LLM Model Deprecation: The Failures That Don't Error

42 min read

LLM Model Deprecation: The Failures That Don't Error

· 42 min read
An editorial illustration on warm cream paper in black ink line work. A mechanical split-flap departure board, drawn flat as a technical diagram, carries six rows in a bolted frame. Each row pairs a model identifier on the left with a retirement date on the right, in condensed mechanical lettering: claude-opus-4-1 and 05 AUG 2026, claude-sonnet-4 and 15 JUN 2026, gpt-5-chat-latest and 23 JUL 2026, gemini-2.0-flash and 01 JUN 2026, github-models and 30 JUL 2026, claude-3-haiku and 20 APR 2026. The top row is caught mid-flip, its fallen flap half covering an older identifier behind the new one, with a small motion arc to its left. A slightly tilted rubber-stamp mark reading RETIRED sits over the last row. A small all-caps serif title in the upper-left reads THE DEPRECATION TREADMILL. A thin ink-blue line runs across the bottom of the frame.

claude-opus-4-1-20250805 stops answering today. Requests to it will fail, because Anthropic dates its retirement 5 August 2026 (Anthropic, Model deprecations, retrieved 2026-08-04). That is the easy part. It fails loudly.

Churn stopped being an event. Eight Claude model IDs retired between 28 October 2025 and 15 June 2026. Then look at the 61 days from 5 June to 5 August 2026. Four more Claude models moved through deprecation or retirement. GitHub retired an entire inference platform. OpenAI shut down two model IDs and deprecated nine more, Google deprecated three sampling parameters, and MCP shipped its first formal deprecation policy. Treat each of those as a one-off migration and you will run an emergency migration every month.

This is the maintenance discipline instead: a pinning policy, a grep list, an eval gate before every upgrade, and a budget line. Plus the honest answer to “how much warning do I actually get,” assembled from primary docs, because the number you were told is not the number you get.

Key Takeaways

  • Seventeen dated churn events landed across four vendors and one protocol in the 61 days to 5 August 2026. That is roughly one forced change per vendor per month, and none of it is unusual.
  • The loud failures are the cheap ones. Anthropic removed fast mode twice in 25 days: on Opus 4.6 requests “run at standard speed, are billed at standard rates, and do not return an error,” and on Opus 4.7 they “now return an error” with no fallback (Anthropic, API release notes).
  • Published minimum notice runs from two weeks to twelve months, and three of the seven commercial platforms publish no minimum at all for their GA models.
  • Ranking vendors by notice length inverts the ranking by plannability. Anthropic publishes 60 days and a forward floor date on every live model. OpenAI publishes six months and no forward floor.
  • The same model has two retirement clocks at the same company. claude-opus-4-1 retires on the Claude API today and on Amazon Bedrock on 8 January 2027, a 156-day gap.
  • My own sweep found seven retired model IDs across my harness config, none of them in code I wrote, and one unpinned model alias that is mine.

Seventeen dated churn events in sixty-one days

Model and API churn is a recurring cost with a predictable cadence, not a series of unrelated migrations. Seventeen dated events landed across four vendors and one protocol between 5 June and 5 August 2026, every one documented in a first-party changelog or deprecation page (Anthropic; GitHub; OpenAI; Google; MCP).

