Model Deprecation Routing Is a Continuity Drill, Not a Changelog Line

The planner subagent’s request log has looked healthy all week: model deepseek-v4-pro, status 200, tool calls parsing, no retries. The pin has not changed since August. The model answering it has, since 04:00 UTC on Monday, Sep 14, when DeepSeek started serving that ID from V4.1-Flash. No error, no stall, no red job in CI, and nothing in your stack noticed because nothing in your stack was built to.

That is model deprecation routing done by the provider, and it is a cutoff with better manners. The provider did not leave; the model under your ID did. The provider-cutoff drill already covers the case where the endpoint goes dark and the alias layer saves you. This piece is the other case, the one that shows up as a quiet bill: the ID lives, the behavior and the price change, and the only errors you get are the ones your own smoke tests raise.

Treat an in-catalog swap exactly like a provider vanishing, minus the 404. Ordered fallbacks, a quality smoke test, a spend cap per lane, a human who gets told, and a ledger of retired IDs that your routers treat as landmines rather than aliases.

DeepSeek moved V4-Pro traffic on Sep 14, and the ID kept answering

DeepSeek released V4.1-Flash on Sep 10, 2026 (deepseek.com) with the instruction “Set your model to deepseek-flash.” The same post retired two IDs and rerouted a third. “V4-Flash & V4-Flash-Vision-Exp are retired. For compatibility, deepseek-v4-flash and deepseek-v4-flash-vision-exp temporarily route to V4.1-Flash.”

Then: “Tests by multiple parties put V4.1-Flash ahead of V4-Pro on performance, cost, speed & total runtime. We’re phasing out V4-Pro.” And the line that turns a launch post into a continuity event: “Starting at 04:00 UTC on Sept 14, 2026, all deepseek-v4-pro requests will route to V4.1-Flash at V4.1-Flash rates. This will continue until V4.1-Pro launches.” No date is given for that launch.

Screenshot: DeepSeek, “Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient.” (Sep 10, 2026), captured Sep 19, 2026.

The pricing page (api-docs.deepseek.com) makes the alias behavior explicit in a footnote: “Use deepseek-flash as the model name. The legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but the corresponding models have been retired, their requests are served by the DeepSeek-V4.1-Flash model and billed at the Flash price.” The same table still lists deepseek-v4-pro as “DeepSeek-V4-Pro-0813”, without vision support and with a concurrency limit of 500 against Flash’s 2500. The page also carries its own disclaimer: “Product prices may vary and DeepSeek reserves the right to adjust them. We recommend topping up based on your actual usage and regularly checking this page for the most recent pricing information.”

New pricing took effect at 04:00 UTC on Sep 10; the V4-Pro route followed four days later. The off-peak half of that story is the sibling piece on V4.1-Flash off-peak and cache-hit.

For a chat user this is a free upgrade. For a fleet it is three separate events on one ID: a behavior change, a price change, and an unstated end date. Agents act on the model’s judgment, and a planner that was tuned against one model’s habits is now driving tool calls with another’s.

Three vendor dialects for the same event

Every provider does model deprecation routing; they just do it in different grammars, and your ledger has to read all of them.

Dialect	Vendor example	What the ID does	What the operator must assume
Route and rebill	DeepSeek: deepseek-v4-pro requests “route to V4.1-Flash at V4.1-Flash rates” from 04:00 UTC Sep 14, “until V4.1-Pro launches”; retired deepseek-v4-flash “still accepted”	Keeps answering; the model and price beneath it change on a clock	The ID will change again on an undated day; the smoke test is the only notice you get
Dated retirement floor plus breaking changes	Anthropic: claude-fable-5-1 shows “Retirement: Not sooner than September 1, 2027”; the docs list three breaking changes for callers of Fable 5	A floor, not a date; the successor is a new ID with its own contract	Plan the migration as code changes, not a rename; the floor tells you the latest safe date to finish
One alias, no dated snapshot	OpenAI: the model docs list a single gpt-6-astra ID and no dated snapshot	Whatever the alias points at today	Pin behavior with your own evals, because the ID cannot pin it for you

The Anthropic breaking-changes sentence is worth quoting because it is the kind of thing a router cannot see: “If you already call Claude Fable 5, three changes are breaking: forced tool use returns an error, earlier models can’t read its thinking blocks, and editing earlier turns invalidates thinking blocks” (platform.claude.com). A forced-route that silently lands a Fable 5 caller on Fable 5.1 would not 404; it would return errors on every call that forces a tool choice. And a name can change without the model changing: OpenAI’s pricing page notes “Priority processing was renamed Fast mode on July 30, 2026” (developers.openai.com), which is a landmine for any config that keys on the old label.

