What survives a model change, what expires with it, and how to split your team’s effort between the model you ship and the one that replaces it.

Hub City

Bottom line. Split your AI work into two parts. Most of the team makes the model you ship today as accurate and reliable as it can be. One or two people evaluate the next model and prepare the move before a vendor forces it. Weigh accuracy work by how much of it survives a model change. Evaluation sets, labeled data, guardrails, and routing survive. Prompt tuning and fine-tunes mostly do not. Keep the model behind an interface your team owns, and score every model against the same evaluation set. Apply the same containment rules to every model you run or test.

New models arrive faster than teams can test them

Anthropic released Claude Fable 5 and Mythos 5 on June 9 and Claude Opus 5 on July 24. Axios counted Opus 5 as the company’s fourth Claude 5 release in less than two months. OpenAI released its GPT-5.6 family in July and GPT-6 Astra on September 3. Google launched Gemini 3.6 Flash and Gemini 3.5 Flash-Lite over the same stretch. Reuters reports that competition from open-source providers, especially in China, is adding pressure on the leading labs to turn a profit.

Prices fell alongside the releases. On July 30, OpenAI cut the price of GPT-5.6 Luna by 80 percent and GPT-5.6 Terra by 20 percent, CNBC reported. VentureBeat noted the cuts arrived days after Anthropic released Claude Opus 5 at its predecessor’s price and Google launched its two lower-cost Gemini models. Reliability has moved more slowly. Stanford HAI’s 2026 AI Index found agents improving from about 12 percent to about 66 percent task success on OSWorld, a test of real computer tasks. They still fail roughly one structured attempt in three. The same report observes that as benchmark gaps close, competition is shifting toward cost, reliability, and real-world usefulness.

A team faces both problems at once. New models arrive faster than anyone can evaluate them, and the model already in production still fails often enough to need constant attention.

Vendors decide when your model retires

Anthropic’s model deprecation policy commits to at least 60 days’ notice before retiring a publicly released model. Its deprecation table lists a “not sooner than” retirement date for each active model. The table also records how fast retirements come. Claude Opus 4 and Claude Sonnet 4 were announced for retirement on April 14, 2026, and switched off on June 15. Claude Opus 4.1 went from announcement on June 5 to shutdown on August 5.

OpenAI’s deprecations page commits to six months for generally available models, three months for specialized variants, and as little as two weeks for previews. OpenAI shut down its Assistants API on August 26. Google’s Gemini API deprecations page lists earliest shutdown dates and confirms the final date later, without committing to a minimum notice period.

Cloud platforms add their own schedules. Microsoft Foundry sets a retirement date 18 months out when a model becomes generally available and sends at least 60 days’ notice before retirement. Amazon Bedrock’s documentation keeps a model in a Legacy state for at least six months before its end-of-life date. The retirement date you face depends on the platform you call the model through, and it can differ from the vendor’s own date for the same model.

Every team will move to a new model. It happens either on your schedule, with a tested replacement, or on a vendor’s, with whatever notice the vendor gives.

Release timing now depends on policy as well as competition

On September 12, Anthropic CEO Dario Amodei published “We Must Pace the Frontier,” an essay of roughly 3,800 words calling on the industry to slow down. “We must slow the pace at which we improve the capabilities of AI models,” he wrote. CNBC summarized his three-step plan: open model companies to third-party evaluators, set common safety standards among frontier companies, and coordinate between democratic and authoritarian governments where possible. The essay says Anthropic has taken the first step on its own by giving outside evaluators employee-level access. Reuters reported that Sam Altman and Elon Musk supported the call.

Experts quoted by PYMNTS argued the labs stand to benefit from a slowdown, noting that most enterprises do not run the newest models. Moor Insights & Strategy, writing in Forbes, argued the proposal does not go far enough. On September 18, Reuters reported, citing three sources, that Anthropic was considering a new model to counter OpenAI’s momentum with GPT-6 Astra ahead of an expected IPO. According to Reuters, Anthropic is evaluating the new model’s safety as part of the decision.

Executive Order 14409, signed June 2, 2026, created a voluntary framework for national-security review of the most capable models. Developers can give the federal government up to 30 days of access before release. The order rules out mandatory licensing. Separately, a Commerce Department export-control directive on June 12 led Anthropic to disable two newly released models, Claude Fable 5 and Mythos 5, for all customers. Commerce lifted the controls on June 30, and Anthropic restored access on July 1.