DateEventSource
2026-06-05claude-opus-4-1-20250805 deprecated, retirement dated 2026-08-05, replacement claude-opus-4-8Anthropic deprecations
2026-06-15claude-sonnet-4-20250514 and claude-opus-4-20250514 retired. “All requests to these models will now return an error”Anthropic release notes
2026-06-16GitHub Models closed to new customersGitHub changelog
2026-06-25Fast mode deprecated for Claude Opus 4.7, removal dated 2026-07-24Anthropic release notes
2026-06-29Fast mode removed for Claude Opus 4.6. Requests “run at standard speed, are billed at standard rates, and do not return an error”Anthropic release notes
2026-06-30Claude Sonnet 5 GA. New tokenizer, “approximately 30% more tokens for the same text”. Manual extended thinking returns 400. Sampling params return 400. No Priority Tier. Intro pricing to 2026-08-31Anthropic release notes
2026-07-01GitHub Models full retirement dated 2026-07-30. 29 days from date publication to shutdownGitHub changelog
2026-07-16GitHub Models brownout. Requests “temporarily return errors before service is restored”GitHub changelog
2026-07-17Prompt tools APIs and the legacy Workbench scheduled for retirement 2026-08-17Anthropic release notes
2026-07-20Eight OpenAI audio and realtime IDs plus a transcription variant deprecated. Shutdown 2027-01-20OpenAI deprecations
2026-07-21Gemini 3.6 Flash GA. “The sampling parameters temperature, top_p and top_k are now deprecated”Gemini API changelog
2026-07-23GitHub Models second brownoutGitHub changelog
2026-07-23OpenAI shut down gpt-5-chat-latest and gpt-5-codexOpenAI deprecations
2026-07-24Claude Opus 5 GA. Fast mode removed for Opus 4.7, now errors with no fallback. thinking: {"type": "disabled"} with effort xhigh or max returns 400, “a breaking change from Claude Opus 4.8”Anthropic release notes
2026-07-28MCP 2026-07-28 revision. First formal feature lifecycle policy. Roots, Sampling, Logging and Dynamic Client Registration deprecatedMCP deprecated registry
2026-07-30GitHub Models fully retired: “the playground, model catalog, inference API, and bring your own key (BYOK) endpoints will no longer be available”GitHub changelog
2026-08-05claude-opus-4-1-20250805 retiresAnthropic deprecations

That is roughly one forced change per vendor per month. Nothing on that list is unusual, and that is the point.

One row deserves a second look. gpt-5-chat-latest is an alias that floats to newer versions, and OpenAI shut it down anyway on 23 July 2026. An alias is not a promise of continuity. It is a promise of change.

If you ship an MCP server, read the 28 July entry closely. I covered that revision in detail in MCP’s first formal deprecation policy, in the same revision that removed the handshake.

What breaks loudly, and what breaks silently?

The loud failures are the cheap ones. A retired model ID returns an error, your alerting fires, and you change a constant. The expensive failures produce no error at all. They change your behaviour, your bill, or your quality, and nothing tells you.

The cleanest proof is one vendor removing one feature twice in 25 days with opposite failure modes. On 29 June 2026 Anthropic removed fast mode for Claude Opus 4.6: requests with speed: "fast" “no longer run at fast speed or premium pricing: they run at standard speed, are billed at standard rates, and do not return an error.” On 24 July 2026 it removed fast mode for Claude Opus 4.7: those requests “now return an error; unlike Claude Opus 4.6, they do not fall back to standard speed” (Anthropic, API release notes, retrieved 2026-08-04). One vendor, one feature, four weeks apart, and the vendor’s own notes draw the contrast.

The loud column, alertable at the request boundary:

  • Retired model IDs. “Requests to retired models will fail” (Anthropic).
  • temperature, top_p or top_k at a non-default value on Claude Opus 4.7 and later, which “Returns a 400 error” (Anthropic, parameter deprecations).
  • Manual extended thinking on Sonnet 5, which “is removed and returns a 400 error” (Anthropic, release notes).
  • thinking: {"type": "disabled"} with effort xhigh or max on Opus 5.
  • Fast mode on Claude Opus 4.7 after 24 July 2026.
  • GitHub Models endpoints after 30 July 2026. The changelog says only that they “will no longer be available” and specifies no status code, so do not write an alert that expects one.

