Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999900518Guide page
📋

CAROL-INI-2261-00: Per-call LLM provider override — Albus RSI diagnosis and troubleshooter on Claude Fable

Initiative
Open in Initiatives →

📖About

The LLM provider toggle is global (llm_config.json active_provider=deepseek), so every droid call routes to deepseek-chat — including Albus RSI diagnosis calls that request sonnet, and the meta-diagnosis stronger-model upgrade to opus, which silently collapses to deepseek-chat (alias not in _DEEPSEEK_MODELS). Ninad decision 2026-07-03: fleet STAYS on DeepSeek; ONLY Albus RSI diagnosis (al-rsi-diag-01) and Albus troubleshooter move to Claude, model Fable (claude-fable-5, verified available on the VM CLI).

Scope (5 pieces): 1. Optional provider param on the shared LLM entry points (call_claude / call_claude_raw) delegating to llm_provider.get_provider(name); callers that omit it keep the global active provider. 2. Config-driven per-droid overrides map in llm_config.json (droid id -> provider+model), data not code; flipping back is a config edit. 3. Model alias fixes both sides: Claude provider gains fable -> claude-fable-5 alias; DeepSeek provider maps opus/fable -> deepseek-reasoner instead of silently -> deepseek-chat, so stronger-model intent survives fallback. 4. Fail-open fallback: if the requested provider is unavailable or errors (e.g. Claude Max auth lapse), fall back to the active provider and log the downgrade — the RSI loop must never stall on auth. 5. Attribution: prompt-capture/usage records gain the resolved provider so Fable vs DeepSeek diagnosis quality is comparable on real data.

First consumers: Albus RSI diagnosis droid + Albus troubleshooter -> provider=claude, model=fable (meta-diagnosis included). Everything else untouched on DeepSeek.

⚖️Decisions

  • Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
  • [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • Fleet default stays DeepSeek; ONLY Albus's RSI diagnosis (al-rsi-diag-01) and Autonomous Troubleshooter (al-auto-01) route to Claude, model Fable (claude-fable-5). Decided by Ninad 2026-07-03. (orion)
  • Override resolution precedence: explicit provider argument > per-droid overrides map in llm_config.json > global active provider. Unknown/unregistered provider falls back to active (fail-open). Config re-read every call — flipping a droid back is a config edit, no deploy. (orion)
  • If an overridden provider errors (auth lapse, rate limit, transport), the call retries ONCE on the active provider and records the downgrade (_fallback_from in usage) — an override must never stall the RSI loop. (orion)
  • Alias hygiene: Claude side resolves fable -> claude-fable-5; DeepSeek side maps opus/fable -> deepseek-reasoner and sonnet/haiku -> deepseek-chat, so stronger-model intent survives fallback (previously opus silently collapsed to deepseek-chat, making the meta-diagnosis upgrade a no-op). (orion)
  • Attribution: execution_prompts store gains a provider column (idempotent migration); the cost log writes the RESOLVED provider — Fable vs DeepSeek diagnosis quality is now comparable on real data. (orion)
  • [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
  • Test-suite maintenance for CAROL-INI-2266 (recorded on 2261 book keeping thread): the RSI loop suite mock now models the initiative_tags picker query and covers the rsi-retrigger-stuck skip (23 tests). The 2 suite errors flagged by regression run 388 were mock-blindness to the new query, not a code defect. (orion)
  • [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

Success criteria

  • Shared LLM entry points accept an optional per-call provider override; calls without it behave exactly as today (global active provider) (must_have)
  • Per-droid provider/model overrides live in llm_config.json as data; Albus RSI diagnosis + Albus troubleshooter configured to provider=claude model=fable, and their live calls verifiably route to claude-fable-5 (must_have)
  • Claude provider resolves alias fable -> claude-fable-5; DeepSeek provider maps opus/fable -> deepseek-reasoner (no silent collapse to deepseek-chat) (must_have)
  • If the overridden provider fails or is unreachable, the call falls back fail-open to the active provider and the downgrade is logged; RSI loop never stalls on provider auth (must_have)
  • Usage/prompt-capture records include the resolved provider for every call (must_have)
  • All other droids remain on DeepSeek — no behavior change outside the two Albus consumers (regression suite shows no new failures) (must_have)