How Cursor Router chooses the right model for the task · Cursor

Models →<br>Product →<br>Enterprise

Pricing

Resources →

Sign inContactContact salesDownload

Blog / research

On July 22, we launched Cursor Router with two new configurations, Auto Intelligence and Auto Balance. Since then, we have continued improving both modes as new models have arrived and our routing system has learned from more production traffic.

Today, Auto Intelligence delivers above Fable-level user satisfaction at 68% lower cost, a further 18% reduction since its launch. Auto Balance outperforms Opus 4.8 at 41% lower cost, a further 8% reduction over the same period, while further increasing user satisfaction by 3%.

We're working towards a Cursor Router that improves alongside the model frontier. This post explains how the current system works.

Cursor Router increases satisfaction and cuts cost vs. frontier models<br>Numbers in graph reported relative to Opus 4.8

Cursor Router increases satisfaction and cuts cost vs. frontier models<br>Numbers in graph reported relative to Opus 4.8

Cursor Router increases satisfaction and cuts cost vs. frontier models<br>Numbers in graph reported relative to Opus 4.8

#A data-driven approach to routing

Cursor Router is built around the idea that model selection should be learned from how models perform on real developer work, rather than inferred from benchmark scores.

The router makes each decision using signals from the current turn and recent conversation state. These include structured features such as the task category, along with recent tool calls and the broader context of the work.

From there, routing happens in two parts.

First, we need to decide whether a turn is simple enough for a price-efficient model. Compass, our complexity predictor, makes this decision.

Second, if the turn is more demanding, we need to decide which frontier model is most likely to perform well on that kind of work. To make that decision, we classify the turn using a taxonomy of tasks, domains, and modifiers learned from real developer traffic.

#Building a dataset

To develop the routing system, we first needed a dataset that reflected the conditions it would encounter in production. We built it from live Cursor traffic so it would preserve the actual mix of developer tasks, the context surrounding each turn, and the effects of switching between models.

As always, we respected users' privacy mode and data retention settings throughout this process.

The dataset contains hundreds of thousands of turns sampled across a range of models. Each datapoint includes the conversation signals available to the router, along with two outcomes we use to compare routing choices.

Performance. We infer performance from what the user does next. Moving on to the next task is a strong positive signal, while correcting the agent is a strong negative one.

Cost. We calculate cost from API pricing and token usage for that turn. Because the data comes from live traffic, it also captures costs that benchmarks often miss, including cache misses caused by switching models.

#Predicting complexity with Compass

Compass estimates the complexity of each turn by predicting whether the user will be satisfied with Cursor's response. We train it on the performance signal mentioned above.

We use the resulting prediction as a proxy for complexity. This works because users rarely ask for corrections after simple tasks, like making a commit, while they're more likely to make follow-up requests when the work is more complex.

We evaluated Compass online and confirmed that its scores are strong predictors of user satisfaction. Turns that Compass rated as most likely to succeed received a positive performance signal 96% of the time, while turns it rated as least likely to succeed received one 71% of the time.

Compass scores predict user satisfaction

Compass scores predict user satisfaction

Compass scores predict user satisfaction

In practice, Compass assigns each turn a continuous complexity score between 0 and 1. We set a threshold within that range to determine which turns stay on a price-efficient model and which are upgraded to a frontier model. Lower thresholds keep more traffic on the price-efficient model, while higher thresholds upgrade more often.

Raising the Compass threshold trades cost for more quality gain

Compass threshold sweep

Raising the Compass threshold trades cost for more quality gain

Compass threshold sweep

Raising the Compass threshold trades cost for more quality gain

Compass threshold sweep

#Learning model strengths

After Compass tells us when a turn is complex enough to justify using a frontier model, the next question is which frontier model to use.

To answer it, we built a taxonomy from real developer traffic that describes each turn across three dimensions:

Domains identify where the work happens: backend, database schemas, frontend

Tasks identify what the developer wants done: fixing bugs, running commands,...