The Best Coding Model Isn't the Smartest One Anymore. Platforms Are Training Their Own.

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.