Cursor Router 路由机制解析：如何为任务选对模型

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

Numbers in graph reported relative to Opus 4.8

Cursor Router increases satisfaction and cuts cost vs. frontier models

Numbers in graph reported relative to Opus 4.8

Cursor Router increases satisfaction and cuts cost vs. frontier models

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, writing tests
• Modifiers capture characteristics that cut across domains and tasks, but may change which model performs best: bounded edits, product questions, visual-heavy changes

We then compare how different models perform across those categories. We found that no model dominates every kind of work, and each has categories where it outperforms:

• Grok offers strong value across broad, routine work. Its low inference cost made it especially effective for categories such as Git commands and general database operations.
• Sol performs especially well on planning and codebase comprehension. It also delivered strong results across several implementation tasks at a lower cost than other frontier models.
• Opus performs well on execution-heavy work. It showed particular strengths in devops, database queries, and performance optimization.
• Fable excels at debugging and visual implementation. Its quality gains were most valuable on complex tasks where they justified its higher cost.

Cursor Router uses those differences to match each turn to the model best suited to it.

#Combining into an algorithm

Compass and the taxonomy play complementary roles. Compass estimates the model-agnostic complexity of the turn and compares that score with a routing threshold. Depending on where the score falls, we either send the turn to Grok, given its low inference cost, or use the taxonomy to identify the frontier model with the strongest observed performance on that kind of work.

route(x)={price-efficient model,task router,​Compass≥τCompass<τ​

When Compass does send a turn to the taxonomy router, model selection follows two rules:

• Only route when performance is clearly better. A candidate model becomes eligible only when its observed performance on that task label clears a one-sided 75% uplift threshold against the price-efficient model. Roughly, this means we need 75% confidence that the improvement is real.
• Choose the best mix within the budget. From the eligible candidates, the optimizer chooses the traffic-weighted combination expected to deliver the largest performance gain while keeping the average cost per turn within the mode's budget.

Together, the Compass threshold and the task router's cost budget define each mode's position on the cost-performance curve. Auto Balance keeps more traffic on the price-efficient path and gives the task router a smaller budget. Auto Intelligence gives the task router more room to select frontier models when the expected performance gain justifies the cost.

#Evaluating performance in production

We evaluated our routing policies in two stages. First, we used cross-validation to tune the Compass thresholds and optimization budgets without overfitting to a particular split. We then evaluated the selected policies on a held-out test set that had not been used during training.