Fetching from the wire…
01
02
03
04
05
06
07
08
Top 5 · 2026-05-19 · source-backed
Cursor's Composer 2.5, built on Kimi K2.5 with custom reinforcement learning, matches Opus 4.7 quality at one-tenth the token cost. Read that again. A purpose-built model trained for coding tasks is matching the most capable general-purpose model at a fraction of the price.
This isn't an isolated case. Cursor already trained Composer 2 on its own data. Codex built task-specific models running on its own infrastructure. Windsurf shipped an Adaptive model router that selects the optimal model per task to stretch quota. Every major AI coding platform is investing in purpose-built post-trained models, and they're doing it for the same reason: agentic token costs on general-purpose APIs are unsustainable.
The connection to the billing story above is direct. When GitHub charges by token and Anthropic meters usage pools, the platform that can deliver equivalent coding quality at 10x fewer tokens wins on unit economics. That's not a nice-to-have optimization. It's existential. And it explains why we're seeing this pattern emerge simultaneously across every major player.
For builders, the practical implication is uncomfortable. The "use the best frontier model" default that most of us run with is probably wrong for many coding tasks. A model trained specifically for code editing, with custom RL on code review signals, can outperform a model that also knows Shakespeare and organic chemistry. I haven't tested this rigorously enough in my own workflows to give specific recommendations, but the data is compelling enough that I'm planning to benchmark Composer 2.5 against my current Claude Code setup this week.
The broader pattern: we're moving from a world where there's one "best model" to a world where the right model depends on the task. Coding agents will increasingly run on models you've never heard of, trained specifically for the workflows they execute. The frontier model becomes the fallback, not the default.
Each link below shares sources, entities, or timing with this story.
Cursor uses Opus / Shared entities / Same source / Shared topic / What happened next
Linked by a graph relationship (Cursor uses Opus); both cover Anthropic, Claude Code, Composer, Cursor; cite the same source (Cursor's Composer 2.5).
Linked by a graph relationship (Cursor uses Opus); both cover Composer, Cursor, Kimi K2, Opus; cite the same source (Cursor's Composer 2.5).
Cursor supports Claude / Shared entities / Same source domain / Shared topic / What happened next
Linked by a graph relationship (Cursor supports Claude); both cover Anthropic, Claude Code, Cursor, Windsurf; reported by the same outlet (cursor.com, windsurf.com).
Cursor benchmarked against Windsurf / Shared entities / Same source / Shared topic / Earlier coverage
Linked by a graph relationship (Cursor benchmarked against Windsurf); both cover Adaptive, Claude Code, Cursor, Opus; cite the same source (Adaptive model router).
Cursor benchmarked against Codex / Shared entities / Shared topic / Earlier coverage
Linked by a graph relationship (Cursor benchmarked against Codex); both cover Anthropic, Claude Code, Codex, Cursor; overlapping topics (code, coding, model).
Linked by a graph relationship (Cursor benchmarked against Codex); both cover Claude Code, Codex, Cursor, Kimi K2; overlapping topics (code, model).
Cursor supports Claude Opus / Shared entities / Same source domain / Shared topic / Earlier coverage
Linked by a graph relationship (Cursor supports Claude Opus); both cover Anthropic, APIs, Composer, Cursor; reported by the same outlet (cursor.com).
Cursor benchmarked against Codex / Shared entities / Shared topic / What happened next / Tension
Linked by a graph relationship (Cursor benchmarked against Codex); both cover Codex, Cursor, Opus, Windsurf; overlapping topics (code, coding, cost, model, token).