Cursor Router Updates Auto Intelligence and Auto Balance

Cursor has published a new look at Cursor Router, the system it uses to choose models for individual turns. In an approved post, Cursor said the router is improving from millions of in-product interactions each week and classifies and routes requests to lower latency and cost based on the task. (Cursor on X)

The durable Cursor Router engineering write-up explains that the system uses the current turn and recent conversation state, including task category, recent tool calls, and the broader context of the work. Cursor says the router is meant to choose models based on how they perform on real developer work rather than on benchmark scores alone.

Two ways to use the router

Cursor says it launched two Router configurations on July 22:

• Auto Intelligence aims for a higher-quality frontier-model mix while keeping the average cost within its budget.
• Auto Balance keeps more traffic on the price-efficient path and gives the task router a smaller budget.

Cursor reports that Auto Intelligence delivers above Fable-level user satisfaction at 68% lower cost, including an 18% cost reduction since launch. It reports that Auto Balance outperforms Opus 4.8 while further increasing user satisfaction by 3%, at 41% lower cost and with an 8% reduction since launch. These are Cursor’s own production measurements, not an independent benchmark. (Cursor’s Router write-up)

The two modes therefore represent a choice on the cost-performance curve rather than two fixed model names. Cursor says Auto Intelligence gives the task router more room to select a frontier model when the expected performance gain justifies the expense, while Auto Balance favors the cheaper path more often.

How model selection works

Cursor describes Router as a two-stage system. First, Compass, its complexity predictor, estimates whether a turn is simple enough for a price-efficient model. The predictor uses a continuous complexity score from 0 to 1 and a threshold to decide when a request should be upgraded.

Cursor says Compass learns from what users do next. Moving on to the next task is treated as a strong positive signal, while correcting the agent is treated as a strong negative signal. That lets the routing system learn from outcomes in actual developer workflows rather than relying only on a prebuilt benchmark.

For turns that need a frontier model, a second taxonomy classifies the work and identifies which model has shown the strongest observed performance for that kind of task. Cursor says the taxonomy covers domains such as backend, database schemas, and frontend; tasks such as fixing bugs, running commands, and writing tests; and modifiers such as bounded edits, product questions, and visual-heavy changes. (Cursor’s Router write-up)

Why the model can change by task

Cursor’s announcement says no model dominates every kind of task. Its thread describes Grok 4.5 as strong value for routine work, GPT-5.6 Sol as effective for planning and codebase comprehension, Opus 5 as strong on execution-heavy work, and Fable 5 as especially useful for debugging and visual implementation. (Cursor on X)

The point is not that one model is always cheapest or always best. It is that the router can spend more of the budget where the task-specific quality difference is meaningful, while keeping routine turns on a lower-cost path when the expected result is good enough.

What Cursor says it learned from production traffic

Cursor says its routing dataset contains hundreds of thousands of turns sampled from live Cursor traffic. Each datapoint includes the signals available to the router, a performance outcome, and a cost outcome. The company says it respected users’ privacy-mode and data-retention settings while building the dataset. (Cursor’s Router write-up)

The write-up reports that Compass’s highest-confidence turns received a positive performance signal 96% of the time, while its lowest-confidence turns received one 71% of the time. Cursor also says it uses cross-validation, a held-out test set, and live-traffic testing to measure actual per-turn cost and user satisfaction.

Those measurements should be read as a description of Cursor’s internal evaluation, not as a universal ranking of the named models. Results can vary with task mix, prompts, context, caching, and the mode’s budget.

What changes for Cursor users

Cursor describes Router as available through Auto Intelligence and Auto Balance. The practical change is that users can select a cost-performance preference instead of manually choosing a single model for every turn, while the system chooses among models based on the work in front of it. (Cursor’s Router write-up)

Cursor says it has already added Opus 5 to the routing mix, improved Compass’s predictions, and moved both modes farther beyond the cost-performance frontier. The company plans to keep updating the router as new models arrive and as production outcomes provide more signal.

Bottom line

Cursor Router is a model-selection layer built around task complexity, observed developer outcomes, and a cost budget. Auto Balance favors efficiency, while Auto Intelligence gives the router more room to spend on frontier models when Cursor expects the quality gain to matter. The headline savings and satisfaction figures are Cursor’s own production claims, but the underlying direction is clear: model choice is becoming an adaptive part of the coding workflow rather than a one-time setting.

Sources

• Cursor, “How Cursor Router chooses the right model for the task,” August 6, 2026: https://cursor.com/blog/how-cursor-router-works?v=2
• Cursor announcement on X: https://x.com/cursor_ai/status/2085390483740676365
• Cursor model-selection thread on X: https://x.com/cursor_ai/status/2085390485502239171