Price flips ride the same rails. Google’s Gemini 3.8 Flash post says the introductory rate “expires on December 31, 2026” and that from January 1, 2027, “$1.50/1M input tokens and $7.50/1M output tokens will apply” (blog.google). Same ID, same model, a dated doubling. Your ledger should carry it beside the DeepSeek route as the same class of event.

The model deprecation routing drill, step by step

Budget one day for steps 1 and 2, one afternoon for step 3, and an hour for each subsequent notice. Every file below is a shape, labeled illustrative; vendor IDs, prices and dates are the vendors’ own.

Step 1: intake a deprecation ledger, in the vendor’s sentence

A ledger entry is one dated line per ID-affecting statement, quoting the vendor rather than summarizing. Summaries lose the clock; DeepSeek’s route has a start time, a rate clause and an open end, and each of those is a separate decision for you.

# deprecations.yaml — illustrative
- id: deepseek-v4-pro
  vendor: deepseek
  kind: route-and-rebill
  effective: 2026-09-14T04:00:00Z
  until: "until V4.1-Pro launches"        # no date published
  served_by: DeepSeek-V4.1-Flash
  billed_at: flash-rates
  source: deepseek.com/en/news/deepseek-v4-1-flash/
- id: deepseek-v4-flash
  vendor: deepseek
  kind: retired-alias
  effective: 2026-09-10
  served_by: DeepSeek-V4.1-Flash
  note: '"still accepted" per the pricing footnote; treat as landmine, not alias'
- id: claude-fable-5-1
  vendor: anthropic
  kind: retirement-floor
  not_sooner_than: 2027-09-01
  breaking_from_prior: [forced-tool-use-error, thinking-blocks-unreadable, edit-invalidates-thinking]

Watch three places per vendor: the news page, the pricing page and the model page. DeepSeek put the route in the news post and the alias rule in a pricing footnote; Anthropic put the floor and the breaking changes on the model page. A watcher that reads only one will miss half the ledger.

Step 2: audit aliases, and treat retired IDs as landmines

A retired ID that is “still accepted” is the most dangerous kind, because it never fails. Find every pinned ID first, then classify.

# illustrative: find every pinned model ID across repos, dotfiles, CI and subagent files
rg -n --no-heading -e 'deepseek-v4-(pro|flash)' -e 'claude-fable-5(-1)?' -e 'gpt-6-astra' \
   ~/.config ~/.claude ~/.codex .github/workflows agents/ ci/ 2>/dev/null

Classify each hit into one of three buckets and give each bucket a rule:

Bucket	Example	Rule
Live, current	deepseek-flash, claude-fable-5-1	Keep; add to the smoke-test matrix
Live, rerouted	deepseek-v4-pro (served by V4.1-Flash, Flash rates, until an undated launch)	Replace with the explicit target now; a rerouted ID will move again the day V4.1-Pro ships
Retired, still accepted	deepseek-v4-flash, deepseek-v4-flash-vision-exp	Replace, then make the router refuse them: a retired ID in a request is a config bug, not a request

The refusal is the point. If your gateway or alias file passes deepseek-v4-flash through because the provider accepts it, you have handed the provider the decision about which model your agents run and when that changes. A denylist of retired IDs, maintained from the ledger, turns a silent reroute into a loud failure at the one moment a loud failure is cheap: before the job starts.

Step 3: smoke test the forced route before the vendor’s clock does

Quality is the thing that changed without an error, so the smoke test is the detector. Reuse the golden tasks from your eval regression gates; ten to twenty tasks per role is enough to catch a swap. Run them against the old ID and the explicit new ID on the same afternoon and record five numbers, not one.

1. Pass rate per role. Planner, grinder, reviewer. A swap that lifts the grinder and drops the planner is common and invisible in an average.
2. Tokens per task. Same prompt, different tokenizer or verbosity, different bill. Anthropic’s pricing page warns that its newer tokenizer, on Claude 4.7 and later models, “produces approximately 30% more tokens for the same text” (platform.claude.com). A route that moves you across a tokenizer boundary changes cost even at an unchanged per-token price.
3. Cache-hit share. DeepSeek reports prompt_cache_hit_tokens and prompt_cache_miss_tokens in usage, and its caching “works on a ‘best-effort’ basis” (api-docs.deepseek.com). A new model behind an old ID means a cold cache on the first run and a different hit pattern after; measure the second run, not the first.
4. Tool-call error rate. The Fable 5 to 5.1 list is the model: forced tool use that used to work “returns an error.” Count errors per hundred tool calls before and after.
5. Effort setting. Anthropic notes Fable 5.1 “defaults to High effort in Claude Code, and to Medium in Claude Cowork and on Claude.ai,” and that “when set to Low or Medium effort, Fable 5.1 achieves results similar to or better than Fable 5’s at a much lower cost” (anthropic.com). A route can change the default effort under you; pin it explicitly in the lane.

