In this briefing
- 01The same migration cycle has produced three lifecycle treatments
- 02API compatibility does not make replacement models task-equivalent
- 03Private deployment does not remove lifecycle risk; it changes the failure mode
- 04Gateways are adding routing ledgers, but release records are not production evidence
- →What to watch next
- ↗Sources and verification
- At 17:00 Pacific time on 25 September, Baseten will withdraw the model ID values for GLM 4.7, Kimi K2.7, Kimi K2.6, Inkling, Inkling Small and DeepSeek v4 Pro; each ID will then become inactive and return errors for every request.
- Fireworks' 25 September withdrawal covers only older DeepSeek, GLM, Muse and Kimi Serverless entry points, leaving Dedicated deployments unaffected; the same model name may therefore have a different lifecycle in a different service form.
- On 10 September, DeepSeek planned to route deepseek-v4-pro temporarily to V4.1 Flash from 12:00 today; its current API documentation instead says V4 Pro will remain available after 14 September with unchanged billing. The latest LiteLLM release candidate begins to synchronise deprecation dates and display the actual routed model, but neither a catalogue nor routing logs replace a final state check before activation.
The same migration cycle has produced three lifecycle treatments
On 13 September, Baseten announced that GLM 4.7, Kimi K2.7, Kimi K2.6, Inkling, Inkling Small and DeepSeek v4 Pro would be deprecated at 17:00 Pacific time on 25 September. The announcement is explicit about behaviour after the deadline: each relevant model ID will become inactive and return an error for every request. It does not promise that an old ID will map automatically to the recommended alternatives, so callers that continue to use an old ID will encounter an explicit failure at the deadline.
On 12 September, Fireworks announced a Serverless migration pointing to the same 25 September date. It covers DeepSeek V4 Flash (0731), DeepSeek V4 Pro (0813), DeepSeek V4 Flash Vision Exp, GLM 5.2, Muse Glimmer 30B, Kimi K2.6 and Kimi K2.7 Code. The notice also says that Fast and US-only Serverless variants are affected where applicable, while Dedicated deployments are unaffected. The three DeepSeek models are directed to V4.1 Flash, GLM 5.2 to GLM 5.3, Muse to NVIDIA Nemotron 3.5 Lightning 30B A3B, and both Kimi models to either GLM 5.3 or Kimi K3.
DeepSeek's third treatment of its own API changed before the plan took effect. An official announcement on 10 September said that the older V4 Flash and V4 Flash Vision Exp had been retired and their compatible model names were temporarily routing to V4.1 Flash; it also originally planned to route every deepseek-v4-pro request to V4.1 Flash from 12:00 Beijing time on 14 September. The current API documentation instead says that, in response to user demand, the DeepSeek V4 Pro API will remain available after 14 September with unchanged billing, and that further notice will be given if this changes. The two official materials preserve positions from different stages; operating decisions should use the final state available before activation.
These three treatments separate the questions 'does the endpoint still respond?' and 'what is still running?'. A hard shutdown creates a visible error, retirement by service form affects only some deployments, and a schedule change just before activation can make an earlier migration list stale very quickly. If enterprise operating records retain only the model string in the request or the first announcement, they cannot distinguish a service interruption, a change in deployment scope and an overridden plan.
API compatibility does not make replacement models task-equivalent
DeepSeek describes V4.1 Flash as a multimodal MoE model with 552 billion parameters, activating 8 billion parameters per token during input and 16 billion during output, with support for contexts of up to 1 million tokens. The official model card also says that the instruct-model results use the maximum reasoning_effort=100. Code-Agent evaluations use different DeepSeek Harness, mini-SWE or Claude Code scaffolds, while visual-Agent evaluations use a 512,000-token context. Capability figures are therefore tied to reasoning effort, context and execution scaffold; they cannot be inherited from the API name alone.
The same official table also shows that a 'replacement' is not higher on every measure: V4.1 Flash records a Pass@1 of 90.6 on Terminal-Bench 2.1, above V4 Pro's 87.9; it records 74.2 on DeepSWE v1.1 against 62.7. On GPQA Diamond, however, V4.1 Flash records 90.9, below V4 Pro's 92.4; on the same text-only subset of HLE, the figures are 39.1 against 42.7. This is a vendor evaluation under specified configurations, not an independent result for enterprise workloads, but it is enough to show that a planned alias redirect cannot be interpreted as a task-by-task equivalent upgrade.
Keeping a model entry point compatible can reduce code changes, but output quality, tool behaviour, visual input, context consumption, latency and price may still change. A comparable migration record needs to fix the request alias, actual model revision, reasoning parameters, scaffold and business sample together; otherwise a change in success rate after migration is difficult to attribute.
Private deployment does not remove lifecycle risk; it changes the failure mode
Fireworks explicitly limits the 25 September retirement to Serverless, while Dedicated deployments continue to run. This boundary makes service form part of model identity even within one supplier: a shared endpoint may update quickly with the platform catalogue, while a dedicated instance carries a lifecycle through its own deployment and capacity. Moving from Serverless to Dedicated is therefore not simply a URL change; it also changes the image, GPU form, scaling, patching and cost basis.
The NVIDIA AI Enterprise lifecycle notice shows another constraint on the private-deployment side. Each model-specific NIM for Llama-3.1-8B-Instruct, Llama-3.3-Nemotron-Super-49B-v1.5 and Nemotron 3 Nano has Production Branch 6 as its last supported branch, is absent from Production Branch 7, and reaches the end of support in 2027-01; the corresponding artefacts then receive no further CVE patches, bug fixes or updates. NVIDIA's migration paths include moving to a model-free NIM configured with a supported model source and profile, or to another supported NIM; for the latter two entries, it also explicitly requires validation of behaviour or application quality, performance and GPU capacity before cutover.
The main risk for a cloud endpoint often appears as requests beginning to fail on a stated date or being routed automatically; for private deployment it more often appears as a frozen operating branch, the end of patches and a renewed hardware-capacity calculation. Both are model-service lifecycle issues with different responsibility boundaries. A model inventory can describe actual exposure only if it includes the provider, service form, endpoint or image identifier, operating branch and support deadline.
Gateways are adding routing ledgers, but release records are not production evidence
LiteLLM v1.102.0-rc.1, released on 13 September Beijing time, puts model-catalogue and routing visibility changes in the same release candidate. The release record includes audits of deepseek-flash and gpt-live-1, corrected deprecation dates for xAI and Groq, synchronised deprecation dates for Azure and Together, and the addition of DeepSeek V4.1 Flash on Fireworks. It also displays the actual routed model and session savings in Claude Code and Codex, exposes complexity-routing response headers, fixes fallback when the auto-router layer is unhealthy, and provides guidance for verifying release containers with cosign signatures.
These changes show multi-model gateways turning catalogues, prices, deprecation, actual routing and fallback reasons into observable state, but the release page labels v1.102.0-rc.1 as a Pre-release. It can prove that the relevant code entered a release candidate; it cannot prove that the catalogue will always be timely, that every provider will return an immutable underlying revision, or that a business result after automatic fallback is equivalent to the original model. Gateway logs that display only a friendly name or a savings figure are still insufficient to reconstruct the model, price and policy through which a request actually passed.
The auditable unit for a model lifecycle is expanding from one API model name into a resolution chain: caller alias, gateway route, provider endpoint, actual model revision, service form, price snapshot, fallback reason and validation result. A control plane can record this chain, but the business risk and agreed policy still determine whether automatic replacement is permitted and whether an unknown revision should fail closed.
What to watch next
- How long DeepSeek V4 Pro's continued availability will last, whether later changes provide a precise effective time, and whether the API exposes an actual model revision that can be recorded consistently.
- The exact error codes, last successful request times, regional differences and post-migration capacity arrangements at the 25 September deadlines for Baseten and Fireworks.
- Whether multi-model gateways develop standard fields across providers for the requested alias, resolved version, price snapshot, service form, fallback reason and validation batch.
Sources and verification
Golden Data has edited this briefing from the public materials listed above. The original sources govern facts and figures. The enterprise relevance sections are Golden Data editorial analysis and do not constitute an endorsement of any third-party product.
← Back to AI Daily Briefing