Historical article: this article preserves the model split used by this generation of Codex. Model names and the current orchestration stack later changed; the body stays with the design described here.
“First-Generation Model Specialisation” is an editorial label, not an official OpenAI version name. I use manager as shorthand for the GPT-5.4 role handling planning, coordination and final judgement.
An authentication refactor often begins with work which is not really design yet. Find where sessions are created. Trace permission checks. Work out what the current tests cover. Read the configuration which constrains the change.
That work can consume plenty of context and time before anyone has decided where the new boundary should sit.
Once the material is collected, the problem changes. Which compatibility constraints matter? Should the old API remain? Which slice should move first?
Later again, the architecture may already be settled and a human may simply be watching a page while small UI edits come back. At that point the expensive thing is often the wait between one observation and the next edit.
All three are “coding”. They spend different resources.
The Codex app already supported parallel agents across separate threads and worktrees.[4] GPT-5.4, GPT-5.4 mini and GPT-5.3-Codex-Spark make that distinction unusually visible.[1][2][3]
Figure 1 | Do not start with model rank. Start with what this part of the job is waiting on.
Mini works well when the finish line is easy to describe
OpenAI gave GPT-5.4 mini a fairly clear role. The larger GPT-5.4 kept planning, coordination and final judgement, while mini subagents handled narrower work such as codebase search, large-file review and supporting-document processing.[2]
For the authentication job, that might mean:
- locating session creation and destruction paths
- mapping where permission checks live
- summarising current test coverage
- reducing the relevant configuration and supporting documents to a short report
I would hand those jobs to a smaller worker not because they are unimportant, but because the definition of done is crisp.
The worker does not need to decide the architecture. It needs to cover the assigned scope and return something the manager can inspect.
The quota model also made this easier to justify. In Codex, GPT-5.4 mini used 30% of GPT-5.4 quota, which OpenAI described as roughly one-third of the cost for simpler coding tasks.[2]
That 30% belongs to Codex quota and included-limit accounting. It is not a promise that API spend falls by 70%; API token pricing is a separate surface. The practical effect is simply that supporting work had a cheaper worker tier, so opening several bounded workstreams became easier to justify.
Spark belongs where a person is waiting for the next edit
The shape of the job changes again once the refactor reaches interface polish.
Move the control a little. Slow the hover state. Change one small branch of logic and show me the result. A person is watching the page, so another half-minute of latency on every turn is suddenly very noticeable.
Codex-Spark was designed for that kind of loop. OpenAI introduced it as a real-time coding model running at more than 1,000 tokens per second on ultra-low-latency hardware. The research preview launched with a 128k context window, text-only input and separate rate limits.[1]
Its working style fits the same job. Spark favoured minimal, targeted edits and did not automatically run tests after every change unless asked.[1]
That makes sense in an interactive loop. It does not turn a quick edit into completed verification.
OpenAI was also reducing latency around the model. Published improvements included an 80% reduction in client/server roundtrip overhead, 30% lower per-token overhead and 50% lower time-to-first-token, alongside a persistent WebSocket path and other session-pipeline changes.[1]
That matters because the person waits for the whole path: prefill, generation, tool execution, network transport and harness overhead. Tokens per second explain only part of the experience.
Spark can shorten the feedback loop. Broad regression, cross-file convergence and longer autonomous work still need the normal verification path.
The hard part often starts when the workers come back
Suppose three mini subagents return a session map, a permission review and a test-coverage report.
The refactor is still not designed.
The reports may disagree. Together they may expose a compatibility constraint nobody expected. Someone still has to decide which findings change the design, what should move first and whether the old path should remain.
OpenAI explicitly kept planning, coordination and final judgement with the larger GPT-5.4 in its description of mini subagents.[2] GPT-5.4 itself was positioned for complex professional work, tool use and longer agentic workflows.[3]
Figure 2 | Mini removes bounded support work from the manager; Spark sits in a separate human-interactive lane.
GPT-5.4 manager
├── Mini subagent: session/auth code search
├── Mini subagent: permission review
├── Mini subagent: test coverage review
└── reconcile findings → choose design → order changes
Human + Spark
└── rapid local UI / logic refinementThe important detail is that Spark is not another level in the mini-subagent hierarchy.
Spark is the interactive lane. GPT-5.4 plus mini is the manager-worker split. Turning them into one hierarchy would imply an orchestration relationship which these sources do not establish.[1][2]
More workers can still mean more work
Fan-out is easy to overrate because several moving workers look productive.
If three subagents read substantially the same context and return three overlapping reports, the manager now has to reconcile material which should probably have been gathered once. The workers did run in parallel. The workflow simply created duplicated work.
Another trap is delegating judgement because mini looks close on a benchmark. GPT-5.4 mini approached GPT-5.4 on some published evaluations, but the gaps varied across coding, tool use and long-context work. OpenAI still assigned planning, coordination and final judgement to the larger model.[2]
A close score can justify trying a bounded workload. It does not show that every role is interchangeable.
Routing research asks a similar question more generally. RouteLLM frames strong-versus-weak model selection as a cost-quality trade-off, while FrugalGPT studies cascades which avoid paying the maximum model cost for every query.[5][6]
In an agent workflow, the routing unit can be smaller than the whole user request. One subtask may deserve a different model from the work around it.
I would start with the work, not a router service
There is no need to build a complicated router before trying this split.
Repository search, large-file review and supporting-document work are good mini candidates when their finish lines are clear.
Conflicting findings and implementation choices belong back with the stronger decision-maker.
If a human is watching the UI and each turn is only making a small local change, Spark’s latency profile starts to matter.
The simplest guardrail is not a model rule at all: if you cannot say what “done” means for the subtask, do not fan it out yet.
More workers will only produce ambiguous partial work faster.
Model names will change. The habit worth keeping is to look at the job first: where does it need judgement, where can work proceed independently, and where is the main cost simply a person waiting for the next result?
References
- OpenAI, Introducing GPT-5.3-Codex-Spark, 12 February 2026.
- OpenAI, Introducing GPT-5.4 mini and nano, 17 March 2026.
- OpenAI, Introducing GPT-5.4, 5 March 2026.
- OpenAI, Introducing the Codex app, 2 February 2026.
- Ong et al., RouteLLM: Learning to Route LLMs with Preference Data, 2024.
- Chen, Zaharia & Zou, FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, 2023.