Write the results into the ledger entry. A route you have smoke-tested is a route you chose; one you have not is a route the vendor chose for you.

Step 4: order the fallbacks and cap spend per lane

The route table has three lanes per role, in order, each with a spend cap enforced on that lane alone. The cap is per lane rather than per job because a forced route changes price without changing the job.

# routes.yaml — illustrative; prices are the vendors' published per-MTok rates
planner:
  primary:  { model: claude-fable-5-1, effort: medium, cap_usd_day: 120 }
  fallback: { model: gpt-6-astra, cap_usd_day: 120,
              note: "single alias, no dated snapshot; smoke test monthly" }
  local:    { model: local/open-weight-planner, cap_usd_day: 0 }
grinder:
  primary:  { model: deepseek-flash, cap_usd_day: 40,
              note: "off-peak 50%; peak 01:00-04:00 and 06:00-10:00 UTC Mon-Fri" }
  fallback: { model: "<grok-4.6 id per x.ai docs>", cap_usd_day: 60,
              note: "$2/$6 per MTok; no cached-input price published; cap assumes zero cache discount" }
  local:    { model: local/open-weight-coder, cap_usd_day: 0 }
denylist: [deepseek-v4-flash, deepseek-v4-flash-vision-exp]
rerouted:  [deepseek-v4-pro]   # replace before V4.1-Pro launches

The DeepSeek route is a rare case where the forced swap lowered the bill, and the chart shows by how much. Per million tokens at peak, the pricing page lists V4-Pro at $1.32 for a cache miss, $0.044 for a cache hit and $3.96 output, against Flash at $0.30, $0.006 and $1.20; off-peak is half of each. That is 3.3 to 7.3 times cheaper per token depending on the row, which is why the cap on a rerouted lane has to be re-derived rather than carried: a cap sized in dollars for V4-Pro now buys several times the tokens, and several times the tokens is not always what you wanted an unattended grinder to have.

What the Sep 14 route did to the per-token bill. Source: api-docs.deepseek.com pricing, read Sep 19, 2026. Each panel has its own scale.

The fallback lane is where caps earn their keep, because a fallback is usually a model you know less well. Grok 4.6, released Aug 12, 2026, is a plausible grinder fallback: “Pricing starts at $2 per million input tokens and $6 per million output tokens. Additionally, there is a fast variant which is twice the price” (x.ai). The page does not list a cached-input price or a context window, so the lane’s cap has to assume no cache discount, and the lane’s config has to make sure nobody selects the fast variant by accident. That is not a knock on the model; it is what a cap is for.

Screenshot: SpaceXAI, “Introducing Grok 4.6” (Aug 12, 2026), captured Sep 19, 2026.

Three cap rules. The rerouted lane’s cap is re-derived on the route date, not inherited. The fallback lane’s cap is set from the fallback’s list price with no cache assumption. The local lane’s cap is zero dollars and nonzero minutes, which is a different meter and a different piece of paper.

Step 5: notify a human, before and after

Two notifications, both written before the event. The first goes out when the ledger gains an entry with an effective time: who owns the affected lanes, what the smoke test found, what the cap changed to, and the date. The second goes out when the route actually takes effect and carries the first day’s numbers: tokens per task, pass rate, cache-hit share, spend against cap.

Silence between the two is fine. Silence after the second means nobody looked, and the cost anomaly alert is the backstop for the day someone forgets.

For a route with an open end like “until V4.1-Pro launches,” add a third: a weekly reminder that the lane is still rerouted and that the ledger entry has no end date. The reminder is annoying on purpose. Annoying is what gets a rerouted ID replaced.

Step 6: cut over on your clock, then re-audit

The vendor’s clock said 04:00 UTC on Sep 14. Yours should say the afternoon before, when a human is awake and the smoke test has run. Flip the explicit ID in the route table, run the golden tasks once more against the live lane, confirm the cap, send the second notification. Then re-run the alias audit from step 2, because the cutover itself is when a forgotten pin in a CI workflow gets found.

Six steps, one loop. The loop closes on the vendor’s next sentence, not on a calendar.

