Hi there,
I have been using Cursor for years now. Until recently, I’ve noticed my token usage is insane with little to no change in my workflow. I’m asking for relatively small changes but it seems that my cache reads are hyper inflating my token usage thus increasing my cost. Is this something on my end that I need to change or is something wrong?
Thanks
Hi @steeb Thanks for the post. I understand why a 12M token line is alarming at first glance. That number isn’t a single call. The Total on a usage row is the sum of every LLM call the agent made while working on that one message: reading files, running tools, applying edits, and thinking in between. In your screenshot roughly 95% of it (11.37M) is Cache Read, which is context the provider had already processed and is re-reading rather than processing fresh. Cache reads are billed at a small fraction of the input rate, so a large cache read number means caching is doing its job, not that you’re paying full price for repeated work. Without it, that same session would have cost considerably more.
This isn’t something you’ve misconfigured. What tends to move the number over time is session length and model choice. A single message now often triggers ten or more calls autonomously, so longer chats and the newer premium thinking models push per-request totals up even when the change you asked for is small.
Colin’s explanation here covers the mechanics in more depth: Why does Cursor consume an absurd amount of cache read tokens? - #24 by Colin
Three things that help in practice:
Start a fresh chat for each new task. Every follow-up in a long thread carries the whole prior conversation forward.
Check the Cursor Context Usage Display by clicking on the circle icon in the bottom right (the circle indicator). This can help expose unexpected items in your context and help you reduce token usage.
Check which model you’re on. The newest thinking models are priced higher per token than the ones you may have been using earlier this year.
If a particular request still looks off after that, I’m glad to take a closer look. Send over a few Request IDs from the sessions that surprised you and I’ll check what those calls actually did. One caveat: with Privacy Mode on, we don’t retain request data, so the IDs need to come from requests made after you switch it off, so I can see details about the request.
To disable Privacy Mode:
Cmd+Shift+J on macOS or Ctrl+Shift+J on Windows/Linux.General.Privacy Mode off / switch to Share Data.To get the Request ID:
... menu.Copy Request ID.Cache reads inflating while your prompts stay small is usually a context-size problem, not a pricing change. Every turn in agent mode resends the whole conversation plus your rules, plus the JSON schema for every tool from every enabled MCP server, plus whatever files got pulled in - and all of that gets billed as cache-read tokens on each request. So the size of one request is roughly “everything the model has seen in this thread so far”, which is why a 10-line change late in a long chat can cost far more than the same change in a fresh chat.
This is a client-side config/context issue rather than a provider accounting bug, which is the good news: it’s fixable on your end. Concretely, check three things. First, how many MCP servers you have enabled - tool definitions are sent on every single request, and a couple of chatty servers (browser tools, big API wrappers) can add tens of thousands of tokens per turn before you type anything. Disable the ones you aren’t using in that project. Second, your rules: anything set to “always apply” is prepended to every request, and .cursorrules / AGENTS.md files that have grown over time add up. Third, thread length - start a new chat per task instead of continuing one long thread, and avoid @-ing whole directories.
If you want to confirm it rather than guess, note your cost-per-request at the start of a fresh chat with MCP disabled, then re-enable servers one at a time. The jump will point straight at the culprit. One caveat: if the inflation started on a specific date with no change on your side, that’s worth reporting to Cursor separately, since model/pricing changes on their end do occasionally shift how cache tokens are counted