I used gpt-5.5-medium for a few Cursor coding prompts today and burned almost 10M premium tokens in about 6 included requests. A couple of individual prompts were 2–4M tokens each.
That makes it hard to use as a normal coding model. With 5.3 Codex, I could iterate normally without watching the quota disappear this quickly.
Is gpt-5.5-medium intended only for occasional high-cost use? And is there a recommended way to limit context so a single coding prompt doesn’t consume millions of tokens?
Hey, thanks for the question. High token usage on GPT-5.5 is generally expected, and here’s why.
GPT-5.5 is the heaviest reasoning model OpenAI offers in Cursor. It sticks with the task longer in long multi-step sessions, reads files more aggressively, and makes more tool calls. Because of that, the same amount of work can cost noticeably more tokens than a lighter model like 5.3 Codex. Also, in a long chat the cost compounds. Each new request resends the whole growing context, so by the end of a session individual prompts can easily reach millions of tokens.
How to keep usage under control:
Start a new chat for each separate task. Don’t keep one long thread going, the context only grows.
Narrow the context manually. @-reference the specific files you need instead of letting the agent index and read half the repo.
For simple edits, switch to Auto or a lighter model. GPT-5.5 makes sense for harder tasks where you really need its reasoning power.
So GPT-5.5 isn’t only for rare expensive use, but as a default iteration model it’s expensive by design. For day-to-day iteration many users keep Auto or 5.3 Codex, and turn on 5.5 only when needed.
If you’re seeing 2 to 4M tokens from one short request with a small context, that looks like an anomaly. In that case, please share the Request ID right top corner of the chat > Copy Request ID and we can take a closer look.
I’d treat GPT-5.5-medium as a “hard problem” model, not the default iteration model.
For day-to-day coding, the expensive part is not only the model choice, but letting one long chat keep accumulating repo context. I’d split tasks more aggressively: one thread per change, explicitly attach only the files needed, and reserve the heavier model for review, architecture, or cases where the cheaper model is clearly stuck.
Hey, @Jason_Luo1 summed it up well, that’s exactly the right approach. Use GPT-5.5 for complex tasks, not as the default for iterations. Keep one thread per change, explicitly attach only the files you need, and save the heavy model for review or architecture work, or when a lighter model is clearly stuck.
Additionally I would add that once your hard task for that thread is completed, switch from GPT-5.5 to auto for follow up and verifications in that same thread that you started with GPT-5.5. Auto is able to carry the ball with a thread that has been seeded with high intelligence level on the task and it continues to work out the remaining details.
Eventually when you arrive at another difficult blocker, ask auto to create a single detailed click to copy handoff prompt to seed a new GPT-5.5 thread with the remaining intelligence of the original GPT-5.5 thread.
Keep iterating thread handoffs and rotating GPT5.5 to auto as quickly as possible. Expenses are reduced and the output code quality is still excellent. When sht goes south create a handoff prompt and the new thread will save your bacon again !
Hey @FinDevAI, nice add-on. A handoff prompt between threads is a handy trick. GPT-5.5 does the heavy lifting, then Auto can handle the routine follow-ups and checks in the same thread without blowing up costs. When you hit the next hard blocker, it makes sense to ask Auto to compile a compact handoff prompt and use it to start a new GPT-5.5 thread.
Quick summary for anyone who finds this later. Keep GPT-5.5 for hard tasks, not as the default for iterations, and don’t run one endless thread since the full context gets re-sent and the cost keeps going up.
And back to the original question. If someone is really seeing 2 to 4M tokens from a single short request with a small context, that looks like an anomaly. In that case, share the Request ID (top right of the chat > Copy Request ID) and we can dig in.