Cursor launched Router, a layer that sits in front of the various models Cursor already offers and decides, on a per-request basis, which one should actually handle a given coding task. It isn't a new model itself; it's a classifier that reads the incoming request together with its context, estimates how complex the task is and what domain it touches, a one-line rename versus a multi-file refactor versus a UI polish pass, and then sends it to whichever available model is predicted to produce an acceptable result at the lowest cost. Cursor says the classifier was trained on more than 600,000 real requests and validated against millions more in a live A/B test, and that it accounts for cache hits and misses so the cost estimates reflect what teams actually pay rather than a theoretical per-token price. The practical pitch is that engineering teams no longer have to manually pick a model for every task or standardize on a single expensive frontier model just in case a hard problem comes up. Cursor's own numbers claim roughly 60% lower cost than routing everything to Opus 4.8, and early enterprise customers using it during a preview period reported 30-50% savings while keeping output quality close to frontier level. Router ships as the default routing behavior for Cursor Teams plans and as an opt-in toggle for Enterprise admins, and it's available across desktop, web, iOS, the CLI, and the SDK. For any team currently burning budget on frontier-model-for-everything policies, or manually toggling between models depending on task difficulty, this is a concrete example of model routing moving from a DIY infrastructure project into a built-in product feature, worth evaluating even if you don't use Cursor directly, since it signals where IDE-embedded AI tooling is heading on cost control.