Model routing: the quiet revolt against the one-big-AI fantasy
AI model routing is the practice of using software to automatically choose among multiple AI models for each task, sending simple requests to cheaper, faster local models while reserving frontier models in the cloud for complex problems, with the goal of improving cost, speed, and control without forcing users to manually understand or compare model performance themselves. That definition gets to the heart of why routers are suddenly everywhere: the industry has quietly accepted that one universal AI model is a fantasy and that practical AI means orchestration. Nvidia’s Joey Conway says it plainly: “Tasks vary in complexity, so the models handling them should vary too.” That statement is as much a critique of single-model thinking as it is a roadmap. Frontier models are powerful, but the idea that they should answer every query from "two plus two" to a multi-step legal analysis is wasteful on cost, time, and infrastructure. The new orthodoxy is a bench of specialists behind one interface. Users see a single chat box or coding window; under the hood, a router decides whether the request hits a small open model on a local machine or a frontier model in the cloud. This isn’t a minor implementation detail. It is the architectural bet that will separate sustainable AI products from those burning cash to pretend a single model can do it all.
Nvidia’s “system of models” makes local vs frontier a feature, not a bug
Nvidia has become the most vocal champion of treating AI as a system of models instead of a monolith. Its view is blunt: local and frontier models are complementary tools, and the router is the brain that decides who does what. Conway notes that models small enough to run “on the box on your desk” are now good enough that the real question is how to use them, not whether they work. That box can be powerful. Nvidia points to DGX Spark, a USD 4,699 (approx. RM21,700) Grace Blackwell machine with 128GB of unified memory that can handle models up to roughly 200 billion parameters without anything leaving your desk. When you need more power for broader problems, you reach for a frontier model in the cloud. The pattern is clear: route trivial or data-sensitive tasks to local models that are quick and under your control, and route hard tasks to more sophisticated models that justify their higher cost. Done well, Conway argues, this “lets you get a better outcome at a lower cost and lower time to completion.” The user experience, critically, remains simple: “It’ll feel like one interface,” he says, with a variety of models quietly handling a variety of tasks behind it.
Cursor and Ramp: routers as cost optimization AI, not mere infrastructure
Startups and large software firms are no longer treating routers as plumbing; they are selling them as cost optimization AI products. Cursor, the AI coding tool recently acquired by SpaceX in a USD 60 billion (approx. RM276 billion) all-stock deal, has launched Cursor Router to direct every coding request to whichever model handles it best and avoid paying frontier prices for work that does not need it. Under the hood, Cursor Router triages requests like a hospital emergency room, examining how hard the problem is, what it is for, and the surrounding code, then choosing a model that fits. Simple fixes get routed to something cheap; hard problems are escalated to frontier-grade models. Cursor reports that early access customers saved 30–50% compared to routing everything through Opus 4.8, with no loss in output quality. Ramp, a USD 44 billion (approx. RM202 billion) spend-management company, built Ramp Router for its own AI bills and claims roughly 30% savings on large language model costs. It has now opened that router to others, routing across OpenAI, Gemini, and select open-source models via an OpenAI-compatible endpoint that is free to start and does not require a Ramp account. The message from both firms is pointed: if you are still sending every request to a single model, you are overspending and under-optimizing.
Model ambitions meet multi-model strategy: Cursor, Meta, and the router paradox
What makes this moment more interesting is that the companies building routers are also chasing their own frontier and local models. Cursor is the clearest example. In May, it released Composer 2.5, an update to its in-house coding model built for long tasks at a lower cost than frontier options from Anthropic and OpenAI, based on Moonshot AI’s Kimi K2.5 open-weight model. Then, on July 8, Cursor and SpaceXAI jointly released Grok 4.5, a mixture-of-experts frontier model built on a new V9 foundation with roughly 1.5 trillion parameters, trained on trillions of tokens of real Cursor usage data and sold at USD 2 (approx. RM9.20) per million input tokens and USD 6 (approx. RM27.60) per million output tokens. Cursor now has its own local-style Composer for cheap work and a Grok-branded frontier line for heavy lifting, plus third-party models. The obvious move would be to route everything to its own stack and keep the money in-house, but Cursor Router intentionally sends each request to whichever model suits it best, Cursor’s own or not. That is a strategic concession: controlling the whole stack matters, yet forcing one model on every task is worse for quality and cost. Ramp’s router emerged from the same instinct to control AI spend, and reports suggest Meta is building a model router as well. These are not neutral brokers; they are model players building routers that have to treat their own models as first among equals, not the only choice. The paradox is healthy: it forces them to admit that even their models are sometimes the wrong tool for the job.
The end of single-model thinking
The rise of AI model routing is more than a technical trend; it is an ideological shift away from the belief that one frontier model can or should do everything. Nvidia’s “system of models” framing makes local vs frontier models a design decision based on cost, speed, and control, not a question of loyalty to one vendor. Cursor, Ramp, and Meta’s router projects show that serious AI companies are willing to route around their own models when another option is a better fit. The trigger is practical pain. Local and open models have become capable enough that ignoring them wastes money and limits control. Meanwhile, most developers still pick one model and stick with it regardless of the task, “billing simple work at frontier prices it doesn’t need.” Routers are the way out: they automate the trade-offs that engineers currently juggle by hand and expose AI as a utility that can be optimized, not a single deity that must be worshipped. If AI remains a single-model story inside your product, you are now behind. The forward-looking strategy is a multi-model system governed by an opinionated router that treats cost, latency, and quality as levers. The companies building those routers are not hedging; they are admitting that the future of AI is many models, smartly stitched together.
