╭────────────────────────────────────────────────────────────╮
│ │
│ About Cursor CLI │
│ │
│ CLI Version 2026.07.01-41b2de7 │
│ Model Composer 2.5 │
│ OS darwin (arm64) │
│ Terminal tmux │
│ Shell zsh │
│ Last Request ID x │
│ User Email x │
│ │
╰────────────────────────────────────────────────────────────╯
Hey, thanks for the detailed report. These are two different known bugs, so I’ll reply to each one.
Empty list in /model
This is a known intermittent issue at session start. The in-session picker fetches the model catalog on startup with a short timeout, and on a slow network, VPN, SSH, or a cold start the fetch might not finish in time, so the list renders empty. This is not an issue with enabling models in the dashboard, and it’s not an access problem.
Workarounds:
Restart the session. Often the list loads on the next start.
Start with a model right away: agent --model <name>, or set CURSOR_DEFAULT_MODEL.
agent --list-models or agent models shows the full list of enabled models even when the in-session picker is empty.
I can’t share a fix timeline yet, but the bug is known and tracked.
agent --model composer-2.5 is treated as 2.5 fast
This is also a known bug. When launched from the CLI, --model composer-2.5 currently routes and is counted as composer-2.5-fast. There isn’t a reliable CLI workaround right now. The issue is tracked, but I can’t give an ETA.
If you have questions about billing or usage because of this, email [email protected] and they can check your specific account.
I’ll post an update in the thread when we have fixes.
Shouldn’t be a network issue, but when I start the CLI it is frozen for a few seconds, so maybe that’s where the sync error happens.
Regarding usage, clearly the fast version will eat up more, I wonder if they have multipliers for each model? How is the cost calculated compared to the total possible usage?
Thanks, that’s a helpful observation. A 1 to 2 second freeze on startup fits what we’re seeing. At that moment the CLI tries to fetch the model catalog with a short timeout, and if it doesn’t finish in time, the in session picker shows up empty. So it’s more about request timing than the network itself.
On pricing, usage is token based right now. Each model uses your included limit at its own rate, tied to that model’s real token costs for input and output, not a fixed x2 or x3 multiplier. That’s why there isn’t a single multiplier table. Different models burn the limit at different speeds, and the fast variant burns it faster than the regular one. You can see the breakdown by model and spend in the usage dashboard.
If you want to confirm how much composer-2.5-fast used because of that bug, and whether it’s worth a review for your account, email [email protected] and they’ll check the details in your usage. I’ll post an update in this thread once fixes for both bugs are in.
