GPT-5 Picks Its Own Effort. Your Budget Cannot.

GPT-5 is not one model. It is a system of models behind one endpoint, with a router that decides how much reasoning a request gets. OpenAI built it as exactly that (opens in a new tab), and the design choice is the most consequential thing about the release.

The router is a good product decision. For a chat window, it is the right answer: most prompts are easy, a few are hard, and asking the user to pick a model was always a bad interface.

For a system that has to forecast cost, measure quality and explain a decision months later, the router is a problem. It moves a design decision into the vendor's runtime, and the decision it makes is one you would otherwise document.

What the router actually decides

Behind the endpoint sits a choice between a fast path and a reasoning path, and within the reasoning path, how much effort to spend. That effort setting changes latency, token consumption and, for hard tasks, accuracy.

Three properties of that arrangement matter to anyone building on it.

Cost per request becomes a distribution. If you cannot predict which path a request takes, you cannot predict unit cost. You can measure the average over last month. You cannot tell a program office what next month costs per case.

Latency becomes a distribution too. The fast path answers in about a second. The reasoning path does not. A workflow with a human waiting on the other end has to design for the tail, and the router decides when your request is in the tail.

The tested path is not always the executed one. This is the subtle one. Your evaluation covers the requests you ran. If the router sends a subset down a path your evaluation treated as rare, production behavior differs from tested behavior, and you find out from a user rather than from a test.

An evaluation is only valid for the path it exercised. A router makes that sentence harder every month.

Why this is an authorization problem, not just a cost problem

In a regulated deployment, the model version is a configuration item. You test the configuration, you document the behavior, and you revalidate when the configuration changes. That is the bargain that makes an automated decision defensible.

A router undermines the bargain at the edges. Same model name, same endpoint, same version string, different behavior for two requests that look alike. Nothing in your change control caught it because nothing changed from your side.

There is a fair counterargument: a router that sends the hard cases to a stronger model produces better outcomes than a fixed cheap model. That is true, and it is an argument for routing, not for opacity. The objection is not that the system adapts. It is that the adaptation is invisible in the artifact you have to defend.

The control you still have

The API exposes a reasoning effort setting. That is the lever, and it is worth using deliberately rather than leaving the router to do your capacity planning.

1. Set effort explicitly per workload. High effort for extraction that feeds a decision. Low effort for classification and routing. Write the choice down as a design decision with an owner.
2. Pin and log. Record the model identifier, the reasoning setting and the request parameters with every output. If you cannot tell from the record which path ran, you cannot reproduce the result.
3. Test both paths. Run your evaluation at the effort settings you deploy, and include a sample at the other setting to see whether the router's own choice would have changed the answer.
4. Cap the tail. Set timeouts and fallbacks for the reasoning path. A workflow that blocks on a slow path is a workflow that fails under load, and the router does not know your service level.

None of that eliminates routing. It makes routing visible, which is the difference between a system you can operate and a system you can only observe.

Where routing is the right answer

Plenty of work should take the router as it comes. Drafting, summarizing, search assistance, internal tools where a slow answer is an annoyance rather than an incident. In those cases the routing is free optimization and fighting it is wasted effort.

The line is consequence. If the output is evidence, if it moves money, if a person will be asked to defend it in a review, then the path that produced it belongs in the record and under your control. If the output is a first draft that a human rewrites, let the router do its job.

That distinction is more useful than any benchmark comparison, because benchmarks answer the question "how good is the model" and what a program needs is "how do I know which behavior I am buying."

What to ask before you adopt

One question, in a design review: when this system produces a wrong answer, can we reconstruct which model and which effort setting produced it?

If yes, the router is an implementation detail. If no, you have added a variable to a system whose whole value is that its variables are accounted for.

GPT-5 is a strong release and the routing is clever engineering. It also makes a decision that used to be yours. Take it back where it matters, and leave it alone where it does not.