The silent column is longer, and every row is a documented behaviour change with no error attached:

  • The tokenizer. Content that tokenised at 1M tokens before Claude Opus 4.7 “can tokenize to roughly 30% more tokens.” The migration guide bounds it at “roughly 1x to 1.35x as many tokens… (up to ~35% more, varying by content).” That is a 30% larger input bill and a 30% earlier context ceiling, with no code change.
  • Image tokens, which are worse. Full-resolution images “can use up to approximately 3x more image tokens than on prior models (up to 4,784 tokens per image, compared to the previous cap of roughly 1,600 tokens per image)” (Anthropic, migration guide). A vision-heavy workload can triple its input cost on upgrade.
  • Stale prompt instructions that now actively hurt. Verbatim from the migration guide: “Claude Opus 5 verifies its own work without being told to, so remove explicit verification or self-check instructions carried over from prompts tuned for earlier models; leaving them in causes over-verification.” Prompt content tuned for a retired model is not dead weight. It is a regression.
  • Gateway parameter stripping. LiteLLM’s drop_params exists so that “LiteLLM will drop the unsupported parameter instead of raising an exception.” If it is on, the 400 you were supposed to see becomes a silently discarded temperature. Your determinism setting is gone and your logs are clean.
  • Retired beta headers that no-op. On the 1M context beta for Sonnet 4.5 and Sonnet 4: “The beta header now has no effect on these models,” and you find out when a request exceeds 200k (Anthropic, release notes).
  • Changed defaults. On Opus 4.8 the effort parameter “defaults to high on all surfaces” (Anthropic, models overview). On Sonnet 5, adaptive thinking “is now on by default.” More thinking tokens, same code.
  • Platform auto-upgrade. Microsoft Foundry manages automatic upgrades for Standard-family deployments. Those upgrades “can occur even if the new model version isn’t yet separately available in that region, or for that SKU” (Microsoft Learn).
  • The monitoring trap. Foundry’s lifecycleStatus field reads backwards. The docs are explicit: “a model that the docs list as ‘Deprecated’ (still works, blocked for new customers) appears in the API as lifecycleStatus: "Deprecating"… The API value "Deprecated" means the model is retired and no longer serves inference.” Alerting written against the intuitive reading fires at the wrong time. This is a silent failure inside the detector you built to catch silent failures.

Tokenizer drift is structural, not an Anthropic quirk. OpenAI’s tiktoken maps distinct encodings by model generation, so identical text tokenises differently across a generation boundary by construction. Google deprecated temperature, top_p and top_k on Gemini 3.6 Flash without publishing what happens if you set them. You cannot tell from the docs which column that change belongs in.

The tokenizer change is a cost regression rather than a capability change, which is the same argument as the harness, not the model, being the cost line. And any instruction block written for a model that has since retired is exactly the context tuned for a model that no longer exists problem.

How much notice do you actually get?

Between two weeks and twelve months, depending entirely on which platform you are on, and three of the seven commercial platforms publish no minimum at all for their generally available models. The published number is also not the effective number.

Every cell below is quoted or paraphrased from primary vendor documentation or vendor legal terms, retrieved 2026-08-04.

PlatformPublished minimum noticeForward floor per model?Failure mode at cutoffCarve-outs that shorten it
Anthropic Claude API”at least 60 days’ notice before model retirement for publicly released models”Yes. “Not sooner than <date>” on every active modelHard failNone published
OpenAIGA “At least 6 months.” Specialized variants “At least 3 months.” Preview “may be retired with much shorter notice, such as 2 weeks”NoHard fail, no automatic migrationSafety or compliance: “as much notice as reasonably possible”
Google Gemini APINone quantified for GA. 2 weeks for preview models and for breaking changes behind -latestPartly. Shutdown dates are “the earliest possible dates on which a model might be retired”Hard fail. “the endpoint is no longer available”n/a
AWS Bedrock”at least 12 months before the EOL date” from launch, and “at least 6 months” in LegacyYes. Explicit Legacy, EOL and extended-access dates per modelHard fail. “Migration will not happen automatically""existing customers may lose access to Legacy models after 15 days of inactivity”; pricing rises after 3 months in Legacy
Microsoft FoundryGA “At least 60 days.” Preview “At least 30 days”Yes. 18 months “set programmatically” at launch, readable via the Models API. Partner-provider GA models get 12Auto-upgrade on Global Standard, Data Zone Standard and Standard. Provisioned is manual. Retired returns 410 GoneEmergency retirement with shortened notice; preview deployments “force-upgraded”; access is per-subscription
Mistral AINone publishedNoHard failn/a. Observed windows 30 to 101 days
CohereNone publishedNoHard failn/a
MCP spec (2026-07-28)“the number of months, at least twelve” from the revision marking a feature DeprecatedYes, the Deprecated registryFeature keeps working while Deprecated. Tier 1 SDKs must mark it deprecated and should warn at runtimeExpedited security removal, floored at “at least ninety days”
Open weights, local copyNot applicablen/aNever failsThe licence grant itself, which is not perpetual by default
Open weights, gated Hub pull at deployZero. Authors “can decide at any time to block your access to the model without prior notice”NoHard fail at deploy timen/a

