Should you wait for the next model before starting your AI project?

No. Start now, and build it so the model is the easiest part to change. Over the last twelve months the three frontier labs shipped roughly one new model a fortnight, and each of them will be retired within a year or two of launch. If your project only makes sense with a model that doesn't exist yet, it isn't an AI project. It's a wish.

I hear the question in a particular tone: sensible, cautious, slightly relieved. "We're going to hold off until the next big release, let things settle down a bit." It sounds like prudence, and it has the same logic as never buying a laptop because a better one is coming. A better one is always coming. The question is what the waiting costs, and the answer is usually a great deal more than the difference between this model and the next.

How often do new models actually arrive?

Constantly, and the pace is increasing rather than settling.

Anthropic's own release notes list fourteen models in the twelve months to September 2026, from Sonnet 4.5 through the Opus 4 series to Fable 5, Sonnet 5, Opus 5 and now Opus 5.5 (Anthropic). OpenAI went from GPT-5.5 in April to a GPT-5.6 preview in June to GPT-6 in September (OpenAI). Google's Gemini changelog shows eight releases over the same period (Google). Add them up and it comes to about twenty-seven releases across three vendors in a year. One every fortnight.

So "the next model" is not an event you can wait for. Whenever you start, there will be a better model within weeks of finishing, and another one after that. Waiting for the releases to stop is waiting for something that has no reason to happen.

Doesn't waiting get you a better, cheaper model?

Yes, and you'll get it anyway. The only question is whether you have somewhere to plug it in.

The price of a given level of capability has been collapsing for years. Stanford's AI Index found that "the inference cost for a system performing at the level of GPT-3.5 dropped over 280-fold between November 2022 and October 2024" (Stanford HAI). Andreessen Horowitz put the trend at roughly a tenfold fall in price every year for equivalent performance (a16z). It hasn't stopped. This month Anthropic launched a model that "performs at the level of Claude Fable 5.1 on most work and costs 40% less to run than Opus 5" (Anthropic), and OpenAI's summer preview described a tier with "competitive performance to GPT-5.5 while being 2x cheaper" (OpenAI).

Here is the part the waiting argument misses. That price fall only accrues to businesses with a working system to receive it. If your invoice-matching automation is live, a cheaper model turns into a smaller bill next month, with one line of configuration changed. If you're waiting, the same price fall turns into nothing at all. The falling cost of intelligence is the argument for starting, not for waiting, because the system you build is the thing that harvests it.

What does waiting actually cost?

Two things, and the visible one is the smaller.

The visible cost is the process itself. The manual work you were going to automate carries on while you wait. The CRM rekeying that turned out to be worth £50,700 a year to one B2B services firm cost that firm roughly £4,200 for every month it wasn't fixed. A month-end close cut by 70% in a week of work had been running long the whole time somebody was deciding whether the technology was ready. Boring work has no sponsor, so nobody counts what the delay costs. It still costs it.

The invisible cost is the learning, and it is the one that matters. Every month you don't run something, you don't find out what your data actually looks like, where the edge cases hide, which step needs a person and which doesn't, and how your team reacts when a machine hands them a draft. Those lessons are almost entirely model-independent. A better model doesn't teach you any of them, and you'll need all of them whichever model you end up on.

The evidence says this is where projects actually fail. MIT's 2025 study of enterprise AI found 95% of organisations getting zero return, and was explicit about why: the divide "does not seem to be driven by model quality or regulation, but seems to be determined by approach" (MIT NANDA). Gartner predicted in 2024 that 30% of generative AI projects would be abandoned after proof of concept; by January 2026 its own analyst put the actual figure at "at least 50%", for the same four reasons, "poor data quality, inadequate risk controls, escalating costs or unclear business value" (Gartner). Read that list again. Not one of those four gets fixed by a new model.

McKinsey's 2026 survey makes the same point from the other direction. Nearly nine in ten organisations now use AI regularly, but only 37% attribute any profit impact to it, "about the same share as last year" (McKinsey). The models improved enormously in that year. The share of businesses making money from them didn't move. Whatever the bottleneck is, it isn't the model.

When the model changes, what actually changes in your project?

Far less than the question assumes. Here is what a typical automation is made of, and what happens to each part when a better model arrives.

