I was refactoring a data pipeline in GitHub Copilot, bouncing between GPT-5.3-Codex and GPT-5.4-mini. Codex was the obvious choice — it's a dedicated coding model, purpose-built for exactly this kind of work. Mini was there for budget reasons: at 0.33× the message cost, it was hard to ignore.
Then I tried something: I enabled plan mode before sending any task to GPT-5.4-mini.
The result stopped me cold. GPT-5.4-mini didn't just match Codex. It outperformed it — completing the refactor cleanly and fixing several bugs along the way that I hadn't even flagged. A model I'd chosen to save money had quietly delivered better work than the specialist.
But here's where benchmarks run out of explanatory power. GPT-5.4-mini didn't just outperform GPT-5.3-Codex — a dedicated coding model. It outperformed GPT-5.4 itself. The flagship. The model sitting at the top of every leaderboard.
No benchmark predicts that. By raw capability scores, this result shouldn't be possible. Which means something else is driving it — something the benchmarks aren't measuring.
After sitting with this result for a while, I think I have an explanation. Bear with me — it borrows from economics, but I promise it lands somewhere practical.
Every model has two distinct capability axes. The first is broadness: the ability to extract relevant signal from massive, polluted, or misleading context — finding the needle in a noisy haystack. The second is deepness: the ability to solve genuinely complex problems — hard reasoning, architectural decisions, anything where the difficulty comes from the problem's inherent complexity, not its context size.
Now imagine plotting these two axes on a graph. Every task gets a coordinate: how much broadness does it demand, how much deepness? And every model has what economists call a Production Possibility Frontier — a curve defining the boundary of its capability. Above the curve: impossible. Below it: leaving performance on the table. On it: operating at full potential.
This curve has one crucial property: it's concave. Which means the more you demand of one axis, the faster the other collapses. Ask a model to handle massive broadness AND deep reasoning simultaneously — you're pushing toward the interior, away from the frontier. Performance degrades faster than you'd expect. Not linearly. Sharply.
Fig. 1 — Every model has a concave capability frontier. The area enclosed represents total intelligence — larger area means higher price. Performance degrades sharply when both axes are demanded simultaneously.
The curve also has a natural interpretation for cost: the area enclosed by it represents the model's total intelligence. Bigger area, higher price. That's your tier premium, geometrically explained.
This also explains something puzzling about benchmarks: why real-world gaps feel smaller than leaderboard gaps suggest. Benchmarks measure specialized, isolated tasks — they're implicitly testing models near their frontier edges. Real-world usage mixes task types — pushing models toward compound coordinates. The concavity punishes that mixing. So flagship's nominal advantage evaporates faster in practice than benchmarks predict.
And here's what the concavity gives you for free: when you specialize a task — demanding only broadness, or only deepness — you push the coordinate toward the edge of the curve. The model operates at a specialized point where one capability is fully amplified. A standard-tier model, given a purely deepness-heavy planning task, operates near the top of its frontier. Its effective deepness exceeds what you'd ever see from a mixed task. That's why plan mode unlocked GPT-5.4-mini. It wasn't a different model. It was the same model, finally operating where it was strongest.
Let me show you what a bad task coordinate looks like in practice.
I was building a quantitative trading system — if you've read my previous article, you'll recognize this story. Mid-sprint, I changed the spec and sent a new prompt to the model without starting a fresh session: "Ignore what we discussed. Implement spec v2 instead."
What I was actually doing, in capability-plane terms, was creating a task with simultaneously high broadness demand — reconcile two conflicting specs living in the same context — and high deepness demand — reason through the architectural implications of the change and implement correctly. Both axes pegged simultaneously.
On a concave curve, that coordinate sits dangerously close to the interior — or outside the frontier entirely. The model didn't fail because it was weak. It failed because I handed it a geometrically impossible task. No model handles that coordinate well. Not mini. Not flagship. The concavity makes sure of that.
Fig. 2 — Specialized tasks (plan, implement) sit comfortably on the standard frontier. A combined task demands high broadness AND high deepness simultaneously — pushing the coordinate beyond what any frontier can satisfy.
The fault wasn't the model's. It was the shape of the task I created.
Here's where the framework becomes genuinely exciting.
When you decompose a complex task into specialized stages, something unexpected happens. You're not just avoiding a bad coordinate — you're actively reshaping the model's effective capability frontier.
Remember the concavity. At a specialized point — pure deepness, minimal broadness — a standard model's effective deepness capacity is amplified beyond its nominal tier. It's not operating as a standard model anymore. It's operating as something closer to a specialist, with full cognitive capacity concentrated on a single axis.
Meanwhile, a flagship model handed the same task as one combined prompt is pushed toward the interior of its own curve. Its nominal superiority means nothing there. The geometry punishes mixing regardless of tier.
The result: a well-decomposed standard model can produce a higher effective output than a flagship model operating on a compound coordinate. Not because the standard model got smarter. Because you changed the shape of the problem it was solving.
Fig. 3 — Through task decomposition, the standard model's effective frontier (green) rises above both its nominal frontier and the flagship frontier in the moderate broadness region. The task demanded (purple) is outside flagship but inside effective — achievable through decomposition. Flagship falls short (red). The model didn't change. The task structure did.
This is what I mean by "effective frontier." The model didn't change. The task coordinate did. And on a concave curve, task coordinate is everything.
So how does this change my actual workflow? One question now precedes every task I dispatch:
Is this decomposable?
If yes — standard tier, plan mode, inspect, execute. If no — flagship, and it better genuinely need it.
A complex task that can be decomposed belongs to standard. A simpler task that can't be decomposed belongs to flagship. Complexity is a distraction. Decomposability is the real question.
Ask yourself: can this task be broken into sequential steps, each with a clean context and a verifiable output? If yes — standard tier. If no — flagship earns it.
This realization pushed the boundary much further than I expected. Even research — which I originally assumed was flagship territory due to its high broadness demand — turns out to be decomposable. Here's the method I now use for genuinely complex research problems:
First, ask standard tier to make a plan for research — not a solution plan, but a map of what needs to be understood. Second, execute that research plan. Third, identify the gaps that remain and plan the next research iteration. Fourth, repeat until the gaps close. Finally, compose everything into a full solution plan.
Each step is narrow. Each output is an explicit artifact. The task coordinate stays manageable at every stage. The result is indistinguishable from what flagship would produce in one sprawling prompt — often better, because each step was fully auditable.
For teams running thousands of agentic tasks daily, that's not incremental savings. It's a different cost structure entirely.
So where does flagship genuinely earn its place? The answer is narrower than most people think:
| Phase | Broadness | Deepness | Decomposable? | Best fit |
|---|---|---|---|---|
| Research | High | Medium | ✓ Yes | Standard |
| Planning / Spec | Medium | High | ⚠ Partially | Flagship |
| Implementation | Low | Low | ✓ Yes | Standard |
| Review / Debug | Low | High | ✗ No | Flagship |
| Boilerplate / Glue | Low | Low | ✓ Yes | Mini |
Notice what's flagship: Planning/Spec and Review/Debug. Both share one property — they require holding the entire problem coherently in one act of judgment. A spec needs to be internally consistent across all its parts simultaneously. A bug fix requires tracing a complete causal chain without losing the thread. Decomposition breaks that coherence. Flagship earns its price precisely here, and nowhere else.
Step back from the benchmarks, the tier comparisons, the cost calculations. Something bigger is shifting.
In the early days of software, scarcity was in implementation — could you write the code at all? Then it moved to architecture — could you design systems that scaled? Now, in the middle of the AI carnival, scarcity is moving again. Toward something harder to name and impossible to benchmark: taste. Judgment. The ability to decompose a problem elegantly, recognize when a plan is truly feasible, know instinctively when a task coordinate exceeds a frontier.
We are becoming less like engineers and more like artists. The tools are extraordinarily powerful. Anyone can pick them up. What separates great work from mediocre work is no longer technical access — it's the sensibility of the person directing the tools.
Workflow design is the new competitive advantage. Not because the models matter less. But because they've become capable enough that how you ask matters more than what you ask with.
The flagship era isn't ending. It's being put in its proper place — as a specialist instrument, reached for deliberately, not reflexively. The artists who understand that will build things the benchmark-chasers never will.