Hello,
I had grok 4.6 spawn composer-2.5 subagents, they are shown as that model in both the model selector and the subagent model preview, yet in the usage tab, I am being charged for composer-2.5-fast as shown in the paste from below,
Sep 7, 04:23 PM
Included
composer-2.5-fast
2.2M
Included
This behavior seems exclusively to occur with subagents.
Have on agent orchestrate composer-2.5 subagents, and have model selector with fast mode disabled for both models.
Go to https://cursor.com/dashboard/usage
View model usage by type.
Expected Behavior
Should run and only be charged with base model pricing, not fast.
Hey, thanks for the detailed report. The screenshots and the version helped a lot.
We checked the run you described, and you’re right. The main agent requests standard Composer 2.5, but the subagents it spawns actually run as Composer 2.5 Fast, so Usage shows composer-2.5-fast. This is a known issue we’re tracking, and I’ve added your case to it.
It looks like when a subagent is spawned, it doesn’t inherit the Fast setting from the main agent and instead falls back to a saved preference for Composer 2.5. On a fresh account there’s no saved preference yet, and the default for Composer 2.5 is Fast on. That’s why Fast gets billed.
There’s a workaround that should also confirm this:
Open a new chat.
In the model picker at the bottom, select Composer 2.5 as the chat model.
In the same picker, turn Fast off for Composer 2.5.
Switch the chat model back to Grok 4.6 Fast off.
Ask Grok 4.6 to spawn a Composer 2.5 subagent like before.
Can you please tell me whether the new subagent rows show composer-2.5 instead of composer-2.5-fast? Either way is useful, and I’ll pass it to the team.
On billing, all this usage was within your plan’s included allowance, so nothing extra was charged. Fast does burn through the limit quicker though, so the workaround above should help.
As shown in the first screenshot from my original post, I actually already had Fast mode disabled for Composer 2.5 in the model selector. However, following your logic, I went ahead and manually toggled it on and then back off again.
It seems that doing this manual toggle successfully updated the saved preference, the issue is fixed, and the dashboard is now correctly showing composer-2.5 for the new subagents.
Odd, refuting my last reply, the spending has suddenly switched back to fast, no changes on my end, odd behavior. For reference, the same agent has been orchestrating composer both when it says fast mode and not, whereas the IDE shows it is not in fast mode.
EDIT: Request ID e9356afe-c121-4649-a9c3-fbb1a70b41de
Thanks for the follow-up and for the Request ID, that’s exactly what we needed.
You’re right in both cases. Your Fast toggle did work. The Composer 2.5 worker that Grok started right after that (around 22:38 UTC on Sep 7) ran as normal Composer 2.5 for about three hours. It was the same worker that got switched. At 01:35 UTC on Sep 8 it woke up because a background command it had started earlier finished, and that wake-up turn was billed as Composer 2.5 Fast. From that point on, all later turns from the same worker, including ones Grok started, stayed on Fast even though Grok requested normal Composer 2.5 each time. So on the Usage page it switched back to Fast without any changes on your side.
This is part of the same issue we’re tracking. I added your Request ID and this detail to it.
For now, the most reliable workaround is to not keep one Composer 2.5 worker alive for hours. A freshly started worker begins as normal Composer 2.5 (your preference is saved now), and the switch to Fast only happens after the worker is woken up by a finished background command. If you have Grok start a new worker for each chunk of work instead of reusing the same one, the Usage lines should stay on composer-2.5.
Can you try that and let me know if new lines stay on composer-2.5? Any reply helps us confirm.
