Introducing Cursor Router · Cursor

Concept 1: The Core Problem — One Model for Everything is Wasteful

The situation today:

• About 60% of developers pick a single AI model and use it for everything
• This means simple tasks (like a small UI tweak) get sent to the same expensive, powerful model as complex tasks (like debugging a multi-system architecture problem)

Why this is a problem:

• It's like hiring a senior surgeon to put on a bandage — the capability is there, but you're massively overpaying for the task
• AI spend grows much faster than output quality improves
• Routine work gets completed at frontier (maximum) prices unnecessarily

Key Insight: Not every coding task needs the most powerful model. Matching task complexity to model capability is the opportunity.

---

Concept 2: What is a Model Router?

Definition: A model router is a system that sits between your request and the AI models. Before any model runs, the router classifies your request and decides which model should handle it.

Think of it like a hospital triage system:

Applied to Cursor Router:

The router analyzes:

1. Your query (what you're asking)
2. Context (surrounding code, conversation history)
3. Task complexity (how hard is this?)
4. Domain (what kind of work is this?)

---

Concept 3: How Cursor Router Was Built and Trained

Training data:

• Trained on 600,000+ live requests from real developers
• Evaluated in online A/B tests across millions of live requests

What it optimizes for — the reward signal:

• User satisfaction (AFC): Did the user move forward, or did they correct the agent?
  • ✅ Moving on to the next feature = strong positive signal
  • ❌ Correcting the agent = strong negative signal
• Keep rate: How much of the AI-generated code stays in the codebase over time?

Why online A/B tests instead of offline benchmarks? Offline evals are small, artificial, and miss real-world nuance. Online tests capture real engineers writing real code, hitting real errors, across hundreds of requests per week — the actual conditions that matter.

Cache-awareness (an important technical detail):

• Switching models mid-conversation causes cache misses (extra cost)
• Cursor Router is trained on data where cache misses occur and evaluated including those costs
• This means the reported savings are honest — they already account for the switching overhead

---

Concept 4: The Cost-Intelligence Pareto Frontier

What is a Pareto Frontier? It's the set of best possible tradeoffs between two competing goals. Here, the two goals are:

• Higher intelligence/quality (costs more)
• Lower cost (may sacrifice some quality)

You can't improve both simultaneously — improving one comes at the expense of the other. The frontier represents the optimal tradeoffs.

Cursor Router's three modes let you choose your position on this frontier:

QUALITY
  ↑
  |  [Intelligence] ← Matches most powerful frontier models
  |
  |  [Balance] ← Matches popular daily-driver frontier models
  |
  |  [Cost] ← Highest intelligence while minimizing token spend
  |
  └─────────────────────────────→ COST (lower is better)

---

Concept 5: The Real-World Results

Online A/B test results (millions of requests):

• Auto Intelligence ≈ Fable quality at ~60% lower cost
• Auto Balance > Opus 4.8 satisfaction at ~36% lower cost

Early access enterprise results (thousands of users):

• 30–50% cost savings vs. routing everything to Opus 4.8
• No decrease in quality

Cost per commit (the metric engineering leaders care about):

Key Insight: Cost per request is only half the story. Cost per commit (actual shipped work) is what matters to engineering teams — and Cursor Router wins on that metric too.

---

Concept 6: Admin Control and Team Configuration

Who controls what:

ADMIN LEVEL
├── Enable/disable Cursor Router per team or group
├── Choose which modes (Intelligence/Balance/Cost) members can access
├── Set the default mode for the team
└── Allow or block specific underlying models

USER LEVEL
└── Select Auto mode in model picker → choose from available modes

This gives organizations top-down cost governance while still giving developers flexibility within set boundaries.

---

Concept 7: Router + Efficiency Improvements (The Bigger Picture)

Cursor Router is one piece of a larger token efficiency strategy. Choosing the right model only helps if the surrounding system is also lean.

Dynamic Tool Calling (a complementary optimization):

• Previously: All tool descriptions loaded into every prompt (wasteful)
• Now: Tools are looked up only when the model first needs them
• Common tools (read, edit) stay "hot" (cached/ready)
• Rare tools only enter the prompt when actually called

The combined effect:

Right Model (Router) + Lean Prompts (Dynamic Tools) = Maximum Efficiency

---

Summary: The Full Mental Model

Developer Request
       ↓
[Cursor Router Classifier]
  - Analyzes: query, context, complexity, domain
  - Trained on: 600k+ real requests
  - Optimizes for: user satisfaction + keep rate
       ↓
Routes to best-fit model
  ├── Simple task → Cheap, efficient model
  ├── UI work → Model with best taste
  └── Complex task → Frontier reasoning model
       ↓
Result: Frontier-quality output at 30–60% lower cost

The core value proposition in one sentence:

Cursor Router ensures you pay frontier prices only when you actually need frontier capability — automatically, on every request.