Maintained reference · Checked August 13, 2026
AI model launch and retirement timeline: names change, dependencies remain
A source-linked history of major GPT, Claude, and Gemini milestones, plus the lifecycle vocabulary and migration checklist builders need when a model changes underneath a product.
Michael Okeje
AI model lifecycle and developer research · Last updated August 13, 2026
Why a model timeline is a product reliability tool
AI model names feel like product names, but they behave more like software dependencies. A provider announces a model, exposes it through one or more products, changes an alias or snapshot, introduces a replacement, and eventually removes an identifier. The dates matter, but the lifecycle matters more. A model can be impressive and still be the wrong dependency if your application cannot reproduce its behavior, observe its cost, or migrate before a shutdown.
This timeline is designed as a reference layer, not as a claim that one family is permanently best. The major milestones help explain the shape of the market: multimodality, long context, reasoning, tool use, coding, and agent workflows became increasingly important. The source links point to provider announcements and documentation. For current names, prices, and retirement dates, always open the live provider notice because those details change faster than an evergreen article should pretend.
I recommend keeping two records. The first is a public timeline that helps readers understand what changed. The second is an internal dependency inventory that tells a builder exactly which production feature uses which model identifier, with what fallback, budget, schema, and evaluation. The public record earns authority; the private record prevents an announcement from becoming a surprise outage.
Major milestones and what they changed
| Period | Milestone | Builder implication |
|---|---|---|
| 2023 | GPT-4, Claude 2, and Gemini's public-era competition made general-purpose chat and API model selection a recurring product decision. | The lesson for builders was to separate a product feature from a single model and to record the exact model identifier used. |
| 2024 | GPT-4o, Claude 3 and 3.5 families, and Gemini 1.5 expanded multimodality, long context, coding, and lower-latency use cases. | The boundary between a text model, a vision model, a realtime model, and a product assistant became less tidy. |
| 2025 | Claude 4 launched on May 22, Gemini 2.5 was introduced on March 25, and GPT-5 launched on August 7, with reasoning, tool use, coding, and agent workflows becoming central themes. | “Model quality” increasingly included how a system used tools and worked through a task, not only one response. |
| 2025-2026 | Providers continued to add model variants, reasoning modes, coding products, agent SDKs, context features, and specialized endpoints, while older identifiers entered deprecation cycles. | A model catalog became a lifecycle system: launch, preview, stable use, replacement, deprecation, and retirement. |
| Now | The durable practice is to maintain a source-linked inventory and test replacements against real tasks instead of treating a model name as a permanent dependency. | The timeline should be updated from provider announcements and documentation, not copied from a static list. |
GPT-5's August 7, 2025 launch is a useful example of why launch descriptions need context. OpenAI described a unified system with fast responses, deeper thinking, and routing behavior, while developers received API models and new capabilities for coding, tool use, and agentic tasks. A buyer reading only the headline “GPT-5” might miss that the practical choice still includes model variant, reasoning effort, endpoint, rate limits, and application design.
Anthropic's May 22, 2025 Claude 4 announcement similarly bundled model releases with extended thinking, tool use, parallel tools, Claude Code, and new API capabilities. That is not merely a new number. It changes what builders can attempt and what they must evaluate. A workflow that depends on tool calls should record the tool behavior and trajectory, not only the final answer.
Google's March 25, 2025 Gemini 2.5 announcement emphasized thinking models and later updates expanded the family and availability. The lesson is not that a provider's benchmark claim should be ignored. It is that a model family often contains different latency, cost, context, and capability choices. Compare the endpoint and task configuration that your users actually receive.
By 2026, the catalog problem is operational. A team may use a consumer assistant, an API model, a cloud-hosted variant, a coding product, an embedding endpoint, a speech model, and a vision model from several providers. “We use Claude” is not a dependency record. A useful record names the route, model ID, purpose, input type, output contract, owner, and retirement risk.
The timeline should also distinguish launch from impact. A release announcement may contain impressive benchmark gains, but users experience the model through a product surface, plan, quota, prompt, tool configuration, and latency budget. A model can be better on a benchmark and worse for a particular workflow because it changes formatting, refuses a previously allowed task, costs more, or takes longer. Historical context helps readers understand what changed; local evaluation tells a team whether the change helps.
That is why this page is intentionally modest about rankings. It records milestones and the engineering consequence of each period. It does not declare one provider the permanent winner. The useful reference is the one that helps a reader ask better questions: what exactly launched, where is it available, what does it replace, what changed in the contract, how will we test it, and what is the retirement plan if it disappears?
For readers who cite this page, the source discipline is part of the value. A date should point to the provider's announcement or documentation, not a recycled social post. A retirement claim should point to the deprecation notice. A capability claim should say whether it belongs to a model, an application, or a tool-enabled configuration. That separation keeps a timeline useful months after the launch headline has stopped trending.
Use the timeline as a starting point for verification, not as permission to skip the original provider documentation.
The dates are useful only when they lead to better decisions for real users and maintainers.
How to read a model announcement before changing production
A launch post is written to explain what is new. A migration decision needs to discover what is different, what is supported, and what could break. I use the following reading order when a provider publishes a new model or retirement notice.
Identify the surface
Ask where the announcement applies: a consumer app, an API endpoint, a cloud marketplace, a coding product, or more than one. The same family name can refer to different access rules, context limits, tools, and billing units. Copy the exact route and model identifier into your dependency record.
Separate capability from contract
A provider may describe better reasoning, vision, coding, or tool use, but your application depends on a contract: input types, output format, schema behavior, refusal behavior, rate limits, latency, and error responses. List the contract changes that could affect your feature before celebrating the benchmark change.
Find the lifecycle language
Look for terms such as preview, experimental, recommended replacement, deprecated, shutdown, alias, snapshot, or end of life. They are not interchangeable. A preview can change without a retirement date; a deprecation notice creates an engineering deadline even if requests still succeed.
Locate the migration evidence
Read the provider's migration guide, release notes, pricing page, and deprecation documentation together. A replacement may need a new SDK, a different parameter, a changed system prompt, a new tool schema, or a different context strategy. The launch post alone rarely contains the complete migration surface.
Write the decision down
Record why the team will adopt, test, delay, or reject the change. Include the owner, affected features, evaluation set, budget impact, deadline, and rollback plan. A source link without an explicit decision becomes a bookmark, not operational knowledge.
This sequence also protects editorial accuracy. It prevents a timeline from turning an announcement into an unsupported statement about general availability, price, or capability. When a detail applies only to one endpoint or account tier, say so. When the provider has not published a retirement date, do not invent one; mark the status as unannounced and set a date to recheck the official documentation.
The lifecycle vocabulary
Use precise words in product tickets, documentation, and procurement conversations. “The model changed” is too vague to guide a migration.
Announcement
The provider introduces a capability or family. Claims may describe evaluations, intended use, and access paths, but availability can be staged.
Preview
The model is available to selected users or under terms that allow changes. Treat output and pricing as provisional and avoid irreversible dependence.
General availability
The provider presents the model as broadly supported. Read the exact API, region, quota, safety, and contract details rather than assuming every surface is identical.
Version change
A snapshot, alias, system behavior, price, context limit, or tool contract changes. A patch may be harmless or may require an evaluation and prompt update.
Deprecation
The provider recommends migration and usually publishes a shutdown date or replacement path. Create a tracked migration issue immediately.
Retirement
The identifier or endpoint stops serving requests. A fallback that was never tested is not a fallback; it is an outage plan written in hope.
What a retirement notice should trigger
A retirement notice is not a link to forward to engineering and forget. It is a change-management event. Assign an owner, identify the customer impact, estimate the migration work, and create a deadline earlier than the provider's shutdown. The replacement may change output structure or refusal behavior even when it has a similar name.
- Inventory model IDs, aliases, provider routes, SDK defaults, environment variables, prompt templates, evals, and documentation references.
- Record which features depend on structured output, tool calling, vision, audio, long context, reasoning, citations, JSON schemas, or provider-specific behavior.
- Read the exact provider notice and distinguish retirement, deprecation, alias movement, pricing change, and temporary availability issue.
- Create a representative evaluation set from successful, ordinary, difficult, multilingual, long-context, and refusal cases in your own workflow.
- Run the replacement beside the current model. Compare correctness, format validity, safety, latency, cost, escalation, and user edits.
- Canary the replacement for a small share of traffic and log the model identifier and usage fields for every result.
- Update prompts, parsers, tool definitions, retry logic, budgets, and customer documentation when the new model needs different handling.
- Keep a rollback window and remove the retired dependency only after production evidence and monitoring show the migration is stable.
For the evaluation layer, use our AI evaluation guide. For cost changes, see how AI model pricing works and the current pricing reference.
Rehearse the migration before you need it
A dependency review should end with a rehearsal, not just a spreadsheet update. Ask these questions with the engineer, product owner, support lead, and budget owner in the room. A “no” is useful: it identifies the work that makes the fallback real.
The goal is not to preserve identical wording across providers. It is to preserve the customer outcome, the safety boundary, and the team's ability to explain what happened. Treat a model replacement as a controlled product change with evidence, not as a string substitution in an environment variable.
A minimal dependency record
The downloadable table is a starting point for a maintained research or engineering inventory. Add your own routes, aliases, owners, and retirement notices rather than treating this public timeline as a substitute for an internal catalog.
The record can live in a spreadsheet, repository, or service catalog. Its value comes from being current and connected to the code that makes the call. Include it in launch review for new AI features and in quarterly dependency review for existing ones.
Frequently asked questions
What is the difference between an AI model launch and general availability?
A launch announcement is the provider's public statement. A preview may be limited, experimental, or subject to change. General availability usually means the provider considers the model ready for a broader supported use, but access, regional availability, rate limits, and product surfaces can still differ.
What does it mean when an AI model is deprecated?
Deprecation means a provider has announced that a model or endpoint should no longer be used and may have a future shutdown date. A deprecated model may continue responding temporarily, but builders should migrate, test the replacement, and remove reliance before the stated retirement date.
Do model aliases always point to the same model?
No. An alias or rolling version can change its underlying snapshot, behavior, price, context window, or safety characteristics. Pin a version when reproducibility matters, monitor provider notices, and run evaluations when an alias changes.
Why do model benchmarks not tell me which model to use?
Benchmarks measure selected tasks under selected conditions. Your workflow may depend on instruction following, structured output, latency, tool calls, citations, language, cost, safety, or long-context behavior that the headline benchmark does not capture. Evaluate the model on representative cases from your own work.
How should I prepare for an AI model retirement?
Inventory every model identifier and alias, identify affected features, read the provider notice, select a replacement, run a representative evaluation, compare cost and latency, canary the new version, update prompts and schemas, and keep a rollback or fallback route until production evidence is stable.