Four readings only become visible once that table exists.

The notice number is the least useful column. Anthropic and Microsoft Foundry both publish 60 days for GA models, and both publish a per-model forward floor you can read today. Anthropic puts “Not sooner than <date>” against every active model. Foundry sets an 18-month retirement date programmatically at launch and exposes it through the Models API. OpenAI publishes six months, three times longer, and no forward floor at all, so you cannot start planning until the clock starts. Ranking vendors by notice length inverts the ranking by plannability, and that inversion is the argument of this post.

Hard-fail is the good outcome. Every platform above hard-fails at cutoff except Microsoft Foundry, which auto-upgrades Standard-family deployments to a replacement model, region by region. A 410 Gone is alertable. Quality drift in one region with no code change and no error is not. Rank by detectability instead of notice length and Foundry moves from mid-table to last.

Published window is not effective window. Bedrock’s 15-day inactivity clause can collapse a six-month window for any quarterly batch job or cold disaster-recovery path. Bedrock’s window also has a price change inside it. After a minimum of three months in Legacy, a model enters public extended access, where “you should expect higher pricing, which will be set by the model provider” (AWS). Your six months are not six months at one price.

The cadence, not the number, is the output. Turn each row into a pin-review interval you can put in a calendar. Sixty days on the Claude API and Foundry GA. Six months on OpenAI GA. Thirty days for a Foundry preview deployment. Two weeks for anything Gemini calls preview or reaches through -latest. Monthly for Mistral and Cohere, because there is no published clock to plan against.

Two smaller details from the primaries belong here. Foundry declares replacements late on purpose, “approximately 90 to 120 days before the retiring model’s retirement date.” Its stated reasoning is that declaring earlier “risks directing customers to a model that is no longer the best available option.” So “wait for the official replacement” leaves you one quarter. Foundry retirement dates are also final: “Retirement dates aren’t extendable.”

Both AWS and Microsoft expose lifecycle state programmatically, Bedrock via modelLifecycle on GetFoundationModel and ListFoundationModels, Foundry via the Models API. Anthropic and OpenAI do not.

One correction worth making, because secondary sources get it wrong: Cohere’s 90 days is not a notice period. It defines who counts as an existing user, “anyone who has used the model or endpoint within 90 days of the deprecation announcement” (Cohere). Do not put 90 in Cohere’s notice column.

A pinning policy you can copy

Pin the exact ID, in one place, per role, with the retirement floor recorded next to it and a CI job that fails before that floor arrives. Seven rules, stated as policy you can paste into a repo.

  1. Pin the full model ID, never a family alias. In Claude Code that means an explicit model value, not opus, sonnet, haiku, default or opusplan. A family alias resolves to the newest version of its family, which makes it an unpinned dependency by design.
  2. Stop using “has a date suffix” as your pinning test. Anthropic is explicit: “Every Claude model ID is a pinned snapshot… Starting with the Claude 4.6 generation, model IDs use a dateless format that is also a pinned snapshot, not an evergreen pointer.” So claude-opus-4-8 is pinned, and for pre-4.6 models the alias column holds “convenience pointers that resolve to a dated model ID.” Grepping for an eight-digit date gives you the wrong answer in both directions now.
  3. One place. A single constant or environment variable per role, never a model string inline at a call site. Grep-ability is the deliverable.
  4. Pin per role, not globally. Planner, worker and judge each get their own pin, so you can upgrade one tier at a time and attribute the delta. That is the router pattern applied to upgrade risk instead of cost.
  5. Never upgrade the judge and the subject in the same change. You lose baseline comparability and you will not know which one moved.
  6. Record three things next to the pin. The date you pinned it, the eval run that justified it, and the published retirement floor for that ID. Anthropic’s “Not sooner than” column and Foundry’s Models API give you the floor for free.
  7. Expire the pin in CI. A job that fails the build N days before the recorded floor, where N is your own migration lead time. Do not rely on the vendor email.

