{"version":"2.1.219","anchor":"category-based-server-side-fallback-beta","canonical_anchor":"category-based-server-side-fallback-beta","heading":"Category-based server-side fallback beta","tier":"internal","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.219\/e\/category-based-server-side-fallback-beta","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.219","markdown":"### Category-based server-side fallback beta\n\nThe server can now pick a fallback model by category when a request is refused, instead of the app naming one.\n\n**What**\n\nA 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.\n\n**Details**\n\n- the descriptor is `server_side_fallback_category` with header `server-side-fallback-2026-07-01`\n- 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\n- fallback-error classification gained `category_beta_header` (the new header was rejected) and `default_unconfigured` (from a body containing \"has no default fallback configuration\")\n- the retry path un-arms the category header on those errors and falls back to the existing explicit-list behaviour\n- the code path also still requires the existing default-fallback conditions\n\n**Evidence**\n\n`\"server-side-fallback-2026-07-01\"`\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5\n- Present in the build but not switched on"}