For the fleet side of the same afternoon, the switch that stops three coordinators at once is the sibling piece on the multi-vendor abort bus; a cutover that goes wrong at 3 p.m. is easier to unwind if you can stop everything at 3:05.

Six quiet failures in model deprecation routing, and their signals

A rerouted ID that moves twice. deepseek-v4-pro went to Flash on Sep 14 and will go somewhere else “until V4.1-Pro launches” resolves. Signal: a second behavior change on an ID you thought you had already handled. Detection: the weekly reminder from step 5, and the smoke test re-run on the day the vendor posts a launch.

A retired ID accepted by the provider and passed through by your router. Signal: nothing, which is the problem; a job that used to run on V4-Flash now runs on V4.1-Flash and looks fine. Detection: the denylist, which turns acceptance into refusal, and the alias audit, which finds the pin.

A price change with no model change. The Gemini 3.8 Flash introductory rate ends Dec 31, 2026; a fast variant on Grok 4.6 costs twice list. Signal: spend per task rises while pass rate and tokens per task hold. Detection: the ledger carrying dated price events beside model events, and the cap sized from list price.

A behavior change with no price change. An undated alias like gpt-6-astra can point at something new without telling your bill. Signal: pass rate moves on the planner role while tokens per task hold. Detection: the monthly smoke test the route table’s note asked for.

A cap that was right for the old model. After the DeepSeek route, a cap sized in dollars for V4-Pro lets the grinder consume three to seven times the tokens it used to. Signal: an unattended job that runs much longer than it did in August, on budget. Detection: the cap re-derivation in step 4, and a minutes cap beside the dollars cap.

A tokenizer boundary crossed by a route. Same prompt, roughly 30% more tokens on Anthropic’s newer tokenizer per its docs. Signal: input tokens per task up with no prompt change. Detection: tokens per task in the smoke test, compared before and after.

The operating layer holds the ledger, the router holds the rule

Routing belongs at the boundary where the gateway is the control plane: that is where an alias resolves, a denylist refuses a retired ID, and a cap closes a lane. The ledger, the smoke tests and the notifications belong to the operator’s desk, which is where agentic ops has always put the parts that need a human’s judgment. Neither layer can do the other’s job. A gateway that refuses deepseek-v4-flash still needs someone to have read the footnote; an operator who read the footnote still needs something that refuses.

Chatbots made model choice a preference. Agents made it a dependency, and dependencies get drills. The fleet on one screen is where you see the lane that went quiet at 04:00 UTC and the meter that did not; the drill above is how you make sure both of those were expected. The scheduling half, moving flexible work into the off-peak window a route just made cheaper, is the sibling piece on off-peak by clock.

FAQ: model deprecation routing

What happens to deepseek-v4-pro requests after Sep 14, 2026?

DeepSeek says that from 04:00 UTC on Sept 14, 2026, all deepseek-v4-pro requests route to V4.1-Flash at V4.1-Flash rates, and that this continues until V4.1-Pro launches. No launch date is published. The pricing page still lists the ID as DeepSeek-V4-Pro-0813, so replace the pin with an explicit model before the next move.

Should a router accept retired model IDs the provider still serves?

No. DeepSeek accepts deepseek-v4-flash and serves it from V4.1-Flash at the Flash price, which means the provider, not you, decides which model runs. Put retired IDs on a denylist maintained from your deprecation ledger, so a stale pin fails before the job starts instead of quietly running on a model you never smoke-tested.

How do I size a spend cap for a fallback model I have not run before?

Take the list price with no cache assumption, since some pages, like Grok 4.6’s, publish input and output rates but no cached-input price. Multiply by the tokens per task your smoke test measured on that lane, then by the day’s expected task count. Add a minutes cap beside the dollars cap for unattended work.

Sources

• DeepSeek, “Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient.” (Sep 10, 2026)
• DeepSeek API docs, Models & Pricing
• @deepseek_ai on X, V4.1-Flash launch thread: set the model to deepseek-flash (Sep 10, 2026)
• DeepSeek API docs, Context Caching
• Anthropic docs, Claude Fable 5.1 model page
• Anthropic docs, Pricing
• Anthropic, “Introducing Claude Fable 5.1 and Claude Mythos 5.1” (Sep 1, 2026)
• OpenAI docs, GPT-6 Astra model page
• OpenAI docs, Pricing
• SpaceXAI, “Introducing Grok 4.6” (Aug 12, 2026)
• Google, “Introducing Gemini 3.8 Flash and 3.8 Flash Cyber” (Sep 2, 2026)