10 min read Requalification

Eleven models in eleven days: none of those releases forces you to requalify

Eleven models in eleven days: none of those releases forces you to requalify

Between 1 and 11 September 2026, eleven models shipped from seven providers. Anthropic opened with Claude Fable 5.1 on the 1st, Google published Gemini 3.8 Flash on the 2nd, Meta shipped Muse Spark 1.3 the same day, OpenAI released GPT-6 Astra on the 3rd, then two image models on the 8th, DeepSeek V4.1 Flash on the 10th and Sakana AI two Fugu variants on the 11th. The count comes from the release ledger maintained by LLM Gateway, updated 11 September. On 6 September, CNBC put a name to the effect on buyers, model fatigue, and reported Sam Altman acknowledging a general shift to faster cadences.

The reflex reading is that you need a better method for picking from this stream. That misses the point. Not one of those eleven releases creates an obligation. Nothing breaks in production because a model was announced, and a pinned identifier keeps answering exactly as it did the day before. What creates an obligation is a retirement date placed on the model you are already running. On 1 September, the day Fable 5.1 shipped, GitHub Copilot retired six models. The notice was dated 31 July.

Two calendars run in parallel. The release calendar is loud, permanent and carries no deadline. The retirement calendar is quiet, dated and enforceable. Most of a team's evaluation budget goes into the first one. The 1 September article on the vendor notice period that became the real calendar dealt with the forced exit from a model. This one deals with the voluntary entry into the next, which is to say the right not to requalify.

Two horizontal timelines, one dense with unmarked points, the other carrying four sharp deadlines and a stop point.
Two calendars run in parallel. Only one carries an enforceable date.

Eleven releases in eleven days, and zero obligation

The LLM Gateway ledger tracks 385 models from 55 providers since 2022, 141 of them in 2026 alone. The early-September cluster is therefore not a volume anomaly, it is a synchronisation anomaly: four frontier labs in three working days, each with its post, its benchmark page and its comparison against the previous generation.

What that cluster produces for a buyer is an attention cost, not a production cost. No contract is broken, no interface changes, no invoice moves. The only mechanical effect of a release is that a vendor now has a newer model to recommend when it retires the old one, which is a consequence rather than a cause.

The trap lies in how the information arrives. A release is pushed: post, email, social feed, press coverage within hours. A retirement is pulled: one line in a changelog, one row in a documentation table, sometimes an email to the billing address. The first category saturates the attention of teams with no decision to make. The second lands on people who do have a decision to make, and a deadline for making it.

The date that binds you is in no release announcement

On 31 July 2026, GitHub published a changelog entry deprecating six models on 1 September across every Copilot surface, chat, inline edits, ask and agent modes, completions: Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6 and Raptor Mini. Thirty-two days of notice. The post states that Copilot Enterprise administrators may need to enable access to the replacement model themselves through their model policies, which means reading the announcement is not enough: someone has to act before the date, or developers face a picker that no longer offers anything equivalent.

On the model vendor side, the information is even more available and even less read. Anthropic's deprecation page publishes, for each active model, a floor retirement date phrased as "not sooner than". As of 13 September 2026, the claude-sonnet-4-5-20250929 snapshot carries a floor of 29 September 2026 and claude-haiku-4-5-20251001 a floor of 15 October 2026, sixteen and thirty-two days out. The same page commits to at least sixty days' notice before any publicly released model is retired, and documents the console CSV export listing usage broken down by API key and by model.

Those three elements are enough to build the full horizon of your estate without waiting for any announcement: the list of identifiers actually being called, the published floor against each one, the contractual notice period on top. That data is available today, free, and depends on no monitoring effort at all.

The vocabulary of the lifecycle

Requalification: putting a model back through the evaluation set that authorised it for production, because the model or its usage context has changed. Distinct from initial qualification, which dealt with an unknown model.

Deprecation: the model still works but is no longer recommended, and a retirement date is assigned to it. Retirement: calls fail. Between the two sits working time, and it is the only time you have.

Snapshot and alias: a snapshot is a dated, reproducible identifier with its own published retirement date. An alias points at the most recent version in the family and therefore changes underneath you without your code moving.

Residual lifetime: the time left between today and a model's floor retirement date. It applies as well, and above all, to the model you are considering migrating to.

Diagram contrasting a release calendar with no date against a retirement calendar carrying an enforceable deadline.
The loud calendar carries no deadline. The quiet one carries one per model.

The 31 July post did not merely announce six retirements, it recommended targets. Gemini 3.1 Pro was to give way to Gemini 3.6 Flash. Claude Opus 4.5 and Opus 4.6 pointed to Opus 4.7, Opus 4.8 or Opus 5. Raptor Mini pointed to MAI-Code-1-Flash.

On 3 September, two days after the deadline, GitHub published a second deprecation wave dated 2 October. It takes out Gemini 3.6 Flash and Claude Opus 4.7, which is to say two of the targets recommended five weeks earlier. On 10 September, MAI-Code-1-Flash received its own deprecation notice in turn. Of the four targets named in the 31 July post, three were deprecated before September was over.

