How to Plan Around an Unreleased AI Model
Announced AI models get delayed or cancelled. Follow three roadmap rules, from building on what ships to adding a swap point, so a miss never stalls you.
To plan around an unreleased AI model, treat it as a rumour with a date on it: build your product on models you can call today, design one clean place in the code where a newer model can be swapped in, and price the plan at current rates. A model that is announced, promised for next month or leaked in a benchmark table can slip, change price or never ship, and your roadmap should survive any of those.
This is not hypothetical. OpenAI cancelled the October launch of GPT-6.1 Astra after safety tests, as we reported in the cancellation post. Anyone who had scheduled a feature around it lost that date overnight.
Why announced models slip
There are ordinary reasons and there are the reasons this month showed.
Safety and quality testing can fail late. The Astra decision came after tests on staying in scope and reporting actions honestly.
Pricing can change between announcement and release. Prices on a preview page are not a contract.
Access can be staged. Some models arrive first in a subscription product or a gated tier and reach the API later. GPT-6.1 Sol, for example, launched in Codex and ChatGPT Work while not yet in ChatGPT Chat, per The Next Web.
Names move. A launch can arrive as a cheaper sibling of the model you were waiting for.
Rule 1: build on what ships
Your committed roadmap uses only models you can call in production now. A feature that depends on next month's model goes in a separate list called "if it ships." That list can be long. It does not carry dates that a customer or a teammate will hold you to.
A quick test: if the vendor announced today that the model was cancelled, which line items on your plan would break? Anything that would is built on the wrong layer.
Rule 2: put a swap point in the code
Do not let model names spread through your codebase. Keep them in one configuration place, with the model ID, the prompt version and the expected settings together. When a new model does arrive, you change one entry and run your test set.
MODEL_CONFIG = {
"summarise": {"model": "current-model-id", "effort": "low"},
"review": {"model": "current-model-id", "effort": "high"},
}Our guide on migrating from one AI model to another without breaking your app covers what to keep constant, and whether to pin a model version covers the other side of the same coin.
Rule 3: price the plan at today's rates
If your unit economics only work at a future price, the plan is a bet. Cost a feature using what you pay now. If a cheaper model arrives, that is upside. The recent launches show why to be careful: Sonnet 5.5 kept list prices flat and claimed savings through fewer tokens, which you only get if it holds on your tasks, as we explain in Sonnet 5.5 vs GPT-6.1 Sol.
How to plan around an unreleased model the week it is announced
Add it to the "if it ships" list with the source and the date it was said.
Write the two-line test you would run on release day, using your own prompts.
Note what you would gain and what it is worth. If the gain is small, stop watching it.
Ignore countdowns. Check again when the model is callable.
For keeping the signal-to-noise ratio sane, see how to keep up with AI news.
A small worked example
Suppose you run a support-reply tool and hear that a cheaper, smarter model is due next month. The unreleased-model plan has three lines: keep shipping on today's model, add the model name to your configuration file with a note "candidate", and write the 25 test conversations you would replay. The day the model becomes callable, you spend an hour on those conversations, compare cost per resolved ticket, and decide. If it never ships, nothing in your roadmap changed. If it ships late, nothing broke. If it ships early, you were ready. That is the whole benefit of planning around the announcement instead of on it.
FAQ
What if my product depends on a model that gets cancelled?
If it depends on it at all, the model choice was a single point of failure. Keep the model behind one configuration point and keep a fallback model that already passes your tests.
Should I wait for a rumoured model before building?
No. Build on a model you can call now. A good swap point makes upgrading later a small change.
How do I know when an announced model will really be available?
When you can call it with an API key and it appears in the vendor's pricing page and documentation. Before that, treat dates as intentions.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