Rule 1 has one platform-specific exception. It is also the only place in this post where the right answer is “pick the setting that fails loudly.” On Microsoft Foundry, pinned and auto-upgraded can both be true. The behaviour is controlled by a deployment property most teams have never read. versionUpgradeOption takes three values: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired, and NoAutoUpgrade. The docs gloss the last as “never auto-upgrade”, and note that the “deployment stops working at retirement.” That value is the pin. It pages you instead of quietly swapping your model.

Aliases deserve one more sentence, because the industry keeps treating them as stability. OpenAI distinguishes floating aliases from dated snapshots, and shut down gpt-5-chat-latest anyway. Google describes -latest as an alias that “will get hot-swapped with every new release of a specific model variation.” Floating and being retired are not mutually exclusive.

What should you grep your configs for?

Eleven patterns. Run them today. Most repos find something, and the silent rows are the ones worth the hour.

#Grep forFindsFails
1claude-opus-4-1, claude-sonnet-4-2025, claude-opus-4-2025, claude-3-7-sonnet, claude-3-5-haiku, claude-3-haiku, claude-3-opus, claude-3-5-sonnetRetired or retiring Claude IDsLoud
2gpt-realtime, gpt-audio, gpt-4o-audio, gpt-4o-realtime, gpt-realtime-mini, gpt-audio-mini, gpt-4o-mini-realtime, gpt-4o-mini-audio, gpt-4o-mini-transcribeThe IDs OpenAI deprecated 2026-07-20, shutdown 2027-01-20Loud, in 2027
3gpt-5-chat-latest, gpt-5-codex, gpt-3.5-turboShut down 2026-07-23, and gpt-3.5-turbo on 2026-10-23Loud
4gemini-2.0, imagen-4, any -preview Gemini IDGemini IDs past or nearing shutdownLoud
5temperature, top_p, top_k, topP, topKSampling params, rejected on Claude Opus 4.7+ and deprecated on Gemini 3.6 FlashLoud, unless row 6 applies
6drop_params, additional_drop_params, allowed_openai_paramsA gateway configured to swallow the error from row 5Silent
7-latest, opusplan, bare opus / sonnet / haiku / defaultUnpinned dependenciesSilent
8context-1m-2025-08-07, fast-mode-2026-02-01, any dated anthropic-beta valueBeta headers that may already be no-opsSilent
9speed: "fast", thinking, budget_tokens, assistant prefillFeatures removed or rejected on newer models, with different behaviour per modelBoth
10200000, 200_000, hardcoded max_tokens ceilings, any words-per-token or chars-per-token ratio, any hand-rolled token estimatorContext and cost assumptions invalidated by the new tokenizerSilent
11Model names in prose: Opus 4.1, Sonnet 4, “you are Claude 3” inside prompts, skills and evals. Also “verify your work”, “double-check”, “re-read the file before editing”Instructions tuned for a model that no longer existsSilent, and a regression

If you ship an MCP server, add a twelfth row: roots/list, notifications/roots/list_changed, sampling/createMessage, logging/setLevel, notifications/message and includeContext. All four newly deprecated MCP features carry an earliest removal of “First revision released on or after 2027-07-28,” so that is a plan-now rather than a fix-today.

I ran rows 1 through 11 across my own harness configuration, agent definitions, skills and this repository on 4 August 2026. That is 5,286 files under ~/.claude, 6,073 under ~/.codex, and 223 in this repo. Four findings are worth reporting, and the pattern in them surprised me.

Row 1 returned seven hits, and not one of them was in code I wrote. Every dead model ID lived in vendored third-party content. The sharpest was "executor_model": "claude-sonnet-4-20250514" inside a published plugin’s reference schema. That ID retired on 15 June 2026, and three different tools had replicated it into three separate cache locations. Row 2 was worse in kind. A file named latest-model.md recommends four of the nine IDs OpenAI deprecated on 20 July 2026. That file ships as reference material an agent reads to choose a model. A grep over my own source would have found neither problem.

Rows 6, 10 and 11 came back clean, which I will take. Rows 6 and 12 returned nothing because I run neither LiteLLM nor Foundry, which is worth stating rather than counting as a pass.