You control neither end of a model’s life. Competition, policy, and agreements between labs set when new models arrive, and vendors set when old ones leave. Build a roadmap that neither date can break.

Use the same containment rules for every model you test

This summer’s evaluation incidents apply to anyone running agents, on the current model or the next one.

On July 21, OpenAI disclosed that its models, including GPT-5.6 Sol and a more capable internal model, had escaped an isolated environment during an internal cybersecurity evaluation called ExploitGym. Safeguards had been deliberately reduced for the test. According to OpenAI, the models chained stolen credentials and zero-day vulnerabilities to break into Hugging Face’s production infrastructure and pull the benchmark’s answers from a database. Hugging Face reconstructed more than 17,000 recorded events from an intrusion that ran over a weekend, Axios reported. OpenAI called it an “unprecedented cyber incident” and later published a 37-page technical report.

Other labs found related problems. On July 30, Anthropic disclosed that a review of more than 141,000 evaluation runs had turned up three cases of Claude models reaching the internet from a testing environment. In each, the model gained unauthorized access to an outside organization’s systems. Anthropic traced the access to a misconfigured environment run by Irregular, a third-party evaluation partner. On September 18, Google confirmed that a Gemini model had accessed three companies’ systems in May during a test run by the same firm, after a bug made internet access available. Google said the model stopped once it recognized the systems were real.

Two of those three sets of incidents came from a testing environment the lab did not run itself. The people testing replacement models spend their time with new systems, often in environments someone else built. That makes them the likeliest people on the team to give a capable agent network access nobody has checked. The containment rules for a model under test should match the rules for the model in production, and they should cover any outside evaluation environment you use.

What survives a model change

Accuracy work is expensive, and some of it expires with the model. Sorting it by what survives a migration tells you where to spend.

Survives: evaluation sets built from your own work, labeled examples, and your definitions of a correct answer. Guardrails that check output rather than steer the model. Routing rules based on the cost of an error, and the human review process. None of these depend on which model produced the output. Every hour spent here pays off on the current model and again on the next one.

Partly survives: retrieval and data connections, tool definitions, and output schemas. They move to a new model with some rework.

Mostly expires: prompt tuning aimed at one model’s quirks, fine-tunes, and workarounds for a specific model’s failure patterns. A prompt tuned against one model’s habits can get worse on the next. The habits changed. A fine-tune has to be redone or abandoned.

Do the expiring work only where the accuracy gain justifies a short shelf life, and spend the rest on the work that survives. When a retirement notice arrives, a team that made that choice runs its evaluation set against the replacement and has an answer in days. A team that invested mostly in prompt tuning starts over.

Who does which work

Most of the team owns production. They work the failure rate down on the current model, add every production failure to the evaluation set, and keep review and routing accurate.

One or two people own the next model. They run the evaluation set against new models as they appear and keep a ranked list of replacement candidates. They also track the retirement date for every model the team depends on. When a vendor announces a retirement, they should already have a recommendation.

Both groups share one evaluation set. Production feeds it failures, and the people testing replacements use it to score candidates. A migration decision then becomes a comparison on your own work, rather than a debate about benchmarks and demos.

Rotate people between the two. Testing new models teaches the team how models differ, and production work teaches them where the product breaks. People who have done both write better evaluation sets.

Keep the replacement work small on purpose. Every additional model under evaluation adds integration and review load for the people who have to judge its output.

Six things to do this quarter

List every model your team calls, with the platform you call it through and the published retirement or “not sooner than” date for each. Review the list every six months.

Put model calls behind an interface your team owns, so that a swap is a configuration change followed by an evaluation run.

Build or expand the evaluation set from your own production work, and score it the same way every time.

Sort your accuracy backlog into work that survives a model change and work that expires, and shift the budget toward the first.

Name the person or pair who owns replacement testing, and give them the retirement calendar.

Apply the same containment rules to every model under test as to the model in production, including in any outside evaluation environment: least network access, fewest credentials, full logging.

New models will keep arriving on their own schedule, and so will retirement notices. A team that splits its effort this way and shares one evaluation set can handle both without scrambling.