Show which model handled each step when using Auto mode

Ideas Feature Requests
,
1

Feature request for product/service

Cursor IDE

Describe the request

Feature request for product/service

Cursor IDE (Agent / Chat)

Describe the request

When Auto is selected, Cursor routes each request to a different underlying model. That’s useful, but today there’s no way to see which model actually handled each turn or agent step after the fact.

The UI only shows “Auto” as the selected model. Local agent transcripts don’t include model metadata per message. The usage dashboard aggregates Auto + Composer pool usage but doesn’t expose per-step routing decisions.

This makes it hard to:

  • Debug quality regressions — “this answer was worse than yesterday” with no way to know if the router picked a lighter model
  • Build trust in Auto — users can’t tell if a complex task got a capable model or a fast/cheap one
  • Audit subagent routing — subagents may run on different models, but the parent chat doesn’t surface what ran where
  • Compare cost vs quality — Premium shows model per request on the usage page; Auto does not

Proposed solution

Minimal viable observability:

  1. Per-message badge or tooltip in chat/agent UI showing the resolved model (e.g. “Composer 2.5”, “Claude Sonnet”) for each assistant turn
  2. Subagent steps should show both agent name and resolved model
  3. Optional detail panel (click to expand) with model id, reasoning effort / thinking mode if applicable
  4. Usage dashboard parity — per-request breakdown for Auto-routed requests, same as Premium
  5. Transcript export — include model_id in exported/local transcript JSONL for debugging

Why this matters

Auto is positioned as the default for everyday agentic coding and draws from a generous included pool. Observability is the missing piece: even if I keep Auto as the default, I need to know afterward what model handled each step — especially for production code changes where quality and predictability matter.

Related community sentiment: several threads mention wanting visibility into Auto’s routing decisions rather than a black box.

Tags (if applicable)

auto-mode, agents-window, composer, subagents

Operating System (if it applies)

Windows 10/11

7

Hi @Jose_E_Carrillo Thank you for forum post! Right now there is not a way to see the exact model used when choosing Auto. Auto intelligently balances quality, speed, and cost — Cursor dynamically picks the best model for each request based on the task at hand and which models are available at that moment. It also takes into account regional availability and load (e.g. if a particular model has very high load / availability issues, auto will route around that).

If you need to choose a particular model, you can pick one from the model picker.

9

While waiting for first-party UI support, it’s worth noting that Cursor does record the resolved model per assistant turn in its local SQLite database - it’s just not surfaced anywhere.

state.vscdb (in ~/Library/Application Support/Cursor/User/globalStorage/ on macOS) has a cursorDiskKV table with keys like bubbleId:<composerId>:<index>. Each value contains modelInfo.modelName with the actual resolved model slug, even for Auto-routed turns. You can query it read-only:

SELECT key, json_extract(value, '$.modelInfo.modelName')
FROM cursorDiskKV
WHERE key LIKE 'bubbleId:%'
ORDER BY json_extract(value, '$.createdAt') DESC
LIMIT 20;

There’s also ~/.cursor/ai-tracking/ai-code-tracking.db which records per-code-block model attribution (ai_code_hashes table) - so Cursor already knows which model wrote which lines.

And for hooks users: the beforeSubmitPrompt hook payload already delivers model, model_params (thinking level), and composer_mode per turn at submit time - so you can log per-turn model/mode data to a local JSONL file today. (The transcript JSONL sadly doesn’t include model metadata per message, as the OP noted.)

None of this replaces proper UI - a per-message badge or tooltip showing the resolved model is the right solution. But the data exists locally if anyone wants to build tooling around it in the meantime.

11

I think this is great, but it would still be helpful to know what the breakdown was for model usage at each step.