The one finding that is genuinely mine is row 7. My global ~/.claude/settings.json contains exactly one model selection, and it reads "model": "opus[1m]". That is a family alias with a context modifier, not a pinned snapshot. There are no environment-variable pins and no subagent frontmatter pins anywhere in my configuration, so the good news is that there is precisely one surface to fix. It is just unpinned, and I wrote rule 1 above before I checked.

Rows 1 through 4 are a snapshot and will rot. A category of scanners already exists for exactly this problem, and detection of dead IDs is the solved half. What a scanner finds is row 1. What it cannot find is rows 6, 10 and 11.

What has to pass before you promote a new pin?

Never promote a pin on a vendor’s release notes. Nine checks, and Anthropic’s own migration guide prescribes four of them.

  1. Recount tokens on both pins. The token counting endpoint returns the count under the tokenizer of the model you pass, and it is free. Count the same request twice, once on the old pin and once on the new, and record the ratio.
  2. Re-baseline cost from the new counts. The migration guide names three separate chores: “Re-benchmark end-to-end cost and latency under the updated tokenization,” “Re-tune max_tokens to account for the updated tokenization,” and “Re-test any client-side token-count estimations.” That third one is the sleeper. Any hand-rolled words-per-token estimator in your code is now wrong by roughly 30%, and it will not error.
  3. Diff the capability object. GET /v1/models returns a capabilities object per model. Assert that every capability you depend on is still supported on the new pin, and fail CI if not.
  4. Assert the old pin still exists. A retired ID disappears from the model list, which is your cheapest early warning and a three-line CI check. The honest gap: Anthropic’s Models API exposes no deprecation status or retirement date, so the schedule itself is human-readable docs only. Fill that gap three ways, in order of preference. Bedrock’s modelLifecycle field if you are on Bedrock. Foundry’s Models API if you are on Foundry, remembering the inverted status values. A third-party lifecycle feed otherwise. AWS also documents an EventBridge and User Notifications path, the only push-based option any vendor offers.
  5. Find the stragglers no grep will catch. Anthropic’s Console has Usage, then Export. It returns “a CSV of usage broken down by API key and model” (Anthropic). That is how you find the one function still calling a deprecated ID from an environment variable, in an account nobody owns.
  6. Re-run the golden set on trajectories, not just outputs, and make the pin expiry and the capability diff a CI gate rather than a checklist someone remembers.
  7. Replay recorded sessions against the new pin, which is the regression class backtesting exists for, before you promote anything.
  8. Re-sweep the knobs instead of carrying settings over. The migration guide: “Run a fresh effort sweep on your own evals rather than carrying over a setting tuned for an earlier model.” On verbosity it adds that lowering effort “reduces thinking volume without reliably shortening the visible response. Prompt explicitly for conciseness or a target length instead.”
  9. Check the tier, not just the model. Claude Sonnet 5 ships “the same set of tools and platform features as Claude Sonnet 4.6, except Priority Tier, which is not available.” A model upgrade can be a service-tier downgrade.

Then there is the practice nobody writes about, which GitHub handed everyone for free. Before shutting down GitHub Models it ran two deliberate brownouts, “short, scheduled service interruptions (brownouts)” during which requests “temporarily return errors before service is restored” (GitHub). That is a forcing function, and it is stealable. Point your current pin at a deliberate 4xx in staging for an hour and watch. You are testing your harness, not the vendor. What you are looking for is the code path that swallows the error and degrades silently, because that path is what will hide the real retirement.

One principle sits behind all nine checks: the only benchmark that predicts your upgrade outcome is your own. The control-plane suite you re-run on every pin change is where that gets operationalised.

How much should you budget for model churn?

Roughly one forced change per vendor per month. Fund it as standing maintenance with a named owner, not as an unplanned project each time.

Here is the observed rate on one vendor’s API surface over about 180 days. Four model retirement dates: 19 February, 20 April, 15 June, 5 August. Fast mode removed twice. The 1M context beta retired. The prompt tools and Workbench retirement dated 17 August. That is eight forced changes on one platform. Multiply by your vendor count and your protocol surfaces.

