Hey, thanks for the report. This isn’t mis-billing. Your main CLI agent is actually running on Grok 4.5, as selected.
gpt-5.6-sol-medium shows up in usage because of Task sub-agents that the Grok agent spins up during the task. Key detail: sub-agents don’t automatically inherit the model you picked. By default, they go to a separate model, usually a lighter one, and they only inherit the parent model in Max Mode. Also, the parent agent can explicitly pass a model into the sub-agent call, which is why you can see usage grow under a different model name.
If a sub-agent is picking an expensive model despite your sub-agent model settings, that’s a known bug. The parent injects model into the Task call. We’re tracking it, but there’s no ETA for a fix yet. To help me verify on the backend which model was actually used, please send the Request ID right corner of the chat > Copy Request ID with Privacy Mode turned off.
How to reduce this right now:
Hide or disable expensive models you don’t want sub-agents to use in Settings > Models, then the agent can’t choose them.
Your workaround also works: start a new session and explicitly say not to use other models.
Let me know how it goes, and send the Request ID. I’ll check what actually happened.
Thanks, got the Request ID 202bb3c8-0df8-4945-8eed-a71e98ceb85d - I’ll check on the backend what actually ran there.
And sorry, I mixed things up on Settings > Models earlier. That enable/disable toggle lives in the Cursor desktop app (Cursor Settings > Models), not in the CLI or the web dashboard. In the CLI you pick your main model via /model, but there’s no UI to globally disable specific models for sub-agents yet.
One thing that does work in the CLI, though: you can define custom sub-agents in ~/.cursor/agents and pin a model: in the definition. When the agent calls one of those, it’ll use the model you set. Two caveats:
Use a valid Cursor model slug. If the CLI can’t resolve it, it silently falls back to your session model (that’s a separate known bug), so it looks like the setting didn’t take.
This pins the sub-agents you define and invoke yourself. It won’t stop the parent agent from spawning its own Task sub-agents and picking a model for them, which is where the gpt-5.6-sol-medium usage came from.
So if you mostly work via CLI, the most reliable options are still: start a new session and explicitly tell it not to use other models, or install the desktop app on the same account and hide the expensive models there so the agent can’t pick them.
Let me clarify and also fix what I said above about Settings. For CLI, the situation is more accurately like this.
Hiding models in Settings is a client-side preference, not a hard server-side block. The backend routing can still see the model, and a sub-agent can still pick it. So it doesn’t work as a guarantee against using an expensive model, not in desktop and not in CLI.
What you can actually do in CLI:
Set the model for your own sub-agents via frontmatter in ~/.cursor/agents/*.md:
Important: use a valid slug list it via cursor-agent --list-models, otherwise the CLI will silently fall back to the session model. Also, this only pins sub-agents that you define and call yourself. The parent agent can still spawn its own Task sub-agents and choose their model, which is where gpt-5.6-sol-medium came from.
Pin the main agent model at launch:
cursor-agent --model grok-4.5
For Task sub-agents that the agent calls automatically, model in CLI currently only gives composer-2.5-fast. The only way to move them off the fast tier is to not set model, then they inherit from the parent.
There is no guaranteed local way to block a sub-agent from using an expensive model in CLI yet. Real server-side model enforcement exists only for Team and Enterprise via the team dashboard. This is a known limitation, and I can’t give an ETA for expanding sub-agent model selection in CLI.
Let me know if anything behaves differently from what I described.
Same pattern here. Facts only from my machine (Cursor desktop, Windows), Aug 10–11 2026.
What I selected
Chat model picker: Grok / grok-4.5 for a multi-day Agent session on a uni-app chart/history bug.
What local storage shows (same machine)
Parent chat bubbles in %APPDATA%\Cursor\User\globalStorage\state.vscdb (cursorDiskKV / bubbleId:*) carry modelInfo.modelName = grok-4.5 and have requestIds (examples from that chat: 9ad5f627-7e2a-4f43-a4c4-59259042faeb, a3dbe72f-ebd3-4612-8e00-040a09d5af72, 0336ed43-c5dc-40ad-978d-b5c857ddee9b).
In the same DB, composerData:* entries also record composer-2.5 / composer-2.5-fast (and related slugs) far more often than grok-4.5.
agentKv:* samples include cursor-grok-4.5-medium-fast and at least one composer-1.
The agent transcript for that session contains multiple Task tool calls with an explicit "model": "fast" (not the parent Grok slug).
What happened in the work (Aug 10–11)
Same Agent chat was used for a CSS fake-landscape history-chart fix.
The agent repeatedly claimed a “unified chart interface,” but kept three near-duplicate skeletons (basic/cell/satellite) and only shared tiny helpers—not a real shared contract. I had to call that out; only then was a mixin/finalizeHistoryChartLayout path introduced.
Cell legend vs Y-axis overlap was “fixed” by a cell-only helper, then had to be pushed back into the shared layout path after I asked why a “unified” API still special-cased one chart.
Alarm-entry satellite auto-tooltip and cell legend alignment were asserted as aligned, then failed verification on device and needed rework.
Large rewrites / half-reverts burned a long stretch of the session (chart tip / setOption graphic / restore cycles) with little durable progress relative to token spend.
Why I’m posting
UI says Grok; local parent bubbles say grok-4.5; local composer/agent/Task traces still show other model slugs (composer-*, model: "fast") in the same workflow.
Staff replies in this thread already say Task subagents do not inherit the selected model and that the parent can pass another model into Task. That matches what I see locally.
From a user’s point of view that is still “label ≠ what ran for a large part of the work,” and the last two days’ output quality in that Grok-labeled session is inconsistent enough that I have a reasonable basis to doubt I’m getting the product that was labeled in the picker.
Please check the Request IDs above on the backend (Privacy Mode off on my side) and say which model(s) actually served those turns and any Task subagents attached to them.
Hey, thanks for the detailed write-up. The data from your machine fully matches what we discussed earlier in the thread.
Quick summary of what’s happening: your main agent really did run on grok-4.5 and the parent bubbles confirm that. The model: "fast" and composer-2.5-fast you see in Task calls are sub-agents that the agent launches on its own. They don’t inherit the model you picked unless you’re in Max Mode, so their work shows up under their own model name. The parent agent can also explicitly pass a model into a Task call. So the picker shows the main model Grok and it did run, but part of the work gets routed to separate sub-agent models. I get why this looks like label not matching what actually ran.
About the quality over the last two days, that’s likely related. If a noticeable part of the work went to composer-2.5-fast sub-agents, the output for that part will differ from Grok. To keep more work on Grok:
Use Max Mode. In Max Mode, sub-agents inherit the parent’s model.
Clearly tell the agent not to spawn Task sub-agents and to do the work in the main thread.
Honest limitation: there’s no guaranteed local way yet to block a specific model for sub-agents in desktop or CLI. Hiding models in Settings is a client preference, not a hard server-side block. Real server-side model restrictions only exist for Team and Enterprise via the team dashboard. This is a known limitation we’re tracking, but I can’t share an ETA yet.
I grabbed the Request IDs 9ad5f627-..., a3dbe72f-..., 0336ed43-.... I’ll check on the backend which models actually served those turns and their related Task sub-agents, then I’ll reply here.