A new model every fortnight

The release calendar is not slowing down

The pace is the story. Gemini 3.6 Flash arrived on 21 July 2026 as Google's new default model with a million-token context window. Sixteen days later OpenAI shipped an updated GPT-5.6 Sol, tuned for shorter answers and better factual reliability, with a new effort slider that lets you dial how hard the model works on a given question. On OpenAI's own numbers, the update produced 68% fewer responses containing at least one factual error than GPT-5.5 Instant.

Both are real improvements. That is the trap. Each release is genuinely better than the last, so each one is a genuine reason to reconsider. Do that every fortnight and you never ship anything. Ignore it and you fall behind on capability and on price, which is dropping just as fast.

Rebuilding per model is the losing game

A frontier release rewrites your assumptions. Prompts that were tuned for one model regress on the next. A cheaper, faster option appears and your cost model is out of date the week you finished it. If your architecture bakes a specific model into the code, every one of these moments is a project: re-prompt, re-test, re-deploy, re-argue the business case.

You cannot win a race whose finish line moves every two weeks. The teams that stall are the ones treating model selection as the decision. It is not the decision. It is the part that changes fastest and matters least to what you own.

Build on the layer you own

Put an abstraction between your business logic and the model. Route every generation call through one interface, keep your prompts and your evaluation set as owned assets, and hold the model choice in config. Then a new frontier release is something you test against your own evals and switch on when it wins, not a rebuild you schedule.

This is how RIVER AI works. It uses the best models available and adds your data, your workflows and your governance on top. The model is a swappable part. What compounds is the layer around it: the knowledge base tuned to your business, the workflows your team actually runs, the guardrails that keep it safe. When the next model lands, our clients get the upgrade by changing a setting, and their evals tell them whether it is genuinely better for their work rather than better on a public benchmark.

The benchmark that matters is yours. A model that tops a leaderboard can still regress on your documents, your tone, your edge cases. Owning an evaluation set built from your real work is what turns a model swap from a leap of faith into a measured decision.

What to actually do

Stop shopping for the best model. Pick a capable one, ship, and design so you can change it later. Time spent choosing between this fortnight's top two is time the release calendar will waste for you.

Own your evals. A small, real set of examples from your own work, scored the same way every time, is the single most useful asset you can build. It tells you when a new model is worth switching to, and it is yours no matter who wins the model race.

Keep the model in config. If swapping a model means a code change and a deployment, you have coupled too tightly. Loosen it now, while the switch is cheap.