A Three-Tier fallbackModel Setup for Claude Code — Keeping Unattended Runs Alive Through Overload Mornings

Ordering the three tiers — what goes where

I ordered the chain like a staircase you descend one quality step at a time. My three criteria:

• Tier 1 (primary): the model whose quality you actually want day to day. I am currently trialing Claude Fable 5 during its introductory window, with the explicit understanding that usage credits apply after June 22 and I may settle back on Opus 4.8 depending on cost
• Tier 2: a model whose output style is close enough to the primary that prompts transfer as-is. Opus 4.8 tracks my triage classification rubric reliably, so it sits here
• Tier 3: a light model you can honestly describe as "clearly better than no result at all." Sonnet 4.6 is fast and gets the broad classifications right

The configuration I would avoid is putting a lightweight model directly in tier 2 to minimize cost. The chain only fires a few times in tens of days, so the cost delta is noise at monthly scale — but a quality gap comes back to you as rework the very next morning. Precisely because activation is rare, spending quality on tier 2 is the trade that pays.

If you want the same philosophy at the API layer, the anti-corruption-layer approach in An Anti-Corruption Layer for Claude API Models — Keeping Generation Changes Out of Your Business Logic applies directly. The CLI's fallbackModel is, to my mind, that whole design compressed into one line of configuration.

Logging which model actually ran — extracting it from stream-json

The first thing that bothered me after enabling fallback was not knowing who wrote this morning's report. Fallback fires silently; without a record you can neither audit quality drift nor attribute cost.

I switched the output format to stream-json and now pull the model name from the session-init system message, appending it to a CSV:

#!/bin/bash
# Record the executing model; flag the report when it is not the primary
PROMPT_FILE="$HOME/ops/crashlytics_triage_prompt.md"
LOG="/tmp/triage_stream.jsonl"
PRIMARY="claude-fable-5"
 
claude -p "$(cat "$PROMPT_FILE")" \
  --output-format stream-json --verbose > "$LOG"
 
MODEL=$(jq -r 'select(.type == "system" and .subtype == "init") | .model' "$LOG" | head -1)
RESULT=$(jq -r 'select(.type == "result") | .result' "$LOG")
 
echo "$(date +%F),${MODEL}" >> "$HOME/ops/triage_model_history.csv"
 
if [ "$MODEL" != "$PRIMARY" ]; then
  # On fallback days, annotate the report itself so tomorrow-me cannot miss it
  printf "> Note: today's run used %s\n\n%s" "$MODEL" "$RESULT" > /tmp/triage_result.md
else
  printf '%s' "$RESULT" > /tmp/triage_result.md
fi

The key decision: treat a fallback event as an annotation on the report, not as an error. Fallback-day output is exactly what I want to inspect later, so the flag belongs in the place I read, not only in a CSV nobody opens. For unattended operation, that placement proved more reliable than any alerting.

Preparing for quality drift on fallback days

After one morning dropped all the way to tier 3 (Sonnet 4.6), I re-ran the same day's 52 crash logs through Fable 5 and compared classifications. 47 of 52 matched — about 90% agreement. All five disagreements were low-frequency crashes with multiple interacting causes, where the lighter model leaned conservative and routed them to "needs manual review."

From that measurement I set exactly two operational rules:

• On fallback days, I manually re-check only the items classified as high priority — never the full report
• If fallback fires more than three times in a month, I revisit either the primary model choice or the run's time slot

Preparing for quality drift is not about perfect verification; it is about deciding where trust ends and your own eyes begin. A measured 90% agreement rate turned out to be exactly enough evidence to draw that line with confidence.

Pairing it with glob deny rules — safety for runs that no longer stop

Once fallback guarantees your run keeps going, the fact that it keeps going becomes its own risk. Whatever model ends up executing, the areas it must never touch should be pinned down with permissions deny rules — which recently gained glob support, so patterns can be expressed compactly:

// .claude/settings.json — lines that no model, primary or fallback, may cross
{
  "permissions": {
    "deny": [
      "Write(~/ops/secrets/**)",
      "Bash(rm -rf*)",
      "Read(**/*.env)"
    ]
  }
}

I have come to see fallbackModel and deny rules as a matched pair: one provides the flexibility to keep executing, the other the rigidity of what stays protected no matter what executes. For permission design in unattended contexts more broadly, see Designing Claude Code Skills That Actually Run Unattended — Three Patterns to Avoid Permission-Dialog Stalls.

How the June 15 credit migration interacts with fallback

Headless claude -p moves to API-rate-based monthly credits on June 15. The easy thing to miss in a fallback design is that each tier consumes credits at a different weight. The chain fires rarely, yes — but a configuration that keeps a heavy primary running through a credit-starved final week risks stopping for budget reasons before overload ever becomes the problem.

I now check remaining monthly credits weekly and am experimenting with swapping the primary down one tier during the last week of each month. For the broader cost-side redesign of which pipeline stages deserve delegation at all, Reallocating My Automation Pipeline Ahead of the June 15 Billing Change covers the reasoning in detail.

What to do next

There are only three steps:

1. Count the failed days in your unattended-run logs over the past 30 days. Even one lost morning a month makes the migration worthwhile
2. Add the fallbackModel array to settings.json, ordering three models as a deliberate quality staircase
3. Wire up the stream-json model logging, and on the first morning the chain fires, measure the quality drift once

Those three steps get you an unattended setup that no longer dreads an overloaded morning.

If your own morning batches have been quietly coming up empty, I hope this record saves you the troubleshooting time it cost me.