A team that followed the official recommendation to the letter therefore did the work twice in five weeks, and finds itself on 13 September with a migration to redo within nineteen days. A team that had already picked a long-horizon target, Claude Opus 5 or Claude Sonnet 5 for instance, did it once. The difference between the two is not the quality of the technical evaluation, it is a criterion almost no model policy writes down: the residual lifetime of the target.

In the field, that criterion is missing for a structural reason. In organisations that do have a written model policy, it describes how to choose a model and says nothing about the conditions under which you are entitled not to change one. And the person receiving the deprecation notice, often a platform administrator or the billing address, is not the person who signed off the production release nor the one who will hold the calendar. The deadline arrives through a channel with no named owner.

Five triggers, and a default of no

A useful requalification policy starts with its default value. By default, you do not requalify. A model release, a public benchmark score, press coverage or a salesperson's request are not triggers. Five situations, and only five, open the right to spend evaluation budget.

The first is an announced deprecation, or a floor retirement date closer than a threshold you set once and for all, on a model genuinely called in production. It is the only trigger that produces a dated obligation, and it is monitored in a table, not in a news feed.

The second is an interface break on the path you actually use, not on the API in general: a parameter that now returns an error, a changed tool-call format, a reasoning block no longer readable by earlier versions. Anthropic, for example, made temperature, top_p and top_k rejected above their default value on Claude Opus 4.7 and later models, with a 400 error attached. That kind of change is qualified by reading the migration note, not by relaunching a full evaluation campaign.

The third is a measured gain above a threshold you wrote down before looking at the results, and measured on your own evaluation set. A threshold decided afterwards is not a threshold, it is a justification. This extends directly from the qualification grid for an unknown model set out on 28 August, applied this time to a model whose author you already know.

The fourth is a price change beyond a threshold, calculated on your real token mix rather than on the list rate. Fable 5.1 shows why the distinction matters: the list price stayed at ten dollars in and fifty out per million tokens, identical to Fable 5, while cache reads dropped to a quarter of their previous price. Anthropic estimates the reduction at roughly 25% on a typical workload and up to 45% on a heavily agentic one, per the summary VentureBeat published on 2 September. A workload that never reads from cache will see none of that reduction. An agentic workload will see most of it. The headline rate on its own settles nothing.

The fifth is a new compliance requirement, specific to your sector or jurisdiction, that makes the incumbent model unsuitable regardless of its performance.

To those five triggers, add two procedural rules. The migration target must have a published residual lifetime longer than your requalification cycle, failing which you pay twice. And every trigger must carry a budget costed in advance, in person-days and evaluation tokens, so the cost of the decision is visible at the moment it is taken.

What requalification costs when the system is classed high-risk

In a regulated context, changing model is not legally neutral. Article 43(4) of the European AI regulation provides that a high-risk system already subject to a conformity assessment procedure must undergo a new one in the event of a substantial modification, regardless of whether the modified system is intended for further distribution or continues to be used by the current deployer.

The same paragraph opens a door few teams use. Changes pre-determined by the provider at the moment of the initial conformity assessment, and included in the technical documentation, do not constitute a substantial modification. Put another way, a requalification policy written in advance and filed with the technical documentation is not merely internal hygiene: it is the artefact that can move a model version change from substantial modification to pre-determined change. Writing it after the fact does not produce that effect.

Two cautions. The obligation sits with the provider of the high-risk system, not with every user of a model, and the exact classification of your system is a legal question to handle with counsel. Separately, the Commission page publishing this article carries a notice stating that the provision has been amended by the Digital Omnibus on AI and that the displayed text does not yet reflect those amendments. The reasoning holds, the exact wording needs checking before it goes into a file.

To put in motion this week

Pull the list of model identifiers genuinely called in production, not the list of models authorised in your policies. At Anthropic, the CSV export on the console Usage page gives usage broken down by API key and by model. The gap between those two lists is often the first useful result of the exercise.

Put each identifier's published floor retirement date next to it, and sort by earliest deadline. If a snapshot you are still calling carries a floor less than ninety days out, you have a migration to plan, and it has nothing to do with last week's eleven releases.

Write the trigger policy on one page, with the default value asserted on the first line and the five triggers below it, each with its numeric threshold. Date it and have it approved by the same body that approves production releases, not by the team that watches the bill.

Before committing to any migration, check the published residual lifetime of the target. A target that expires before the end of your requalification cycle is not a target, it is an intermediate step you need to refuse explicitly.

Name an owner for the deprecation channel, with a receiving address that is not a billing inbox, and a fifteen-minute monthly review of the deadline table. It is the cheapest line in this whole list, and its absence explains most migrations done under pressure.

Conclusion

The labs' release cadence is not your problem, and it will not become one by speeding up your evaluations. Your problem is that the calendar which actually binds you is already published, model by model, in tables nobody has a mandate to watch, while your teams' attention is captured by a stream carrying no deadline at all. Writing down the right not to requalify, with numeric triggers and a default of no, costs one page and frees the evaluation budget for the few dates that are genuinely not negotiable.

Sources: As of September 2026

Godwin AVODAGBE