Router Picks Models Inside Cursor

router is an open-source model router from Weave that sits between coding agents and model providers, then chooses a model for each request. For Cursor, Anysphere's AI code editor, the practical answer is simple: keep Cursor skills focused on reusable work, and let a router experiment only if model cost or model choice is already painful.

A model router is a proxy that receives an AI request, scores it, and forwards it to a selected model instead of always using one fixed model. If you are learning how to use cursor skills, this story is useful because routing only works well when your prompts, rules, and skills are clear enough to be routed safely.

As of July 3, 2026, the GitHub repository had 704 stars, was mainly written in Go, and described itself as a drop-in proxy for Anthropic, OpenAI, and Gemini-style traffic. The interesting bit is not that another proxy exists. It is that the proxy is aimed directly at developer agents such as Claude Code, Anthropic's coding agent, Codex, OpenAI's coding agent, Cursor, and similar local workflows.

Understand what router is trying to remove

The pain behind router is familiar: coding agents are useful enough that people leave them on all day, and the bill starts to look like infrastructure. Weave's stated motivation was that they write a lot of code with AI, and a newer expensive model made the cost jump sharper than they wanted.

The router pitch is one endpoint. Point an agent at localhost:8080, keep provider keys on your machine, and let the router choose among enabled models per request. The README says it supports Anthropic Messages, OpenAI Chat Completions, Gemini native traffic, streaming, tools, vision, and OpenAI-compatible endpoints through providers such as OpenRouter.

The trick is that the router says it uses a small local embedder and a cluster scorer, not another big prompt to decide where a request should go. That matters. If the routing decision itself required a large model call, the cost story would get muddy fast.

A concrete Cursor example: a request like “rename this React hook and update tests” probably does not need the same model as “debug this flaky concurrency failure across three packages.” If both go through the same expensive model, you pay for caution every time. If both go through a naive cheap model, you may pay in retries.

The trap is pretending routing is magic. It is still an extra decision layer. If the chosen model fails, stops early, loops, or misses a repo convention, the user experiences that as a worse agent, not as a clever cost optimization.

Why the Hacker News thread got skeptical

Developers cared because the idea sits right on a current AI-coding nerve: smarter agents are getting better, but using the best model for every turn is wasteful. The repository's promise of cutting costs by changing an endpoint is exactly the kind of thing a heavy Claude Code, Codex, or Cursor user will click.

The strongest objection was caching. If one provider or one model gives you useful prompt-cache hits, spreading requests across models can reduce those hits. A router that saves money on token price can still lose money if it destroys a cache pattern that was doing real work.

That objection is fair. Routing is easiest to justify when your workload is mixed and cache reuse is not already carrying the bill. It is harder to justify when you run a stable, repeated, high-context workflow where one model's cache TTL and prompt shape are already tuned.

The second objection was quality drift. Smaller or cheaper models can stop too soon, miss tool-call conventions, or turn a simple edit into a loop. In a coding agent, one bad turn can force the next turn to spend more context explaining and repairing it.

This is where Cursor rules and skills become part of the story. A router can choose a model, but Cursor skills and repo rules shape the request it receives. Cleaner instructions make routing less fragile. Messy instructions turn every model choice into a gamble.

Put Cursor context before model choice

Cursor has several layers that matter before you add a model router: Agent mode, rules, skills, and MCP. The useful order is boring and strong: make the repo understandable first, then experiment with routing.

Use AGENTS.md or Cursor rules to state durable repo boundaries. Use cursor skills for reusable tasks such as “add a database migration,” “write a Playwright test,” or “prepare a release note.” Use MCP only when the agent needs live external context, such as issues, docs, or design data.

Here is a small Cursor rule stub that keeps a routing experiment honest:

---
description: Keep AI edits small and reviewable when testing model routing
alwaysApply: true
---

When editing this repo:
- Prefer one focused change per request.
- Do not rewrite unrelated files.
- Run the narrowest relevant test before claiming success.
- If a model cannot complete a tool call twice, stop and ask for human review.
- Mention which files changed and why in the final response.

That rule does not make the router smarter. It makes failure cheaper. If a routed model picks the wrong approach, the blast radius is smaller and the review is easier.

