Claude Code Adds Fallback Models and Tightens Agent Security

Claude Code v2.1.166, released June 6, ships two changes that directly affect vibecoders running Opus 4.8 in production: a fallbackModel setting that automatically routes around API overload errors, and a security boundary that closes a privilege escalation path in multi-agent workflows built on SendMessage. If you have hit 529 overloaded errors in the past two weeks, the fix is a five-line config change.

What Has Been Causing the Overload Interruptions

The HTTP 529 overloaded_error appears when Anthropic's shared model capacity is saturated for the model your session is requesting. The error has been documented across multiple GitHub issue threads since Opus 4.8 became the default model for Max and Team Premium accounts in late May. Reports cluster around US business hours on Tuesday through Thursday, roughly 10 a.m. to 2 p.m. PST, when developer demand peaks.

Before v2.1.166, Claude Code applied internal retry with exponential backoff on 529 errors. For brief overloads that cleared in seconds, this worked fine. For sustained capacity saturation during peak hours, the session would exhaust its retries and surface the error to the user, stopping whatever the agent was in the middle of doing. On a 30-minute autonomous refactor run, hitting a hard stop at minute 22 means restarting from context rather than from where the work left off.

How Do You Configure the Fallback Model Setting

The setting belongs in your settings.json. Add it at the user level for global coverage, or at the project level for per-project control:

{
  "model": "claude-opus-4-8",
  "fallbackModel": ["claude-sonnet-4-6", "claude-haiku-4-5-20251001"]
}

Claude Code tries fallbacks in array order. If Opus 4.8 is overloaded, it moves to Sonnet 4.6. If Sonnet is also overloaded, it tries Haiku. You can specify one, two, or three fallbacks. A session flag also works without touching your config file:

claude --fallback-model claude-sonnet-4-6

The retry applies once per turn, not indefinitely. If the first fallback is overloaded, Claude Code moves to the second, and if all configured fallbacks fail, it surfaces the error rather than queuing forever. Auth errors, rate-limit errors, request-size errors, and transport errors bypass the fallback chain entirely and surface immediately.

For most use cases, a single Sonnet 4.6 fallback is the right configuration. Sonnet handles the majority of coding tasks Opus takes on, runs measurably faster, and costs less when the fallback triggers. Haiku as a second fallback is useful when maximum session continuity matters more than model quality, such as during a long overnight agent run.

One failure mode to watch: if you configure a fallback model your plan cannot access, the fallback attempt fails with an auth error rather than another 529, and that surfaces immediately without further retries. Test your fallback chain against a real overload period, or at least verify your plan has access to every model in the chain, before relying on it in a production agent run.

Why Did Cross-Session Messaging Change in Multi-Agent Work

The second significant change in v2.1.166 addresses how trust authority propagated across Claude Code sessions connected by SendMessage.

SendMessage lets one Claude session relay messages to another. In a multi-agent setup, an orchestrator session typically spawns worker sessions and directs them through this channel. Before v2.1.166, a message arriving via SendMessage could carry user-level authority if the orchestrating session framed it as a user instruction. A worker receiving such a message treated it with the same trust as a direct human input.

This created a privilege escalation path through the orchestration layer. A compromised or prompt-injected orchestrator could relay permission grant requests that appeared to come from the user. Worker sessions running in auto mode would then act on those grants without a real human confirmation. The attack surface is narrow in practice but meaningful for teams running complex multi-agent pipelines on sensitive codebases or production infrastructure.

In v2.1.166, this is corrected. Messages relayed via SendMessage from other Claude sessions are now marked explicitly as non-user-authority messages. Receiver sessions refuse relayed permission requests outright. Sessions running in auto mode block them entirely. A permission grant now requires a direct human interaction, regardless of how it arrives.

For vibecoders running a single orchestrator directing a handful of worker sessions on a coding project, this change is transparent. For anyone whose orchestrator was relaying permission grants to workers as part of an automation workflow, those grants now fail. The fix is to restructure the workflow so permissions come from a human-in-the-loop step rather than an orchestrated relay.

What Other Features Did v2.1.166 Include

Glob patterns in deny rules. Tool-name positions in deny rules now accept glob patterns. Setting "*" in the deny list blocks all tools. This makes blanket deny policies easier to write: deny everything, then allow specific tools by exception, rather than listing every tool name explicitly. Unknown tool names in deny rules now warn at startup, catching typos that previously silently failed to apply.

Thinking control. Setting MAX_THINKING_TOKENS=0, passing --thinking disabled, or toggling the per-model thinking setting now successfully disables extended thinking on models that use it by default when accessed via the Claude API. If you have tasks where you want raw speed over deliberation (quick lookups, formatting passes, short generation tasks), you can suppress the thinking step and reduce latency.

Update transparency. claude update now announces the target version before starting the download. Previously the command went silent during the download phase, making it unclear whether anything was happening. Small fix, useful when you care about tracking exactly which version a session is on before it switches mid-session.

What Does This Mean for Vibecoders Running Agentic Workflows

The fallback model is immediately actionable. Add it today if you have experienced 529 interruptions on Opus 4.8. The configuration takes under a minute and works at both user and project scope. For background workers and CI runs under --bg-exec or Claude Code GitHub Actions, the fallback now prevents hard session failures: workers degrade to the fallback model instead of stopping and leaving the task in an unknown partial state.

The SendMessage security change is a behavior break for anyone who built orchestration workflows that rely on relayed permission grants. That pattern was never the intended use of the feature, but if it was working for you before, it no longer does. The correction is to add an explicit human checkpoint where the permission grant is needed rather than routing it through the agent layer.

The two changes together describe a pattern in how Claude Code is maturing. The fallback model makes sessions more resilient to infrastructure conditions. The SendMessage security boundary makes multi-agent authority more precisely defined. Both are preconditions for running Claude Code workflows in production environments where a failed session costs real time, and where an ambiguous trust boundary is a liability.

Full release notes are in the v2.1.166 release on GitHub. The Claude Code changelog has the full v2.1.163 through v2.1.168 diff for this week's releases.