Skip to content
AI Article

Your LLM Will Be Dead in 18 Months. Plan for It.

Frontier model lifespans have collapsed to about a year, and your eval suite is the only contract that survives.

Rachel Goldstein
Rachel Goldstein
Dev Tools Editor · Aug 20, 2026 · 5 min read
Your LLM Will Be Dead in 18 Months. Plan for It.

Windows 10 got ten years of support before Microsoft pulled the plug in October 2025. Claude Opus 4.1 got exactly twelve months: released August 5, 2025, retired August 5, 2026. Gemini 1.5 Pro 002 got twelve months too — launched September 24, 2024, shut off September 24, 2025, to the day. GPT-4.5 barely got five: it appeared in the API in late February 2025 and was gone by July 14.

That's not a run of bad luck. It's the new baseline. If your product calls a frontier model, you're building on the most perishable dependency in your stack, and the lifecycle math is now closer to a food label than a support contract.

The actual numbers

The published policies are worth reading, because they're shorter than you think. OpenAI's deprecation page promises at least six months' notice for generally available models, three months for specialized variants, and as little as two weeks for previews. Anthropic's policy guarantees 60 days' notice before retirement, and its docs list new models with tentative retirement dates about a year out from launch. Azure AI Foundry codifies the floor explicitly: GA model versions get a minimum of 12 months, plus a six-month grace period for existing deployments.

Look at the retirement tables rather than the policies and the picture tightens further. Claude Sonnet 3.7 shipped in February 2025 and was retired in February 2026. Claude Sonnet 4 and Opus 4, both May 2025 releases, were gone by June 2026. On the OpenAI side, gpt-3.5-turbo — scheduled for shutdown this October — will die as one of the longest-lived API models ever at roughly three and a half years, and that's the outlier, not the norm.

Compare that to the platforms we grew up on. Ubuntu LTS gets five years of standard support. RHEL gets ten. Android APIs stay callable for years after deprecation, and when they finally break you got warnings across multiple annual releases. Model lifespans aren't slightly shorter than OS lifespans; they're five to ten times shorter, with a tenth of the ceremony.

Why your dependency instincts don't transfer

Every reflex we've built for dependency risk fails here, and it's worth being precise about why.

You can't pin. A dated snapshot like claude-sonnet-4-20250514 looks like a lockfile entry, but the artifact lives on someone else's GPUs and gets deleted on their schedule. Pinning buys you stability between now and the retirement date — nothing after.

You can't vendor. There's no node_modules for a proprietary model. When it's gone, it's gone. (Anthropic has committed to preserving model weights and hopes to make past models available again someday — notable as the first real acknowledgment of the problem, but not something you can build a migration plan on today.)

And the replacement isn't backward-compatible in any meaningful sense. The API shape is identical; the behavior isn't. The designated successor is better on the provider's benchmarks and different on your workload — it formats JSON differently under pressure, follows your system prompt more literally, refuses things the old model didn't. A library upgrade breaks loudly at compile time. A model swap breaks quietly, in production, in the 4% of cases your prompt was accidentally load-bearing.

This is the point the GoodBarber engineering team lands on in the essay that prompted this piece, and it's the right one: the teams that handle retirements calmly are the ones for whom a swap is a rehearsed move, not an emergency.

What the survivors actually do

The pattern that works has three parts, and none of them are exotic.

Model IDs live in config, mapped per task. Not one global MODEL env var — a catalog, where each pipeline step names its own model and can be repointed independently:

tasks:
  summarize_ticket:   {model: claude-haiku-4-5, max_cost_per_call: 0.002}
  generate_migration: {model: gpt-5,            max_cost_per_call: 0.15}
  classify_intent:    {model: gemini-2.5-flash, max_cost_per_call: 0.001}

When a retirement notice lands, the blast radius is one line, not a codebase grep. A gateway like LiteLLM or OpenRouter gets you the routing layer for free, though it adds its own dependency to reason about.

The eval suite is the contract, not the model ID. This is the real shift. You can't freeze the model, so you freeze the standard: a battery of task-specific checks — golden outputs, format validators, refusal-rate thresholds — that any candidate model must pass. Prompts get rewritten per model family; the bar doesn't move. Teams without this are doing vibes-based migration under deadline, which is how a "designated replacement, allegedly better" quietly degrades a feature for a quarter.

Migrations are scheduled, not triggered. If you use models from two or three providers, the arithmetic says you'll do a forced migration roughly every quarter. Budget it like patch Tuesday. The teams in trouble are the ones treating each notice as a surprise.

The escape hatch, if you need one, is open weights: a Llama or Mistral checkpoint you host never retires. You trade the deprecation treadmill for an ops burden and a capability gap, which is a good trade for stable, well-bounded tasks and a bad one at the frontier.

Don't expect this to improve much

The retirement pace isn't carelessness — it's capacity economics. Anthropic says outright that it retires models to free serving capacity for new ones; every deprecated model held alive is GPU fleet not serving the flagship. Azure's 12-month floor and Anthropic's weight-preservation pledge show enterprise pressure is buying a floor, but nobody is going to promise Ubuntu-length support for a 2025-vintage model while the frontier moves this fast. The vendors with ten-year-support DNA (Microsoft, AWS Bedrock) will keep selling longer runways at enterprise prices; that's a feature tier now, not a default.

So the fix lands on your side of the API. If your model IDs are hardcoded and your regression suite is "we tried a few prompts," the next retirement email is an incident. If models are catalog entries and your evals are the contract, it's a Tuesday. Eighteen months into this cycle, that's no longer an architecture opinion — it's the difference between teams that ship through retirements and teams that get shipped by them.

Sources & further reading

  1. Models retire faster than operating systems — dev.to
  2. Deprecations - OpenAI API — developers.openai.com
  3. Model deprecations - Claude Docs — platform.claude.com
  4. Azure OpenAI in Microsoft Foundry Model Retirements — learn.microsoft.com
  5. Commitments on Model Deprecation and Preservation — anthropic.com
  6. Vertex AI release notes - Generative AI on Vertex AI — docs.cloud.google.com
Rachel Goldstein
Written by
Rachel Goldstein · Dev Tools Editor

Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop.

Discussion 0

Join the discussion

Sign in or create an account to comment and vote.

No comments yet

Be the first to weigh in.

Related Reading