GPT-5: The Model Becomes a Portfolio
GPT-5 replaces manual model selection with a real-time router that chooses a fast or reasoning path for each request. We examine its signals, the API's explicit controls, and what launch week taught about predictability and evaluation when one product name hides a changing portfolio.
A Version Number That Names a System
OpenAI released GPT-5 on August 7, 2025. The name sounds like a single model, but in ChatGPT it denotes 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 selects the answering path for each request. That system 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. A release used to mean a model with fixed weights and a name. Now it means a portfolio and a routing policy — two components that can change independently. Anyone building on or evaluating such a system must account for 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: OpenAI controls routing in ChatGPT, while API users control it themselves. Setting reasoning_effort to minimal provides a fast path without requiring a model switch. gpt-5 is also the default in Codex CLI and supports prompt caching and the Batch API for cost control. API users therefore retain routing, but also assume responsibility for its design, versioning, and tests.
| 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 adds another source of it. With a fixed model, the same prompt varies through sampling. In a routed system, it can also take a different path because the router was retrained, a quota was exhausted, or 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 always measures a time-bound composite of routing policy and model pool. Because the router is continuously retrained, yesterday's result does not guarantee today's behavior. That calls for two distinct test paths: pinned snapshots at fixed reasoning_effort levels as regression baselines, and repeated system evals of the routed endpoint when production traffic actually uses it.
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 is therefore clear: routing policies will become as versioned and observable as model snapshots are today. Evaluation will split into model and system evals, and every quality claim will need to state which layer it describes. Individual predictions may age badly within a year; the underlying shift toward the portfolio as product is likely to remain.