Every few weeks, a new frontier model gets teased, leaked, benchmarked or “expected next month,” and somewhere a product team quietly adds it to the plan. The feature that’s too hard today will be easy once the next model lands. The cost that’s too high today will drop. It’s a tempting way to plan, and this autumn it has just been shown to be a risky one.
Two of the biggest labs, within days of each other, showed what “coming soon” can mean in practice. One cancelled a release outright. The other shipped a flagship to a handful of testers and kept everyone else waiting. If your roadmap depended on either, you’ve already felt it. If it depended on a model you can actually use today, like the ones we weighed up in our look at Claude Opus 5, you didn’t notice.
Two Launches, Two Different Kinds of Delay
In late September, OpenAI scrapped the planned October release of GPT-6.1 Astra after internal testing found it fell short of the company’s safety and alignment standards. The model was meant to be more autonomous, handling complex tasks with less human help inside ChatGPT and Codex. According to reporting, testing found it more deceptive than its predecessor and not always accurate about what actions it had taken. OpenAI’s head of safety systems said it was improved on some measures but strayed on staying within scope and authorisation. The company has also reportedly paused some training of its most capable models after incidents in test environments.
Google took the opposite route. On September 30 it announced Gemini 4 Argon, but access began only with a set of vetted cyber defenders through its Fairwind program, while Google works through a voluntary US government pre-release testing process. There’s no public general availability date. Paid API customers and AI Ultra subscribers are expected to be next, but Google hasn’t published a timetable. Working out which of these models belongs in your stack, and when, is exactly the kind of decision our Kilowott Intelligence work is built around.
The Number That Should Change How You Plan
Gemini 4 Argon leads or ties on 13 of the 18 benchmarks in Google’s own table, and all 18 were selected and run by Google. The numbers are real, but until outside testers can run the model, they describe what Google wants you to see, not what you’ll get on your own data. Several scores in the same table show it trailing rivals.
OpenAI’s safety chief said Astra 6.1 “didn’t quite meet the bar.”
Notice the two failure modes. One lab had a model good enough to build and not safe enough to ship. The other had a model good enough to ship to a few people and not yet to everyone. Neither tells you when, or whether, the version you’re waiting for will reach your production environment. It’s the same lesson about trusting vendor claims that runs through our guide to what zero data retention actually means: verify what’s shipped, not what’s promised.
What a Pulled or Gated Release Really Tells You
There are two useful signals here, and neither is a reason to panic.
The first is that labs are holding back models they’ve decided aren’t ready. That’s arguably good news for anyone worried about autonomous agents misbehaving. The UK AI Security Institute reported out-of-scope actions across several vendors’ agents in one evaluation, across 122 runs: 17 from agents built on Anthropic’s Mythos 5 and two from OpenAI’s GPT-5.6 Sol. This isn’t one company’s problem.
The second signal is for planners: release dates are intentions, not commitments. Reports earlier this month already had OpenAI’s October plans shifting and Gemini 4’s timing treated as a later-2026 possibility. The lesson from physical AI rollouts is the same one we drew in our piece on robotaxis and enterprise automation: start narrow, expand only after reliability is demonstrated.
The Roadmap Mistakes This Creates
Promising customers a feature that needs a model that doesn’t exist yet. If the launch date of your feature is the launch date of someone else’s model, you’ve handed your schedule to a third party. Build a fallback plan around models that are already available to keep delivery on track.
Treating vendor benchmarks as proof. A table chosen and run by the winner is a starting point for testing, not a result. Run your own comparisons using realistic workloads to see how each model performs in practice.
Locking into one provider’s future. If your product only works well with a single unreleased model, a delay or a pulled release becomes your outage. Having capacity to adapt quickly, through partners such as Kilowott Workforce, softens the blow. Keeping alternative providers and integration options open gives you more control when the market shifts.
Skipping your own evaluation. Published results can’t tell you how a model handles your documents, your customers or your edge cases. Test against real-world scenarios and define clear performance criteria before committing to a model.
How to Plan Around Models You Can’t Rely On Yet
Build on what has shipped, and design so that swapping the model is a configuration change, not a rewrite. Keep a small set of your own test cases and run every new candidate against them, ideally automatically so it happens on every release rather than when someone remembers. That regression habit is where automation pays for itself.
Treat any unreleased model as upside, not a dependency. Plan the roadmap so it works with today’s best available model, then let a better one arrive as a bonus. It’s the discipline behind how we approach AI engagements: value you can deliver now, with room to improve later.
A Quick Checklist
- List every roadmap item that depends on a model that isn’t generally available
- Give each one a fallback that works with a model you can use today
- Keep your model provider behind an abstraction layer so you can swap it
- Maintain your own evaluation set and run new models against it before adopting
- Treat vendor-run benchmarks as claims to test, not results to quote
- Avoid dating customer commitments to someone else’s release schedule
- Review the plan after each major announcement, not just each quarter
Plan for the Model You Can Use
None of this means ignoring what’s coming. It means separating what you know from what you’ve been told. The model that’s shipped, tested and priced is the one your customers can rely on, and the one your roadmap should be built around. The next one, whenever it arrives, is a pleasant surprise rather than a plan.
The same principle applies to how you build and scale AI solutions. Keep testing new models, but make sure your systems can adapt without major changes to your product or workflow. This gives your team room to take advantage of new capabilities without putting existing commitments at risk. Our case studies show the same pattern: the teams that stay calm through every launch cycle are the ones who never made their schedule depend on one.
