Plan around AI that keeps improving

You picked a model, wrote a prompt that worked, wired it into something that runs without you, and moved on to actual work. Since then there have been four or five releases you half-registered from a newsletter, each one apparently better than the thing you are using. You have not tested any of them, because there is no natural moment to, and the vague guilt about that sits alongside a vaguer worry that one day the thing you built will simply stop.

The second worry is the real one, and it is the one with a fix. The improvement everyone talks about does not reach a small business as a headline. It reaches you as a dated notice that the model you depend on is being switched off, usually with a suggested replacement and a deadline attached. That makes it a scheduling problem rather than a strategy problem, and scheduling problems are tractable. This guide is for someone with at least one thing running on a named model without a person watching each run. If your entire use of AI is a person typing into a chat box, most of this does not apply and the last two sections are the only parts you need.

Improvement arrives as a retirement date

Every major vendor publishes a deprecation page, and it is the least-read useful page in the industry. Anthropic’s lists four lifecycle states, and the last one is blunt: a retired model is no longer available for use, and requests to it will fail [1]. Not degraded, not slower. Failing.

The history on that page is a rhythm rather than a scattering. Claude Sonnet 4 and Claude Opus 4 were deprecated on 14 April 2026 and retired on 15 June 2026 [1]. Claude Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August 2026 [1]. Claude Sonnet 3.7 was deprecated on 28 October 2025 and retired on 19 February 2026 [1]. OpenAI’s page shows the same shape: the GPT-5 snapshots and o3 were deprecated on 11 June 2026 with a shutdown date of 11 December 2026, and the recommended replacements are the GPT-5.6 models [2]. Google shut down gemini-2.0-flash on 1 June 2026 and points users at gemini-3.6-flash; the lite variants went the same day, pointed at gemini-3.1-flash-lite [3].

The forward-looking rows matter more than the history. Anthropic lists a tentative retirement for claude-sonnet-4-5-20250929 of not sooner than 29 September 2026, for claude-haiku-4-5-20251001 of not sooner than 15 October 2026, and for claude-opus-4-5-20251101 of not sooner than 24 November 2026 [1]. If one of those strings is sitting in a Zapier step or an n8n node you set up last winter, you have a date, and the first one is inside a month. Finding that out costs half an hour, once. Not finding it out costs you a morning of confused debugging on a day you did not choose.

The notice you get is a product feature, and it varies by an order of magnitude

Nobody shops on deprecation policy, which is a shame, because the policies differ enough to change what you should build on.

Anthropic commits to at least 60 days of notice before retiring a publicly released model, and notifies customers with active deployments [1]. OpenAI commits to at least 6 months for generally available models, at least 3 months for specialised variants such as chat, Codex and deep research versions, and says preview models may be retired with much shorter notice, giving 2 weeks as its example [2]. Google takes a different approach again: the shutdown dates in its table are described as the earliest possible dates on which a model might be retired, with the exact date communicated to users in advance [3]. Several of its rows sit exactly one year after release, with gemini-3.1-flash-lite released on 7 May 2026 and listed for shutdown on 7 May 2027, and gemini-2.5-flash-image released on 2 October 2025 and listed for 2 October 2026 [3]. Older rows ran longer: gemini-2.0-flash was released on 5 February 2025 and shut down on 1 June 2026 [3].

Sixty days and six months are both survivable. Two weeks is not, if the thing that breaks is how you invoice. OpenAI says so itself, in the same document that lists the preview models: it does not recommend them for business-critical production workloads unless you can migrate on short notice [2]. Read that as written rather than as boilerplate. Preview access is a different contract from general availability, and the good demo you saw is not evidence about the contract. Use previews for the work where a failure means you go and do something else that afternoon.

Pin the version you tested, and keep the name in one place

There is a second, quieter version of this problem, where nothing gets switched off and your output changes anyway.

Model IDs are not all the same kind of string. Anthropic’s versioning documentation explains that an alias such as claude-sonnet-4-5 points to the most recent dated snapshot for that minor version, which means the thing behind it can move [4]. From the 4.6 generation onward the convention changed, and the same page is explicit that a dateless ID such as claude-sonnet-4-6 is not an alias but the snapshot itself, that it maps to a single fixed model snapshot, and that Anthropic does not update the weights or configuration of an existing model ID [4]. Two strings that look identical in style can therefore behave in opposite ways. You need to know which kind you typed, and the only way to know is to read the versioning page for the vendor you use rather than assuming the convention you learned last year still holds.

Upgrading is also not only a question of output quality, because the surface around the model moves too. Anthropic has deprecated the temperature, top_p and top_k parameters, and setting one to a non-default value now returns a 400 error on Claude 4.7 and later models [1]. The 1M token context window beta was retired for Claude Sonnet 4.5 and Claude Sonnet 4 on 30 April 2026, and fast mode was removed for Claude Opus 4.6 on 29 June 2026 [7]. A migration that you assumed was a one-word change in a config file can turn out to require deleting three arguments and rethinking one assumption.

Which leads to the only piece of engineering advice in this guide. The cost of every future migration is roughly the number of places the model name appears, multiplied by the time it takes to retest each one. Reduce the first number now, while nothing is on fire. One value in one configuration file, or one variable in one automation, read by everything else.

The replacement is usually cheaper than the thing it replaces

The fear underneath most of this is that the treadmill costs money. On the published rate cards, the opposite has been true within a tier.

