For a while the default agent architecture was simple: pick the biggest model you can afford and route every turn through it. Planning, tool calls, retries, error parsing, the whole loop.
That worked when agents were demos. It breaks when agents run all day.
Agentic coding is not one prompt. It is hundreds of tool calls, file reads, terminal output, and self-corrections stacked on top of each other. Run that loop on a frontier model and your token bill grows faster than the feature you are trying to ship. Raw capability stops mattering when unit economics say no.
Cursor's Composer 2.5 release is the clearest signal I have seen that the industry is moving past "frontier for everything." Specialized models are not winning on generalized IQ. They win on price, latency, and domain fit inside a harness that actually ships code.
What changed in May 2026
Artificial Analysis put numbers on what builders already felt in their wallets. Composer 2.5 scored 62 on their Coding Agent Index. Claude Opus 4.7 (max) in Claude Code hit 66. GPT-5.5 (xhigh) in Codex landed at 65.
The gap is small. The cost gap is not.
| Model | Index score | Est. cost per task |
|---|---|---|
| Composer 2.5 (standard) | 62 | $0.07 |
| Composer 2.5 (fast) | 62 | $0.44 |
| Claude Opus 4.7 (max) | 66 | $4.10 |
| GPT-5.5 (xhigh) | 65 | $4.82 |
That is roughly 10x to 60x cheaper for near-frontier coding agent performance on a standardized harness. Not a lab benchmark on cherry-picked prompts. A dollar figure for finishing a representative agent task end to end.
List price tells the same story at the token layer:
| Model | Input (per 1M tokens) | Output (per 1M tokens) |
|---|---|---|
| Composer 2.5 standard | $0.50 | $2.50 |
| Composer 2.5 fast | $3.00 | $15.00 |
| Claude Opus 4.7 | $5.00 | $25.00 |
| GPT-5.5 | $5.00 | $30.00 |
When your agent burns output tokens on stack traces and diffs, output pricing dominates. Specialized tiers were built for that workload.
Why specialized models can beat frontier on coding loops
Frontier models are generalists. They are trained to reason across domains you will never touch in a repo refactor. You pay for that breadth on every turn.
Specialized coding models like Composer 2.5 start from a strong open checkpoint. Cursor built it on Moonshot's Kimi K2.5 and spent roughly 85% of total compute on post-training: reinforcement learning, synthetic task generation, and harness-specific behavior tuning.
That is the Cursor playbook in one sentence: do not pre-train from scratch; specialize an open base for your product surface.
The IDE is the moat. Cursor owns the interface, so it captures tool-call traces, failure modes, and the exact loop developers run thousands of times a day. That product data feeds training in ways a generic API customer cannot replicate.
Their targeted RL with textual feedback is a good example. Long agent rollouts make end-of-trajectory rewards noisy. If the model calls the wrong tool on step 47 of 200, a pass/fail grade at the end barely teaches anything useful. Cursor inserts localized hints at the mistake, distills corrected behavior on-policy, and keeps the broader RL objective intact. Same idea as self-distilled fine-tuning (SDFT): teach the model where it went wrong, not just that it lost.
I have shipped enough agent harnesses to know that loop quality matters as much as model IQ. A mid-tier model inside a tight write-run-fix shell often beats a frontier model inside a thin wrapper. The grep vs vector retrieval paper made the same point for search: harness choice swung scores as hard as retriever choice.
Where frontier models still win
Specialized models are not magic. They lag on the hardest out-of-distribution reasoning: novel architecture, zero-shot research, long shell-heavy investigations.
Independent breakdowns show Composer 2.5 leading on in-IDE benchmarks like SWE-Bench Multilingual while trailing GPT-5.5 by double digits on Terminal-Bench 2.0 style shell work. That matches how I use them in client projects:
- Default to specialized for multi-file edits, test scaffolding, refactors, and iterative bug fixes inside a repo.
- Escalate to frontier for greenfield system design, security review on unfamiliar stacks, or tasks where wrong code is more expensive than slow code.
If you route everything to frontier "just in case," you are subsidizing fear with tokens.
The hybrid routing pattern I recommend
Modern agent stacks should assume multiple models, not one hero model.
A practical split for coding agents:
| Workload share | Model tier | Examples |
|---|---|---|
| 80 to 90% | Specialized / mid-tier | Composer 2.5, fast Sonnet-class models, local 30B agents |
| 10 to 20% | Frontier | Opus, GPT-5.5 xhigh, deep research passes |
Recent routing benchmarks line up with that ratio. NVIDIA NeMo Switchyard testing on LangChain's deep agent suite sent only 7% of turns to a frontier model while cutting cost about 74% versus frontier-only, with a measured accuracy tradeoff in the single digits.
That is not "use cheap models and hope." It is explicit policy:
- Classify the step, not just the user message. A vague question might still need a cheap extraction pass before a frontier plan.
- Orchestrate with frontier, execute with specialized. Let the expensive model break work into subtasks, then hand file edits and tool loops to the efficient tier.
- Cascade on failure. Start cheap. Escalate when confidence drops, tests fail twice, or the task hits a novelty flag you define upfront.
- Measure per-tier evals. If your cheap path fails silently, you did not save money. You bought incidents.
For ops agents outside coding, the same math applies with different names. Route ticket triage, CRM field extraction, and formatting to fine-tuned small models. Reserve frontier for policy exceptions and multi-system reasoning.
What this means if you build AI products
Relying entirely on generic Anthropic or OpenAI API calls is a weak margin strategy now. Long-term performance and profitability lean on specialized backends that match your harness and data.
You do not need Cursor's distribution to start. Teams with deep proprietary data in legal, finance, medical workflows, or internal codebases already have the raw material. The missing piece is often infrastructure, not ideas.
That is where tools like Tinker from Thinking Machines Lab enter the picture: Python-native fine-tuning APIs that hide cluster orchestration so smaller teams can run the specialization playbook without owning a supercomputer. I wrote a separate walkthrough on that stack.
Checklist before your next agent project
Before you default to the flagship model:
- Estimate loop cost, not single-prompt cost. Multiply expected turns by output tokens per turn.
- Baseline a specialized model in the same harness you will ship. Same tools, same eval set.
- Define escalation triggers in code, not in prompts alone.
- Log which tier handled each step so finance and engineering see the same chart.
- Re-run evals monthly. Model tiers move fast; your routing table should too.
Takeaway
Frontier models will keep getting smarter. They will not automatically eat every vertical. Agentic loops punish token spend at scale, and specialized models are now close enough on domain tasks that the economics flip.
The winning architecture is hybrid: fast specialized models for the bulk of turns, frontier models for the minority that actually need them. If you want help designing that routing layer (and the evals that keep it honest), book a free discovery call.