Let Cursor Router read the ticket via MCP before picking a model

Ideas Feature Requests
, , ,
1

Feature request for product/service

AI Models

Describe the request

In Auto mode, Cursor Router (Compass) runs a classifier on each request and routes on task type and complexity, deciding at the start of the response (docs). It is supposed to spend a cheap model on easy work and a frontier model on hard work. That only works if the Router can see how hard the work is.

In practice it often can’t. We don’t paste the spec into chat. We paste a Linear or Jira ID and say implement it. Those messages look the same: short, generic, Implement ENG-1234. The tickets behind them can be wildly different, from a one-word copy change to a platform rewrite, but the router only sees the ID. The real scope lives in the issue description. As a result, the Router is unable to pick a suitable model for the task. This isn’t an edge case. Pointing at an issue and saying “go” is how a lot of us start agent work.

Ask: before model selection, let the Router call tools on MCPs the user already connected (preferably read-only), then classify on the prompt plus that context.

It should detect IDs or URLs, fetch them with the available tools (e.g. Linear get_issue), run the classifier including that context, and then route as usual. It should prefer read operations: MCP readOnlyHint, Linear’s /mcp/readonly, or OAuth read. If the fetch fails or times out, keep today’s behavior.

Operating System (if it applies)

MacOS

4

Hey @ross, thanks for the suggestion, and you’ve read the mechanics right: today the Router classifies on the text of your message at the start of the turn, so “Implement ENG-1234” gives it very little to go on.

Two things that work right now: paste the ticket description into the prompt itself (the router reads the full message), or run it as two turns, first ask the agent to pull the ticket and summarize the scope, then send “implement it” in the same chat. The second turn is routed with that summary in view.

That said, I think this is a super intereting idea (let the agent make a few calls to collect the info before deciding on a model) and I’ve passed it onto the team!