When Claude Sonnet 5 Retires: A Team Runbook

01 · Deprecation dates are product dates, not vendor dates

A provider's shutdown date is rarely the date that hurts a product team. The dates that matter are the ones inside your own system: the last day your evaluation suite passed against a model, the day your prompt library stopped being portable, and the day your token forecast assumed a mix you no longer have. In long-running products, a deprecation is not an incident ticket. It is a scheduled release with a backlog, an owner, a freeze window and a rollback path, and it deserves the same ceremony as a feature launch.

The habit that makes this work is simple: every model in production carries a retirement plan from the day it ships. The plan records where the model is used, which behaviours depend on it, what the fallback is, what that fallback costs in quality and in money, and who signs off when the fallback is promoted. Without that record, a deprecation notice turns into archaeology, and archaeology is what pushes teams into emergency migrations with a week of notice and no test coverage.

Treat the vendor's date as the hard end of the runway, then subtract the time you actually need. Review cycles, evaluation reruns, prompt retuning and staged rollouts consume calendar faster than anyone expects. If a model serves traffic you cannot rework in two weeks, you need a standing compatibility path today, not after the notice lands.

02 · The inventory that answers one question: what breaks tomorrow

Start with the surfaces that fail first when a model disappears.

• › Call sites: every product feature, background job, scheduled task and internal tool that reaches the model directly or through a wrapper.
• › Prompts and contracts: system prompts, few-shot examples, structured output schemas and tool definitions tuned against one model's habits.
• › Client wiring: which SDKs, command-line tools and gateways are pinned to a specific model name or version, including agent workflows run from developer machines.
• › Evaluation: which suites measure quality today, how long a full run takes, and whether the same suites can score a candidate replacement.
• › Commitments: internal expectations and external promises that assume particular latency, context length or output shape.

Most teams discover the real risk in the third bullet. A model name can survive in a launch script, a cron job, a notebook or a colleague's local agent configuration long after the platform team believes the migration is complete. Build the inventory from observed traffic as well as from code search: look at what is actually called, who calls it, and how often.

Give every finding an owner and a class. Class one is traffic that a small prompt change can move. Class two is behaviour that depends on a model's reasoning style and needs an evaluation before it moves. Class three is anything tied to a contractual promise, which needs a plan, a budget and explicit sign-off.

03 · A fallback ladder with named tiers and budget ceilings

Every production workload should have a named ladder before the notice arrives.

Primary tier is the model that currently carries the work. Compatibility tier is a model that passes your evaluation suite with known gaps documented, close enough in behaviour that prompt changes stay small and reversible. Emergency tier is a cheaper or faster model that keeps the product usable when continuity matters more than peak quality.

Write the ladder per task, not per product. Long agentic sessions and low-stakes classification do not need the same model, and the ladder for one is usually wrong for the other. A concrete example helps: if Claude Sonnet 5 is the primary for extended agent runs, Claude Haiku 4.5 can be the compatibility or emergency tier for short, well-scoped calls where latency and cost dominate.

For each step in the ladder, record three figures internally: the quality delta measured by your own suite, the operational delta in latency and limits, and the budget delta for your real traffic shape. A fallback you have never measured is not a fallback; it is a hope with a model name attached.

Also decide in advance what promoting the fallback means. Usually it is a routing change behind a flag rather than a code release, and that only works if model choice is abstracted from the caller. Keep it in one place so a deprecation becomes a configuration change instead of a repository-wide search.

04 · Cache accounting and the real cost of a two-model overlap

Overlap windows are expensive in ways a rough token estimate will not show you.

During a migration you often serve the old model and the new one at the same time, and each carries its own prompt prefixes and context. When every call is metered on real tokens with cache writes and cache reads priced separately, the overlap period can double the number of prefixes being warmed and retained, and the bill reflects that split clearly. Plan for it deliberately: keep stable prefixes identical across both routes where you can, avoid rewriting system prompts per request during the window, and make sure the evaluation harnesses themselves do not become a third hidden traffic stream.

This is where metering discipline pays for itself. Clear accounting for output tokens, cache writes and cache reads gives you evidence for when to close the old route instead of guessing from aggregate spend. A relay that keeps one balance and one meter across the whole catalog makes the comparison honest, because you read a single source instead of reconciling several billing systems mid-migration. If your team runs heavy, sustained workloads across providers, open a Quanta account and put every client behind that single meter and base address; teams that bring others onto the relay earn 19% of their top-ups, a small offset to a long overlap window.

Set a budget ceiling for the overlap period at the start, and a review date on which one of the two routes must be switched off.

05 · Rollout gates, decision records and the message users read

Replacements should move through gates, not big-bang switches.

Shadow first: route a small share of production traffic to the candidate and score it with the same evaluations that judged the incumbent, without affecting user-visible output. Canary next: expose the candidate to a narrow slice of real users or internal teams who can report regressions quickly. Promote behind a flag with an explicit rollback instruction, then retire the old route on a scheduled date and confirm that traffic has actually stopped.

Keep a decision record for each gate: what was measured, who approved, which gaps are accepted and why. Six months later, when someone asks why a behaviour changed, that record is the answer instead of a memory.

Finally, communicate early and in plain terms. Internal teams need to know which clients, SDKs and command-line workflows to update and by when. External users need to know what changes in behaviour, what changes in limits or cost if anything, and what action is required of them. A deprecation notice with a date, a migration path and a named contact reads like competence; the same change announced after a silent switch reads like an outage.

Deprecations will keep arriving, and the models behind your stack will keep turning over. The teams that stay calm are not the ones with the best forecasts. They are the ones with a measured fallback ladder, one meter for cost, and a retirement plan attached to every model the day it ships.