Hey, thanks for the report. This is a known issue we’re tracking. On cursor.com/agents for Composer 2.5 and Grok models, the Fast option is currently the default, and selecting fast-off in the web picker doesn’t always stick, especially when you start a new chat and after the first reply.
To be honest, there isn’t a full workaround on web yet. The only thing that really helps right now is to pick the model in the web picker, go to Edit, and uncheck Fast. Then before every send, including follow-ups, take a quick look at the model in Composer and switch it back if it jumps to Fast again. This is exactly what we’re working on, so it’s not 100% guaranteed.
If you also use the Cursor desktop app, there are more reliable controls there. You can pin a default model and disable models you don’t want so the agent can’t pick them. But that doesn’t carry over to a web-only flow.
If you see Fast charges on the usage page that you didn’t expect, email [email protected] and the team can check your account.
Hey @luis_enrique_vargas quick update on this. The issue where Fast would turn itself back on at cursor.com/agents after you turned it off has been fixed on our side, and the change is rolling out now, so it might already be live.
You don’t need to do anything on your end since this is in the web UI. Next time you start an agent, turn Fast off like usual, then check the model in the picker after the first reply. If Fast still switches back on by itself, especially in brand new chats, reply here and we’ll take another look.
Hey, thanks for double-checking. The fix for this Fast turning back on after the first response on cursor.com/agents was merged just a couple hours ago, so it’s very possible the update hasn’t reached you yet.
First, do a full reload of the cursor.com/agents page with cache cleared Ctrl+Shift+R or Cmd+Shift+R, then rerun the test: new chat → turn off Fast → send a prompt → check the model in the picker after the first response.
If Fast still turns itself back on after that, send the Request ID or the agent link or agent ID where you reproduced it so we can take a closer look. Also let us know if it only happens in brand new chats or specifically after the first response, that’ll help narrow down what’s still left.
About the Fast charges on the usage page that you didn’t select, it’s best to email the team at [email protected] so they can check your specific account.
@deanrie Thank you for supporting,
Just checked again now, issue still happens to me. Please check this agent id: bc-3e225a89-9227-497a-af6b-d1ec4ae8ec9d
I checked this agent on our side. All of its requests were going to the regular Composer 2.5, not the Fast variant. Nothing was charged on the Fast plan for it, and I don’t see any new Fast charges on the account after the morning tests.
So what you’re seeing right now looks like a leftover display in the model picker, not an actual Fast run. Most likely, the browser kept an old model setting from before the update. Try this:
Do a full reload of cursor.com/agents with cache cleared using Ctrl+Shift+R or Cmd+Shift+R.
Open the model picker, hover Composer 2.5 (or the model you want), and click Edit.
Make sure Fast is unchecked, then save.
Start a new agent, send a prompt, and after the first response check the model in the picker.
If the picker still flips to Fast after that, send a screenshot of the picker and we’ll dig deeper. But based on what I checked, your agents are running on the selected non-Fast model.
About Fast charges on the usage page that you didn’t select, email [email protected] and the team can look into your specific account.
I checked the agent you shared bc-d52b2d0d, and it’s actually running on Grok 4.6 Medium, so your default is being applied to new agents.
One thing to note: agents created before the default model was saved fall back to the standard default, and that’s currently the Fast variant. That explains why some of the older agents you saw were on Fast.
Can you check this and let me know how it goes?
Open cursor.com, go to Cloud Agent settings, scroll to Default Model.
Make sure it’s set to Grok 4.6 Medium. If not, set it again, make sure Fast is not selected, then save.
Reload the page and confirm it still shows Grok 4.6 Medium.
Trigger the webhook so a new agent gets created.
Open the new agent at cursor.com/agents and check the model shown in the message field.
If the new agent is still on the Fast variant after step 5, reply with the link to it and we’ll dig in.
If you see Fast charges on the usage page that you didn’t select, it’s best to email [email protected] so they can check your account.
Hey, thanks for the agent ID and screenshots, that’s exactly what we needed.
You’re right, this is just a display issue. I checked this agent on our side: all requests for it, including the follow-up message, went to the regular Composer 2.5, not Fast. On your usage page you can also see the correct model, and it was billed at the standard Composer 2.5 rate, not Fast.
The picker switching to Composer 2.5 Fast after the first response is a leftover from a previous issue. The update we shipped fixed what actually gets sent in the request, but the label in the picker can still show the wrong value. This is a known issue we’re tracking, so you don’t need to redo anything or change anything on your side.
Until this is fixed, use the model shown on the usage page as the source of truth. If you ever see Fast billing there that you didn’t select, send the agent link and we’ll take a look right away.
i’m experiencing the same problem, but with agents initiated by grok bot - i tried changing the default model method, but no matter what I do, grok bot-initiated cloud agents always run with Fast mode enabled.
Hey, thanks for the report. The agents launched by Grok Bot follow a slightly different model selection path than what was discussed earlier in this thread (that was about the web-picker at cursor.com/agents), so let’s check your case separately.
To understand what’s happening, please share:
A link or ID for one of these Grok Bot agents where you saw Fast (format bc-...).
What default model you set, and where exactly you changed that setting.
Please check the Usage page and confirm which model is actually recorded for those requests. Does it show the Fast variant or the normal one? This is the key point. In some cases the picker shows Fast as a label, but the request actually goes to the non-Fast model and you’re billed at the normal rate.
With that info I can look at the specific agents and confirm whether they’re really running on Fast or if it’s just UI. If the Usage page shows Fast charges that you didn’t choose, please also email [email protected] and the team can review it on your account.
yesterday, i noticed the grok bot’s cursor agents all consume a bit too much credit. then i realized i never asked it to configure any particular model, so it just went with defaults.
today, i asked it to run agent with composer 2.5 non-fast.
the agents kept running with the default grok 4.6 high fast - I noticed by credit running out too fast again.
then I changed the default model in cursor to composer 2.5 non-fast, but the runs were still run in fast mode.
for final test, i asked grok bot to set model to grok 4.6 medium non-fast, and the agent run with grok 4.6 medium, but in fast mode.
also, when I started these tests, the default was set to grok bot 4.6 high fast, but grok bot couldn’t override it with composer 2.5, no matter what. then I started to play with the default setting, and now, if I set default to grok 4.6 high fast again, the grok bot’s agents correctly run with composer 2.5 (though the Fast is still set, even if it wasn’t supposed to) - i can’t reproduce the initial state, when grok 4.6 high fast default could not be overridden by grok bot’s trigger.
Hey @jurajt, thanks for the agent IDs. That let us check each run separately.
None of the three agents actually ran on Fast:
bc-69b538c1 and bc-e1b2a2bc both ran on standard Composer 2,5. Each one cost just a few cents. The Fast label you see in the picker for these agents is a known UI display bug we’re tracking. The label is wrong, but what actually runs and gets billed is the non-Fast model you selected.
bc-60dfe4c0 is a separate case. Grok Bot did request Grok 4,6 Medium with Fast turned off, but on Sep 3 in the second half of the day UTC, Grok models were temporarily unavailable. During that window, requests to Grok were rerouted to Auto. This agent ran on Auto and was billed as Auto, so not Grok and not Fast. The agent chat may show a note that the model was unavailable and a reroute happened.
Earlier agents that did run on Grok 4,6 High Fast were from before you changed your default. At that time, Fast was enabled in the saved default. After you switched the default to Composer 2,5 with Fast turned off, all Grok Bot runs have been using a non-Fast model.
On credit usage, cloud agents themselves are cheap, just cents per run. Most usage on the account comes from Grok Bot’s own turns, not from the cloud agents it launches. If you want us to review that part for your account, email [email protected] and the team can look with you.
Until the picker label is fixed, use the model shown on the Usage page as the source of truth. If you ever see a Fast charge there for a cloud agent you set to non-Fast, send the agent ID and we’ll check right away.
the runs i posted Ids of were just dummy runs to test how to grok bot-initiated cursor cloud agents’ model selection works - i don’t care about how much those cost
the unexpected credit consumption I was referring to was related to previous runs, where some actual work was done. and they surely didn’t cost a few cents each - the 100$ promotional credit went down much faster than that.
not sure what you mean by “use the model shown on the Usage page as the source of truth” - the Usage page shows just “grok-bot-default” or “grok-bot-automation”. in very few cases, there’s “composer-2.5”, with the cloud icon, which, upon mouse-hover, says “cloud agent” - does this mean the other runs are NOT cloud agents? that can’t be true, as i run ONLY cloud agents with cursor.
also, “Type” column says “Included”, or “Free” which doesn’t make much sense either.
as you surely can see, there’s plenty of reasons for me NOT to take Usage page as source of truth for anything
as for “Most usage on the account comes from Grok Bot’s own turns” - the Spending page is clear about that, and I naver complained about grok bot usage. my understanding is, grok bot usage is decoupled from cursor cloud agents runs - the various gauges in Spending page tell exactly how much was spent on what.
Thanks for clarifying, and you’re right. My wording about the Usage page being the source of truth was off, and the labels there are genuinely confusing. Let me break it down.
Grok Bot and the cloud agents it launches are two different things in billing:
grok-bot-default / grok-bot-automation are Grok Bot’s own turns, meaning the model the bot runs on when you chat with it and it orchestrates the task. This is not cloud agents.
Rows like composer-2.5 with the cloud agent icon, the one that says “cloud agent” on hover, are the actual cloud agent runs that the bot triggered as a tool.
So your read is correct. Most rows grok-bot-default are the bot’s own turns, not cloud agents. Cloud agents are only the rows with the cloud agent icon, and they really are cheap, cents per run. That matches what you wrote. Grok Bot usage is decoupled from cloud agent runs, and the Spending page separates them into different gauges.
That also answers why the $100 promo credit burned quickly. If it was draining faster than cents per run, the source is almost certainly Grok Bot turns grok-bot-default / grok-bot-automation, not cloud agents. So it’s not that the agents it launched are suddenly expensive, it’s that most of the cost is on the bot side.
About the Type column, Included / Free shows how that line item is counted against your plan, covered by included allowance or promo credit, rather than billed as separate on-demand spend. It doesn’t indicate which model ran.
For the exact line items and where the promo credit went on your account, it’s best to email [email protected]. They can see the detailed breakdown for your account and walk through the specific records. If after that it still looks like a cloud agent ran on Fast even though you picked non-Fast, send the agent ID and I’ll check right away.
both consume grok bot usage? i mean, if the Credits are consumed first (which is true, as far as I remember), why would grok bot’s weekly usage be consumed as well?
Here is no way to “edit” an agent on the phone webapp. I’m on android and unless I start the thread from my computer as remote control or from the computers webapp it’s stuck on fast no matter what.
@jurajt about the two gauges. They’re two separate counters, not one layered on top of the other. Grok Bot weekly usage is the included weekly pool for Grok Bot, it resets weekly (yours is 9 Sept). Credits (13/100) is a separate promo credit balance with its own expiry (18 Oct 2026). So Grok Bot activity can show up in both gauges because they track different things, not because charges always happen in a strict order.
For how it was split between the included pool and credits on your account, that’s down to detailed line items. The team at [email protected] can see the full breakdown. I won’t guess from the public numbers and risk misleading you.