Nine tenths of the work survives the swap untouched, and it's the nine tenths that takes the time. I made the longer version of this argument in what vendor-agnostic AI actually means: the model is the easiest layer to change, and the lock-in that hurts lives in the workflow logic and the data. Waiting for a better model to start on the hard nine tenths is like waiting for a better paint colour before you lay the foundations.

What about the model being retired underneath you?

It will be. That is an argument for how you build, not for when.

Every vendor retires models on a schedule. OpenAI commits to "at least 6 months" notice for generally available models (OpenAI), and the original GPT-5, released in August 2025, is scheduled to shut down in December 2026, a sixteen-month working life. Anthropic gives "at least 60 days' notice before model retirement", and says plainly that it "currently deprecates and retires models to ensure capacity for new model releases" (Anthropic); Opus 4.1 was retired twelve months after launch. Google publishes "the earliest possible dates on which a model might be retired" (Google), and its lifecycle table shows Gemini 1.5 Pro retired a year to the day after release.

The waiting argument runs: "I don't want to build on something that gets superseded." But whatever you build on, whenever you build it, will be superseded inside about a year. Waiting doesn't avoid that; it only changes the date you start paying for it. The answer to retirement is the same as the answer to the next model: design so that swapping is configuration rather than a project. Then a deprecation notice is a diary entry, and a better model is a free upgrade.

How do you start now without betting on a model?

Four habits, all of them cheap, and all of them the same habits that keep you vendor-agnostic generally.

1. One place names the model. A configuration value, an environment variable, a routing layer. At volume across several systems that becomes an AI gateway; for one workflow, one setting will do. What matters is that it is singular.
2. Keep an evaluation set. Twenty to fifty real inputs with known-correct outputs, saved. When the next model lands, you run the set and know within an hour whether it's better for your job. This is what turns "should we wait?" from a debate into a measurement you can repeat every fortnight. It's also the same artefact that keeps an automation reliable once it's live.
3. Keep business logic out of the prompt. Validation, routing, thresholds and escalation belong in the workflow, where they survive a model change. A prompt should describe the task, not encode your operating procedure.
4. Use the converged interfaces. The plumbing to switch is now commodity. Google serves Gemini through the OpenAI libraries (Google), Anthropic offers a compatibility layer for the OpenAI SDK, though it describes it as for testing rather than production (Anthropic), and open-source routers such as LiteLLM offer "a single, unified interface to call 100+ LLMs" in one format (LiteLLM).

Then pick the dullest expensive process you have and run a 60-day pilot on it. If the model gets better halfway through, good. Your evaluation set will tell you by how much.

Is there ever a good reason to wait?

Yes, three, and it's worth being straight about them because none of them is "the next model".

• The process isn't ready. If nobody can describe the steps, or the data is in six formats, automating it now produces a faster mess. Fix the process first. That isn't waiting for a model, it's the readiness test, and you can start it today.
• A specific, announced capability is the whole point. If your use case genuinely depends on a feature one vendor has in preview with a date attached, waiting for that date is a decision, not a delay. Wait for the thing, with a deadline. Don't wait for "the next one".
• You can't measure the outcome yet. No baseline means no pilot. But the fix takes an afternoon, not a quarter: write down the volume, the time and the cost of getting it wrong, as in step two of the pilot playbook. Do that while you're "waiting" and you'll find you've started.

What isn't a good reason is "things are moving too fast". They will be moving faster next year. The UK government's own adoption research heard the honest version of this from businesses that would "rather it would be an established technology rather than [us] trailblazing" (DSIT). But using a current model to extract fields from an invoice or route an enquiry is not trailblazing. That work has been boringly reliable for two years, and the trail is well worn: the ONS puts AI use among UK businesses with ten or more employees at around 35%, up from around 12% in late 2023 (ONS). The wait-and-see position is now the minority one, and it's getting smaller.

The bottom line

Don't wait for the next model. It will arrive in a fortnight whatever you do, and it will be retired a year after that. The work that decides whether your project pays is the process, the data, the integrations and the rules, and none of it changes when the model does. Build so the model is one line of configuration, keep a set of real examples to test replacements against, and the next release becomes a free upgrade to something that is already saving you money, instead of a reason to keep not saving it.

If you have a process you've been holding back on until "the technology settles down", a thirty-minute discovery call will tell you whether it's ready now, and what it's costing you in the meantime. See AI consulting and process automation for how I approach the work.