Claude Sonnet 4.5 and Sonnet 4.6 are listed at $3 per million input tokens and $15 per million output. Claude Sonnet 5, the model that supersedes them, is $2 and $10 [5]. Every Opus release from 4.5 through 5 sits at the same $5 and $25 [5], and Anthropic’s release notes record Claude Opus 4.7 arriving on 16 April 2026 at the same $5 and $25 pricing as Opus 4.6 [7]. On OpenAI’s card, the short-context rate for GPT-5.6 Luna is $0.10 input and $0.60 output, against $5 and $25 for GPT-6 Astra [6]. That is 50 times cheaper on input and about 40 times cheaper on output, on the same page, on the same day. The cheap tier is where a small business does most of its work, and it is the tier where the difference is easiest to bank.

Promotional rates are the exception, and they carry a date. OpenAI says GPT-5.6 Sol’s promotional pricing is available at least through 21 November 2026 [6]. Sometimes that date passes and nothing bad happens: Anthropic had scheduled Claude Sonnet 5 to rise from $2 and $10 to $3 and $15 on 1 September 2026, then cancelled the increase on 10 August and made the introductory price standard [7]. You cannot plan on it going your way. Both vendors also charge for where the tokens are processed rather than only for the tokens. Anthropic applies a 1.1x multiplier on Claude 4.6 and later models when you request US-only inference [5], and OpenAI adds a 10% uplift on regional processing endpoints for eligible models released on or after 5 March 2026 [6]. Build a budget on a promotional rate and you have built a budget with an expiry date on it.

None of this means you should chase every release. It means the migration you are dreading is, on the evidence of the published prices, more likely to reduce your bill than raise it, and that the thing standing between you and the saving is not the vendor. It is the number of places you hardcoded a model name.

Retest on the vendors’ calendar, not on how you feel

Here is the trap that costs the most and shows up on no invoice. You try a task, the model cannot do it, you file it under “AI can’t do that,” and your opinion freezes on that day. Eighteen months later it is wrong and you have no way of knowing, because nothing prompts a recheck.

Retesting on every release is not available to you. Anthropic’s release notes list Claude Opus 4.7 on 16 April 2026, Claude Opus 4.8 on 28 May, Claude Fable 5 and Claude Mythos 5 on 9 June, Claude Sonnet 5 on 30 June, Claude Opus 5 on 24 July, and Claude Fable 5.1 and Claude Mythos 5.1 on 1 September [7]. That is six launch dates in about 20 weeks, from one vendor. Nobody running a business is re-evaluating on that cadence, and anyone who tells you they are is not doing much else.

The workable cadence is the one the vendors already wrote for you. The retirement dates on your own models are a schedule that is specific to you, sparse enough to honour, and impossible to argue with. When a deprecation notice lands on something you use, that is your prompt to test the recommended replacement, and also your prompt to retry the two or three tasks you gave up on. Both things happen in the same sitting, which is the only reason the second one ever happens at all.

Make that sitting cheap. Keep a folder of 20 to 50 real inputs, the awkward ones included, next to the outputs you accepted at the time. Rerunning a saved set against a new model is mechanical work you can do while distracted. Reconstructing what you tested from memory is not, and it is what you will do instead if you do not save them now. Write down what failed and why, so that next time you are comparing against a record rather than a feeling about a Tuesday in 2025.

Inside a tool, the model is not yours to pin

Most of the AI a small business uses is not called through an API at all. It is a feature inside something else, and there the version control described above does not exist.

Notion states that it currently uses large language models hosted by Notion as well as by organisations such as Anthropic and OpenAI, and that it continuously evaluates providers and their models to provide the highest quality experience [8]. That is a fair and honest description of how these features are built, and it also means there is no model ID for you to pin, no deprecation table to read, and no 60-day notice coming. The thing that wrote your summaries in March may not be the thing writing them in October, and you will not be told.

The protection is different in kind. Keep the inputs and the outputs you rely on outside the tool, in a format you can export, so that a change in quality is something you can actually notice rather than something you slowly adapt to. Spot-check the same handful of tasks every couple of months on a date you set yourself. And be honest about where you are getting the value, because if the value is the model rather than the workflow around it, you are one silent swap away from paying for something you no longer want.

What still goes wrong

The dates are softer than they look, in both directions. Anthropic’s forward rows say “not sooner than” [1], and Google says outright that its listed shutdown dates are the earliest possible ones [3]. A calendar built from those pages gives you a floor, not a plan, and the actual notice can arrive earlier than you expected on something you did not think of as load-bearing. The commitments also have scope conditions worth reading twice: Anthropic’s 60 days covers publicly released models [1], and OpenAI’s 6 months covers generally available ones, with specialised variants at 3 months and previews explicitly outside that [2]. The tier you were quietly relying on may not be the tier the promise covers.

A saved test set only catches what you thought to save. A new model can be better on average and worse on the one input that matters most to you, and no release note will mention it, because the vendor has never seen your data. That is an argument for keeping the awkward cases in the set rather than the representative ones, and for accepting that some regressions will reach you as a customer complaint no matter how disciplined you are.

Then there is the honest limit on the whole exercise. Most solo operators have one or two automations where any of this pays, and a chat subscription where none of it does. If your AI use is a person typing into a box and reading what comes back, the retirement of a model ID will reach you as a changed dropdown and nothing else. Building version governance for that is worse than doing nothing, because it converts a non-problem into a recurring chore. Do the half hour on the things that run unattended. Leave the rest alone.