Follow Discord
Sweep 22 Oct 2026 · 21:04Z Build v2.1.309 528 read Stable v2.1.308 Latest v2.1.309 Next v2.1.309 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeReleasesv2.1.219entry #119

Claude Code v2.1.219 ·

Category-based server-side fallback beta

The server can now pick a fallback model by category when a request is refused, instead of the app naming one.

Under the hood Nothing to try yet In Development
JSON All of v2.1.219
Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
ElsewhereArea: what it touches
In DevelopmentKind: in v2.1.219,
In DevelopmentSection of the release

Category-based fallback only applies if the server accepts a new beta header; rejection un-arms it and reverts to explicit fallback lists.

What

A second server-side-fallback beta lets the server choose the fallback model by category rather than the client naming one, but it only takes effect if the server accepts the new beta header.

Details
  • the descriptor is server_side_fallback_category with header server-side-fallback-2026-07-01
  • when it applies, the request sends fallbacks: "default" instead of an explicit [{ model: ... }] list, letting the server route, for example, cyber-category refusals to the previous Opus
  • fallback-error classification gained category_beta_header (the new header was rejected) and default_unconfigured (from a body containing "has no default fallback configuration")
  • the retry path un-arms the category header on those errors and falls back to the existing explicit-list behaviour
  • the code path also still requires the existing default-fallback conditions
Evidence

"server-side-fallback-2026-07-01"

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

See this entry in the whole of v2.1.219 →

Feedback