GPT-5 lands with a router and a backlash

OpenAI released GPT-5 last week, replacing the model picker with a single entry that routes internally between a fast model and a reasoning model based on the request.

Within days they restored access to the previous models for paying users after substantial user pushback. That reversal is the more interesting story.

the technical design#

GPT-5 is a system, not a model: a fast non-reasoning model, a deeper reasoning model, and a router that decides which handles a given request. The API exposes gpt-5, gpt-5-mini, and gpt-5-nano, plus a reasoning_effort parameter including a minimal setting.

The router is the right idea. Most requests do not need reasoning, reasoning costs latency and money, and asking users to choose a model is asking them to have an opinion about something they have no basis for.

The problem is that a router is only good if it routes correctly, and a misrouted request produces a worse answer than the user would have gotten by picking themselves. Early reports of poor performance were substantially router issues rather than model issues, which OpenAI acknowledged and shipped fixes for.

There is a general lesson here: automatic routing removes control and adds a failure mode that is invisible to the user. When it works, nobody notices. When it fails, the user has no way to diagnose or override. If you build routing, ship the override.

the deprecation backlash#

The reaction to removing GPT-4o was much stronger than anyone at OpenAI appears to have anticipated, and a lot of it was not about capability.

People had developed workflows, prompt libraries, and — for a nontrivial population — a genuine attachment to a specific model's voice. Removing it overnight felt like a service being taken away rather than upgraded.

Whatever you think of that attachment, it is a real product fact. Model behavior is not a fungible commodity to the people using it daily, and a "better" model that writes differently is a breaking change.

The engineering translation: model versions are an API surface. Deprecating one is a breaking change and should follow the same discipline as any other: advance notice, an overlap period, a migration guide, and a documented behavioral diff.

Every provider is going to keep learning this the hard way.

the developer read#

Ignore the consumer drama. The API story is straightforward:

• reasoning_effort: "minimal" gives you fast responses with the new model's quality. Use it for anything latency-sensitive.
• The routing does not apply to the API in the same way; you pick the model. That is correct.
• Pricing is aggressive relative to previous frontier models, which continues the trend of per-capability cost falling.
• Reported hallucination rates and instruction-following are meaningfully improved, which matters more for production use than benchmark deltas.

Re-run your evals. Do not assume it is a drop-in. It is better on most things and different on all of them, and "different" is what breaks your prompts.

the pattern to notice#

Every major provider has now converged on the same architecture: a family of models at different price points, a reasoning dial, and some form of automatic selection. The differentiation has moved almost entirely off raw capability and onto price, latency, tooling, and integration.

That is what a maturing market looks like. It is also much better for buyers than the alternative.