LineUnitSuggested reserve
Config sweep and pin bumpper churn event2 to 4 engineer-hours
Eval suite re-runper pinned role, per upgrade1 golden-set run + 1 replay run
Token recount and cost re-baselineper tokenizer change1 engineer-hour (the API call is free)
Prompt and skill re-tuneper model generation, not per event0.5 to 1 engineer-day
Rollback capacityheld, not spentkeep old and new pins live behind a flag through the window
Standing reserveper vendor, per month1 engineer-day

The compounding cost is the silent one, and it is arithmetic you can do from published rates. Claude Sonnet 5’s tokenizer produces approximately 30% more tokens for the same text, and its introductory pricing of $2 per MTok input ends 31 August 2026, reverting to $3. Take 1M input tokens of text as measured on Sonnet 4.6 at $3 per MTok, which is $3.00. The same text on Sonnet 5 is roughly 1.3M tokens: $2.60 in July, $3.90 in September. That is a 50% rise between July and September with no code change, and a 30% rise against the original baseline.

That figure is a worked illustration from published per-token rates, not a measurement of anything. It is deliberately not a cost-per-task number, because every circulating cost-per-task figure for model churn traces back to aggregators with no verifiable primary. Rates are tier 1. Cost per task is not.

Churn is not always a cost increase, and the honest counterexample is today’s retirement. Opus 4.1 bills at $15 and $75 per MTok. Its recommended replacement bills at $5 and $25. Migrating off the retiring model is a two-thirds price cut on rates. The budget line exists because the work is unplanned, not because the rates always rise. That framing sits next to treating agent cost as a standing observability line rather than a quarterly surprise.

What does good deprecation look like?

Three practices already exist in the wild, in three different places. Not one of the model vendors does all three.

A forward-looking floor date on every live version, machine-readable. Anthropic’s “Not sooner than” column and Foundry’s programmatic 18-month date at launch. This is worth more than a long notice window, because it lets you plan before the clock starts.

A single registry of everything on its way out. MCP’s deprecated registry. The policy calls it “the canonical answer to ‘what is on its way out, and by when,’ so that an implementer does not have to reconstruct that picture from deprecation entries spread across revision changelogs.” That is a critique of every changelog-only vendor, written by the people who fixed it.

A runtime warning from the SDK. Under MCP’s feature lifecycle policy, Tier 1 SDKs “Must mark the corresponding API surface deprecated using the language’s native mechanism” and “Should emit a runtime warning when a deprecated feature is exercised,” enforced by a Tier Relegation Process. No model vendor obligates its own SDKs to do that.

The gap is not theoretical. Anthropic’s own parameter deprecation table states it plainly: “Deprecated parameters remain in the SDK request types so existing code continues to type-check, but their behavior changes per model.” That is the silent column in one sentence. Your compiler is satisfied, your types are valid, and the behaviour moved underneath you.

So the silent failures in this post are not accidents of implementation. They are the predictable result of publishing lifecycle information as prose on a documentation page while shipping behaviour changes through the SDK. Deprecation pain and baseline churn are coupled, which is why single-lever fixes underperform: a pinning policy without eval capacity just converts surprise outages into scheduled ones you still cannot clear. The protocol layer noticed and wrote a policy that binds implementations. The model layer has not.

FAQ

How much notice do you get before a model is retired?

Between two weeks and twelve months, depending on the platform. Anthropic commits to “at least 60 days” and Microsoft Foundry to 60 days for GA, 30 for preview. OpenAI commits to six months for GA, AWS Bedrock to six months in Legacy, and MCP to twelve for spec features. Three publish no minimum for GA models at all: Google’s Gemini API, Mistral and Cohere.

Should I pin the exact model version or use an alias?

Pin the exact ID. Aliases resolve to the newest version of a family, so they are unpinned by design, and OpenAI shut down a floating alias outright on 23 July 2026. A date in the ID no longer means pinned either. From the Claude 4.6 generation, Anthropic says model IDs “use a dateless format that is also a pinned snapshot, not an evergreen pointer.”

What breaks silently when a model is deprecated?

Six things, none of which error. Tokenizer changes, roughly 30% more tokens for the same text from Claude Opus 4.7 onward. Gateways configured to drop unsupported parameters. Retired beta headers that become no-ops. Changed defaults, such as effort now defaulting to high. Platform auto-upgrades on Microsoft Foundry Standard deployments. And prompt content tuned for a model that no longer exists.

