GPT-5: The Model Becomes a Portfolio
GPT-5 replaces the model picker with a real-time router that chooses between a fast path and a reasoning path per request. We examine how the router decides, why the API keeps explicit controls, what launch week revealed about predictability, and how evaluation practice must change when the product is a portfolio behind one name.
A Version Number That Names a System
On August 7, 2025, OpenAI released GPT-5. The name suggests a single model. It is not one. GPT-5 in ChatGPT is a system: a fast, high-throughput model (gpt-5-main), a deeper reasoning model (gpt-5-thinking), mini variants of both as fallbacks, and a real-time router that decides per request which one answers. It replaced GPT-4o, OpenAI o3, o4-mini, GPT-4.1, and GPT-4.5 as the default for signed-in users.
This is a structural change, not a cosmetic one. The unit of release used to be a model with fixed weights and a name. Now it is a portfolio plus a routing policy, and the two halves can change independently of each other. Anyone who builds on such systems, or evaluates them, inherits that split.
How the Router Decides
OpenAI names four routing signals: conversation type, complexity, tool needs, and explicit intent — writing “think hard about this” in a prompt forces the reasoning path. The router is not static. It is continuously trained on real usage signals: when users switch models, which responses they prefer, and measured correctness. The decision boundary between fast and slow is therefore a learned, moving function.
A second routing layer has nothing to do with difficulty: quotas. Once a usage limit is reached, a mini version of the respective model handles the remaining queries. The quality of an answer thus depends on three things — the question, the current state of the router, and how much quota the account has left. Only the first is under the user's control.
The API Path Stays Explicit
The API does not expose the ChatGPT router. gpt-5, gpt-5-mini, and gpt-5-nano are all reasoning models. Thinking time is controlled through reasoning_effort (minimal, low, medium, high; default medium), answer length through the new verbosity parameter (low, medium, high). The non-reasoning ChatGPT model ships separately as gpt-5-chat-latest. Dated snapshots such as gpt-5-2025-08-07 pin exact versions.
The split is deliberate. In ChatGPT, OpenAI routes; in the API, you do. reasoning_effort set to minimal exists precisely so that developers can build a fast path without switching models. gpt-5 is also the default in Codex CLI and supports prompt caching and the Batch API for cost control. Routing remains available to API users — but as something they construct, version, and test themselves.
| Model | Input per 1M tokens | Output per 1M tokens | Role |
|---|---|---|---|
| gpt-5 | $1.25 | $10.00 | Reasoning model, full capability |
| gpt-5-mini | $0.25 | $2.00 | Smaller, for cost-sensitive workloads |
| gpt-5-nano | $0.05 | $0.40 | Fastest, for classification and extraction |
| gpt-5-chat-latest | $1.25 | $10.00 | Non-reasoning ChatGPT model |
Model Portfolios Become Products
GPT-5 marks the point where the product is no longer a model but a portfolio behind one name. The reasons are economic. Reasoning tokens are expensive, and most queries do not need them. A router that sends a factual lookup down a cheap path and a hard proof down an expensive one improves average cost and latency without touching the price list.
The pattern itself is not new. Application teams have built cascades — try the small model, escalate on failure — for years. What is new is that a provider ships the cascade as the default consumer product and retires the individual models. ChatGPT users lost the model picker on day one, and protested loudly enough that OpenAI restored GPT-4o for Plus subscribers within a day.
Routing also changes who gets what. Free ChatGPT users receive reasoning-path answers for the first time, rationed by the router and by quotas rather than by a paywall alone. That this capability could be given away at all is a routing decision: the expensive path is spent only where the router believes it pays off.
What Routing Does to Predictability
Routing does not remove variance; it relocates it. Against a fixed model, the same prompt varies through sampling. Against a routed system, the same prompt can additionally take a different path: because the router was retrained overnight, because a quota ran out, or because the router itself failed.
The failure case is not hypothetical. On launch day the autoswitcher was, in Sam Altman's words, “out of commission for a chunk of the day,” and GPT-5 “seemed way dumber” as a result. A routing outage degraded perceived model quality across the board — without any model weights changing. OpenAI has since promised more transparency about which model answers a given query.
For engineering teams the consequence is a change of mental model: a routed endpoint is a service with a policy, not a function with weights. Quality regressions may be routing regressions. Log the answering path where the provider exposes it, and pin dated snapshots wherever reproducibility matters.
Evals Against a Moving Target
OpenAI's published numbers are per fixed configuration, not per routed request: 94.6% on AIME 2025 without tools, 74.9% on SWE-bench Verified, 88% on Aider Polyglot — all measured with thinking enabled. The hallucination claims are scoped the same way: roughly 45% fewer factual errors than GPT-4o with web search, roughly 80% fewer than o3 when thinking. The numbers are real, but they describe gpt-5-thinking under controlled conditions.
An eval against a routed endpoint measures a composite — routing policy plus model pool — at one point in time. Because the router is continuously retrained, yesterday's result does not bind today's behavior. We draw two conclusions: benchmark pinned snapshots at fixed reasoning_effort levels as regression baselines, and evaluate the routed endpoint separately and repeatedly if that is what production traffic actually hits.
Outlook From August 2025
OpenAI states that it plans to integrate these capabilities into a single model. Until that happens, routing is the architecture — and we expect it to spread. Providers will route across growing portfolios because unit economics demand it. Application teams will keep building their own cascades wherever cost control matters more than convenience.
Our expectation at Blue IT Systems: routing policies will become versioned, observable artifacts, the way model snapshots are today. Evaluation practice will split into model evals and system evals, and quality claims will have to name which of the two they refer to. Some of these predictions may look wrong in a year. The direction — the portfolio as product — will not.