A good Cursor skill should do the same thing for repeated work. For example, a write-api-test skill can include the test naming pattern, fixture setup, local command, and review checklist. Then the router sees a clearer request, and the human sees a smaller diff.

For more on the surrounding Cursor pattern, the related training topic is the right place to connect cursor subagents, cursor skills, rules, and MCP without turning this router story into a generic setup guide.

Try router when cost is real, not theoretical

The best first experiment is not “route everything.” It is one narrow workflow where you already have enough volume to compare cost, latency, cache behavior, and review quality.

Pick a repeatable lane. Good candidates are small refactors, test generation, dependency updates, or doc edits in a repo with stable conventions. Bad candidates are production incident debugging, security-sensitive migrations, or anything where the failure mode is subtle and expensive.

If you want to know how to use cursor skills alongside a router, start by writing one skill for the lane you plan to test. The skill should make acceptance criteria explicit enough that any model has to satisfy the same bar.

A minimal Cursor skill acceptance rubric:

For a router trial, pair that rubric with one Cursor review checklist:

Router trial review

- What model was selected for the request?
- Did the agent follow the relevant Cursor rule or skill?
- Was the diff smaller than 300 lines?
- Did the agent run or name the narrowest useful test?
- Did caching appear to help or disappear for this workflow?
- Did a human need to repair the first answer?
- Would we accept this result from our default model?

That last question is the one to keep. A cheaper result that your reviewer would not accept is not cheaper. It is deferred work.

Use this fit table before changing endpoints

Router is worth trying when your model usage is varied, expensive, and observable. It is overkill when your current setup is cheap enough, highly cached, or dominated by one kind of hard reasoning task.

The practical implementation path is small. Run router locally, point one agent workflow at it, keep the default model path available, and compare real receipts. Do not judge it from one impressive demo or one bad completion.

The Cursor-specific trap is mixing too many changes at once. Do not add a new router, new cursor agent skills, new MCP servers, and new repo rules in the same experiment. Change one layer, or you will not know what improved.

If you need stricter repo boundaries before trying this, Cursor Guardrails for Real Teams has the safer prerequisite pattern.

Common questions

• Is router different from Cursor Auto?

  Yes, router is a separate local or hosted proxy that sits at the API endpoint layer, while Cursor Auto is a Cursor product behavior inside the editor experience. The practical difference is control surface: router is about forwarding requests across providers and models, while Cursor's built-in behavior is configured through Cursor itself.

• Does model routing save money if prompt caching gets worse?

  Not always. The cache objection is real: if a single-model workflow gets strong cache hits, routing across models can erase some of that advantage. A fair test should compare total cost per accepted change, including retries, failed tool calls, and lost cache benefits, not just headline token prices.

• How should I use Cursor skills with a router?

  Use Cursor skills to make the task repeatable before you test routing. A good skill names when it should activate, what files or commands matter, what output is acceptable, and how to verify the result. That gives every routed model the same contract and makes review less dependent on chat memory.

• Should I route hard debugging tasks to cheaper models first?

  Usually no. Start with low-risk, repeatable work such as tests, docs, small refactors, or mechanical updates. Hard debugging often needs long context, careful reasoning, and fewer false starts. If a cheap model creates a bad theory, the expensive model may spend more tokens cleaning up the mess.

• What should I measure in a Cursor workflow?

  Measure accepted changes, not only request cost. Track selected model, latency, retries, cache behavior, diff size, tests run, and whether a human repaired the output. A simple review checklist inside the pull request or commit note is enough for a first pass.

Best ways to use this research

• Best for: Cursor users already spending enough on agentic coding that model choice is a real budget line, not a curiosity.
• Best first artifact: One Cursor skill acceptance rubric for a repeatable workflow, plus a small rule that limits diff scope and requires verification.
• Best comparison angle: Compare router against your current default model on cost per accepted change, cache behavior, latency, and repair rate.
• Best place to be careful: Workflows with strong prompt-cache reuse, subtle correctness requirements, or missing repo rules.

Further reading

• Cursor — Agent
• Cursor — Rules
• Cursor — Skills
• Cursor — MCP

Next step

Pick one low-risk Cursor skill, run it through your normal model path and router, then compare accepted diffs instead of vibes. If the routed path is cheaper and just as reviewable, you have a real signal.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.