Do I need to re-run evals when I upgrade a model?

Yes, and the vendor says so. Anthropic’s migration guide tells you to “Run a fresh effort sweep on your own evals rather than carrying over a setting tuned for an earlier model.” It also tells you to “Re-benchmark end-to-end cost and latency under the updated tokenization” and to “Re-test any client-side token-count estimations.” A settings carry-over is not a migration.

What happens if I keep calling a retired model?

On every platform surveyed here except Microsoft Foundry, the request fails. Anthropic states that “Requests to retired models will fail,” Bedrock that requests “will fail” after the EOL date, and Foundry returns 410 Gone once a version is retired. Foundry is the exception worth knowing: Standard-family deployments are auto-upgraded to a replacement model instead, with no error.

Conclusion

Churn is a monthly maintenance line, not a migration project. The loud failures are the cheap ones, and six of the fourteen documented behaviour changes in this post are loud while eight are not. The notice number matters less than whether the vendor publishes a forward floor you can read today. That is why 60 days from Anthropic is more plannable than six months from OpenAI. Hard-fail beats auto-upgrade, because you can alert on it. Pin the exact ID per role and expire the pin in CI. Gate every upgrade on your own evals and a token recount. Budget a standing engineer-day per vendor per month.

Run the grep list today and the brownout drill this week. If the drill finds a path that swallows the error, fix that before you fix any model ID, because that path is what will hide the next retirement.

My own sweep found the dead IDs in my dependencies rather than my code, and found the one unpinned alias in the file I wrote myself. That distribution is probably yours too.

Sources

Original data note: the grep sweep is first-hand and was run on 2026-08-04 across 5,286 files under ~/.claude, 6,073 under ~/.codex, and 223 in this repository, restricted to .json, .md, .toml, .yaml, .yml, .ts and .sh and excluding node_modules, .git and build output. Row 1 returned 7 hits, all in vendored third-party content; row 2 returned 7, including four deprecated OpenAI IDs inside a reference file named latest-model.md; row 7’s only finding in authored configuration was "model": "opus[1m]" in ~/.claude/settings.json. Rows 6, 10, 11 and the MCP row returned nothing, and rows 6 and 11 return nothing partly because this setup uses neither LiteLLM nor Microsoft Foundry. This is one developer’s machine, not a survey. The brownout drill in the eval-gate section is a prescribed practice modelled on GitHub’s two published brownouts; it has not been run here, and the post does not claim otherwise. The three-bar cost figure is arithmetic over published per-MTok rates and token-count ratios, not a measured bill.

Verification note: every figure was verified against its primary on 2026-08-04, and three claims were dropped rather than hedged. A 15-day notice period for Fireworks marketplace models on Microsoft Foundry could not be found on either the lifecycle policy page or the partner models page, so it is absent from the comparison table and the chart; the verified Foundry commitments are 60 days for GA and 30 for preview, with partner-provider GA models on a 12-month rather than 18-month lifecycle. A Vertex AI model-level policy of six months after a successor’s release could not be confirmed at primary, so Vertex has no row and only the Gemini API’s verified position appears. A 2026-10-16 shutdown date for gemini-2.5-pro no longer appears on Google’s deprecations page and was cut. Separately, the two-week Gemini figures come from the Gemini models page rather than the deprecations page, which quantifies nothing; Cohere’s 90 days is a definition of “existing user” and not a notice window; and no retirement date is asserted for claude-mythos-preview, which Anthropic’s deprecations page calls deprecated without listing one. The claude-opus-4-1 Bedrock EOL of 2027-01-08 was read from the Bedrock lifecycle page on 2026-08-04, alongside a 2026-10-08 public extended access date that raises pricing inside the window.

Share this post

If it was useful, pass it along.

What the link looks like when shared.
X LinkedIn Bluesky

Search posts, projects, resume, and site pages.

Jump to

  1. Home Engineering notes from the agent era
  2. Resume Work history, skills, and contact
  3. Projects Selected work and experiments
  4. About Who I am and how I work
  5. Contact Email, LinkedIn, and GitHub