Cursor has made Cursor Router generally available for Teams and Enterprise plans. The system is a classifier that inspects each request before a model runs, then dispatches it to the model best suited to that specific task. The cursor team reports frontier-quality performance at 60% savings in online A/B tests, and 30–50% savings for early-access enterprise accounts.
The problem it targets is a spend pattern rather than a capability gap. Cursor states that roughly 60% of its developers pick a single model as a daily driver. Routine work therefore gets completed at frontier prices, and AI spend grows faster than output quality. Routing is Cursor’s answer to that mismatch.
What the classifier actually reads
Cursor Router is not a fallback chain or a retry mechanism. It is a classifier trained on 600k+ live requests, evaluated in an online A/B test across millions of live requests, and optimized for user satisfaction (AFC) as its reward signal.
For each request, the router analyzes four inputs: query, context, task complexity, and domain. It combines these with learned knowledge of each model’s behavior. Cursor publishes three routing rules that follow from that classification:
- Simple work goes to the most price-efficient models.
- UI updates go to the model with the best taste.
- Complex, long-horizon problems go to frontier reasoning models.
That third rule carries the weight of the cost argument. The savings do not come from downgrading hard problems. They come from removing routine work from frontier pricing while the difficult tier stays intact.
One implementation detail deserves attention from anyone who has built a router. Cursor Router is cache-aware in both training and evaluation. It is trained on a dataset where routing produces cache misses, and the reported cost savings include the cost of those cache misses. Switching models mid-conversation invalidates prompt cache, and that cost is real. Routers that ignore it overstate their savings.
The classifier was also designed for model churn. Cursor states it can update the router as newer models ship, which matters in a market where the frontier moves monthly.
Inside Cursor Router: classification, tiers and published results
Every figure below is taken from Cursor’s launch post and changelog (July 22, 2026). Values Cursor did not publish are marked as such.
Step 1 · Signals read before any model runs
Step 2 · Routing tier selected
Cursor’s description
Linear projection — drag to set monthly commit volume
| Model / mode | $ / commit | Monthly | vs Opus 4.8 |
|---|
| Element | What Cursor reports |
|---|---|
| Training data | 600k+ live requests |
| Reward signal | User satisfaction (AFC) |
| Evaluation | Online A/B test across millions of live requests, not offline evals |
| Quality metric 1 | User satisfaction — agent success classified from user responses. Moving to the next feature is a strong positive; correcting the agent is a strong negative. |
| Quality metric 2 | Keep rate — how much agent-generated code remains in the codebase over time |
| Metric track record | Both metrics used to evaluate every model launch and harness change for the past nine months |
| Cache handling | Cache-aware in training and evaluation. Trained on a dataset where routing causes cache misses; reported savings include cache-miss cost. |
| Platform scale | Cursor routes hundreds of millions of coding requests per week across models and providers |
| Problem being solved | ~60% of Cursor developers pick one model as a daily driver, putting routine work on frontier pricing |
