Seventeen models retire on one October day. Treat model choice as a supported dependency.

In brief

Three model retirements executed during July and August 2026, and two larger ones are scheduled inside the current planning cycle.

Executed: Mistral retired five models on 31 July 2026, including Mistral Small 3.2 and Mistral Nemo 12B. Anthropic retired the pinned snapshot claude-opus-4-1-20250805 on 5 August 2026, naming Claude Opus 4.8 as the replacement. OpenAI retired the Assistants API on 26 August 2026, directing migration to the Responses and Conversations APIs.

Scheduled: OpenAI's deprecation table lists at least seventeen models retiring on 23 October 2026 — among them gpt-3.5-turbo-0125, gpt-4-turbo, gpt-4o-2024-05-13, o1-2024-12-17, o3-mini-2025-01-31 and six fine-tuned variants — with migration targets named as gpt-5.6-sol, gpt-5.6-terra and gpt-5.6-luna. A second block follows on 11 December 2026, covering gpt-5-2025-08-07, gpt-5-mini, gpt-5-nano, gpt-5-pro-2025-10-06, o3-2025-04-16 and o3-pro-2025-06-10.

What this changes

A pinned model identifier has been treated in most engineering organisations as a stable configuration value. These tables reclassify it as a dependency with a published end-of-life, and the October date puts a mass migration inside the same quarter as most year-end changes.

The operational difficulty is not swapping a string. It is that prompts, tool-calling behaviour, output formats and evaluation baselines are all fitted to a specific model. A forced migration invalidates the evaluation evidence behind whatever sign-off allowed the system into production.

Fine-tuned variants deserve separate attention. Six are in the October block, and a fine-tune is not portable to a successor model — it has to be rebuilt and revalidated on the new base, which is a training and evaluation exercise rather than a configuration change.

How to prepare

Inventory first: every model identifier in production, staging and scheduled jobs, including those inside vendor products and agent frameworks rather than only in code you wrote. Then map each to its published retirement date, and treat anything before 31 December 2026 as committed work.

Re-run acceptance evaluations against the named successor before the date rather than after. Where a system carries a regulatory or contractual quality claim, the evaluation evidence has to be regenerated, not inherited.

Questions for an engineering board

1. Which production systems name a model retiring on 23 October, and who owns each?
2. Which of our fine-tuned models are in that block, and have we budgeted the retraining?
3. Do we have a standing process that reads vendor deprecation tables, or did we learn these dates from a briefing?

Sources and scope

Retirement dates, model identifiers and named migration targets are from vendors' own published deprecation documentation: OpenAI, Anthropic and Mistral.

Three limits apply. These pages are live and mutable, the October and December dates are published plans rather than completed events, and OpenAI has extended such dates before. Anthropic's retirement dates bind Anthropic-operated platforms only; Amazon Bedrock and Google Vertex set their own schedules for the same models. This briefing makes no claim about the capability or pricing of the successor models — the deprecation tables establish that gpt-5.6-sol, gpt-5.6-terra and gpt-5.6-luna exist and are the named targets, and nothing further about them survived independent verification. The operational framing and the preparation sequence are ByteNib editorial analysis.

Continue exploring: AI & Machine Learning analysis, the related implementation tutorial, and the structured learning path.