Jul, 134 min to read
Platform
News · OpenAI's GPT-5.4 mini and nano push a two-tier model composition strategy
Jul, 94 min to read
PlatformOpenAI's GPT-5.4 mini and nano push a two-tier model composition strategy
The new small models are priced and positioned for subagent architectures, where a large planner delegates narrow tasks to cheaper, faster models running in parallel.
What OpenAI actually shipped
OpenAI released two small models, GPT-5.4 mini and GPT-5.4 nano, framed as its most capable small models to date. The pitch is narrow and concrete: workloads where latency shapes the product experience — coding assistants, subagents, computer-using systems that read screenshots, and real-time multimodal reasoning.
The mini model runs more than 2x faster than GPT-5 mini and, on OpenAI's own benchmarks, closes much of the gap to the full GPT-5.4. On SWE-Bench Pro (Public) it scores 54.4% against GPT-5.4's 57.7%, and on OSWorld-Verified it hits 72.1% against 75.0%. Nano is positioned lower — recommended for classification, data extraction, ranking, and coding subagents handling simpler supporting tasks.
Pricing anchors the positioning. In the API, mini costs $0.75 per 1M input tokens and $4.50 per 1M output tokens with a 400k context window; nano drops to $0.20 and $1.25. In Codex, mini consumes only 30% of the GPT-5.4 quota — roughly one-third the cost for simpler coding tasks.
The subagent pattern is the real product
OpenAI is unusually explicit about the architecture it wants developers to adopt. In Codex, a larger model like GPT-5.4 handles planning, coordination, and final judgment, then delegates to GPT-5.4 mini subagents that run narrower subtasks in parallel — searching a codebase, reviewing a large file, processing supporting documents.
The company states the case directly: instead of using one model for everything, developers can compose systems where larger models decide what to do and smaller models execute quickly at scale. The 30% Codex quota and the ability to delegate less reasoning-intensive work to the cheaper model are the mechanics that make this economical rather than aspirational.
This reframes model selection from a single choice into a routing problem. The interesting engineering work moves to deciding which tasks are 'narrow enough' for mini, and how a planner model coordinates parallel subagent output — decisions that now carry a direct, measurable cost differential.
Where the small models still fall short
The benchmark tables reveal a sharp limitation: long context. On OpenAI MRCR v2 8-needle in the 128K–256K range, GPT-5.4 mini scores 33.6% against GPT-5.4's 79.3%, and nano scores 33.1%. Even in the 64K–128K band, mini reaches only 47.7% versus 86.0% for the full model.
That gap matters for the subagent framing. A subagent asked to 'review a large file' or 'process supporting documents' is doing exactly the kind of retrieval-over-long-input work where these models degrade most. The composition pattern works cleanly for short, targeted subtasks; it gets riskier the moment a delegated task requires reasoning across a large context window.
One customer data point cuts the other way. Hebbia's CTO reports that GPT-5.4 mini achieved higher end-to-end pass rates and stronger source attribution than the larger GPT-5.4 model in their evaluations. That inversion — a smaller model beating a larger one on a specific task — underscores that 'largest' and 'best' are not the same, but it also means teams cannot assume the ranking; they have to test per workload.
What this means for teams building latency-sensitive agents
The concrete implication of this release is that model selection is now a per-subtask economic decision, not a per-application one. With mini at 30% of the GPT-5.4 quota and nano cheaper still, the cost of running a task on the wrong tier is quantifiable, and the incentive to route aggressively is strong.
The practical work shifts to evaluation harnesses that measure each subtask against each tier — because the benchmarks show the tiers diverge unevenly. Tool-calling and computer-use tasks hold up well on mini (τ2-bench telecom at 93.4%, OSWorld-Verified at 72.1%), while long-context retrieval collapses. A team that routes by task type rather than by blanket capability assumption will capture most of the savings without inheriting the failure modes.
OpenAI has effectively productized the intuition that the best model is often not the largest one. The teams that benefit will be the ones that instrument their pipelines enough to know, per task, exactly where that intuition holds.
Find this story relevant to you?
Contact us to find a unique solution
Need an AI engineering partner that can actually build?
We help businesses integrate AI, build AI-powered products, automate high-value workflows, and modernize the software systems behind them.
Related reading
More analysis around product delivery, operational AI, and the systems work that makes deployment hold up in reality.