ok - my issue is that cursor was showing just “fast” in the model select prompt - I had not idea that it had auto switched to an expensive grok model and ate all my credits - prompting me to write a plugin that reports the model and provider source directly in the prompts - so I could avoid that issue. now it appears that I can not actually accurately determine those 2 attributes.
write me a forum post explaining the reasoning I just presented, the problems you outline that prevent accuracy and my request, which is: "add model and provider source to the context available to the model OR make the full response context available to the model if needed (specifically for situations like this)
Problem Background & Motivation
Recently, I experienced unexpected credit depletion because the UI model selector displayed a generic tier label (such as “fast”) while automatically routing to an expensive high-tier model behind the scenes without clear visual indication.
To prevent this and maintain full visibility over spend, I developed a custom guardrails plugin and workspace rules. The goal was simple: require the agent to prepend and append a verified transparency banner to every response stating the exact active model and underlying provider/routing source (e.g., Cursor Native vs. OpenRouter vs. Direct API).
Current Technical Limitations
While attempting to implement this via prompt rules and agent hooks, we ran into fundamental visibility limitations in the agent runtime:
No Routing or Source Telemetry: The agent runtime has no visibility into where requests are physically dispatched. The model cannot inspect outbound HTTP headers, proxy configs, or provider routing.
String-Matching Heuristics: The agent can only read the static model string injected into its initial prompt text (e.g. You are an AI coding assistant, powered by ...). Determining whether a model is routed through Cursor’s infrastructure, an OpenRouter custom key, or an upstream fallback requires brittle string parsing and guessing.
No Upstream Response Metadata: The agent never receives the raw HTTP response object, provider billing payload, or server response headers. These are stripped before context reaches the agent, making it impossible for rules or local plugins to accurately verify what served the request or what concrete usage occurred on that turn.
Feature Request
To allow users and plugin developers to build reliable cost controls and transparency tooling, please implement one of the following:
Inject Verified Model & Provider Context: Include structured, verified runtime metadata in the agent environment (e.g., inside <user_info> or environment variables) that explicitly provides:
active_model_id (the exact canonical model identifier)
Expose Response Metadata: Provide an optional runtime hook or expose provider response headers/metadata to the agent context (or plugin sandbox) so local guardrail plugins can accurately report actual model usage and routing on every turn.
This visibility would make session-level cost guardrails much more dependable and eliminate guesswork around model routing and credit consumption.
Hey, thanks for the detailed breakdown @BigBlock_Studios. I’ll quickly correct one key point since it affects the whole motivation. What you saw, Fast instead of the model name, is a new model picker layout we’re testing. In the collapsed view, some models show the effort or speed level High or Fast instead of the name. The actual model does not change behind the scenes, and Auto did not silently switch to a different model. If you open the picker, you can see exactly which model is selected.
You can verify the model that was actually used for each request on the dashboard under usage. It shows the specific model and mode per request.
Now about your request for programmatic visibility for guardrail plugins.
The hook payload already includes the configured model via the model, model_id, and model_params fields. A plugin can read those today.
Verified served model, provider source, and billing tier are not currently passed through in agent context or hooks. You’re right, you can’t reliably extract that from the prompt.
I shared your detailed request for verified model and provider metadata in the context with the team as a feature request. I can’t share a timeline yet, but the idea is logged. Let me know if you still have questions about the current verification paths, the picker and the usage page.
Ah! ok - you say “the hook payload” - I am not making use of hooks in the transparency plugin!
I can work on that
So as for provider, the prompt request goes somewhere and comes back from somewhere … are those urls/addresses available in a hook as well - I can make a best guess using that..
Playing around with this .. the response payload for afterAgentResponse and afterAgentThought only ever show “default” for model and model_id. “model_params” only ever show up when using beforeSubmitPrompt hook (which is kinda not the point)
This does change when using a different providers model - when selecting an open router provided model I get the expected values in the response model and model_id parameters.
sooooooo is there a different hook that I should be looking at?
Under what conditions would the hook return a cursor provided model response that is not “default” ?
Hey, good experiment, and the result makes sense. The key point is that the hook gets the configured model, not the one that actually served the request served or routed.
When you pick a specific model via OpenRouter, that model is the configured value. That’s why model or model_id shows the real value. But with Cursor-native Auto or default routing, the server picks the specific model later, after the hook payload is already built. At that point the configured value is still the generic one, so you see default.
Answering your questions directly:
There isn’t another hook right now that returns the served Cursor-native model. No hook includes that metadata.
A Cursor-native response will only return something other than default if you explicitly lock a specific model in the selector, not Auto. In Auto mode, you can’t get the served model via hooks.
The upstream URL or address also isn’t included in the hook payload. Provider source and response headers don’t reach hooks or plugins, so you can’t make a reliable best guess from them.
So yes, this is exactly the gap you described in your request: the verified served model and provider source aren’t programmatically available right now. I passed this to the team, but I can’t share an ETA yet.
For now, the only reliable way to see which model actually served the request is in the dashboard under usage. It shows the exact model and mode per request. Let me know if you find anything else while testing hooks.
Actually - it does not, only when the model is specifically selected - otherwise it just shows “auto”
The hooks do provide token and cache totals, which is nice to indicate when something is using a lot of tokens or the context window is getting full - but does not give any insight into probable cost when the model name/id is missing…
For those of us who need to count our pennies it’s pretty important to know which models are giving quality results for our workload/code base and which are not. It’s also good for UX and transparency - my little response footer gives me a good summary of what happened without having to examine/expand every little inline prompt the agent outputs (thinking, used 3 tools, grepped … etc) - those can sometimes fly by pretty fast too. We definitely need to double check the agents, but micromanaging them is defeating the purpose…
we know we can’t trust the model, speed and source - tokens is not accurate but can be a good indicator - Graphify, tools and skills use is super handy - particularly when the agent should be using them and doesn’t
I guess the feature request here is either a response footer showing the actual model used, it’s params and the source/provider or at least providing that in the responses so we can roll our own summaries.
( I have my plugin logging raw requests/responses so I can pull a session summary as well)
What we have now is a real black box - stick your finger in and trust for the best - if my finger hurts I want to know a doctor looked at it - not a plumber…
You’re right, and thanks for clarifying. I wasn’t precise.
For individual Auto usage, the page really doesn’t show the served model, it stays as auto. Full per-request model and mode is only visible on the dashboard for Cursor Router on Teams or Enterprise, with the admin toggle Underlying model enabled. For regular Auto on Pro, that attribution isn’t available right now on the dashboard or in the hook payload. You see default because the configured model is auto, and the specific server model is chosen only after the payload is built.
So yes, this is exactly the gap you described. The verified served model and provider source aren’t programmatically available in Auto today. Tokens and cache totals from hooks are the only thing you can use as a signal.
I shared your reworded suggestion with the team along with the original request, like adding a response footer with the real model, params, and source, or returning that data in responses so you can build your own summaries. There’s no timeline or ETA yet, but the idea is logged. I’ll reply in the thread if there’s an update.
If you find anything else useful while experimenting with hooks, drop it here. I’m curious.
