Cursor vs Claude Code: which one burns more tokens

Per unit of work, Claude Code burns more tokens. It is an agent that reads files, greps, runs commands, reads the output, and keeps the whole trail in context, so a single request from you turns into a dozen model calls with a conversation that grows the entire time. Cursor, used the way most people use it, sends smaller and more targeted context: the file you are in, some retrieved chunks, the diff. Fewer tokens per exchange, more exchanges driven by you.

That does not settle the bill, because the two tools charge on different axes. Cursor sells a subscription with an included allowance and then meters beyond it. Claude Code is available both on Anthropic subscription plans with usage limits and on straight pay-as-you-go API billing. If you are on a Claude subscription and never hit the limit, token count is irrelevant to your invoice. If you are on API keys, token count is the invoice. So the honest answer to which one burns more tokens is Claude Code, and the honest answer to which one costs more is: it depends entirely on which billing surface you are standing on and how long your average task runs.

Why the agent burns more

The cost driver in agentic coding is not output. Output tokens are a rounding error next to what goes up the wire. The driver is that every tool call re-sends the conversation. Turn one sends a system prompt, your project instructions, and your question. Turn two sends all of that plus the first tool call and its result. Turn twelve sends everything that came before it. Input grows roughly quadratically across a long run, and long runs are exactly what an autonomous agent is for.

Prompt caching is the reason this is survivable at all. Anthropic and other providers let you mark a stable prefix so repeated reads of it bill at a small fraction of the normal input rate, with a modest surcharge on the write. On a healthy Claude Code session, most of your input tokens are cache reads rather than fresh input. That is also why cache-hit rate matters more than raw token count when you are looking at a bill. Two sessions with identical token totals can differ several times over in cost depending on whether the prefix stayed stable.

The practical consequence: anything that mutates the front of your context invalidates the cache and makes the next turn expensive. Editing your project instructions mid-session does it. Tools that rewrite or compress history to save tokens do it, and they frequently spend more on the cache miss than they saved on the trim. I have watched a context-compaction feature increase the cost of a run.

Where Cursor's spend hides

Cursor's pricing has moved several times, and the current shape is a subscription with an included usage allowance and metered spend past it, with the option to bring your own API key. I am not going to quote a number that may be stale by the time you read this; check their pricing page. What matters structurally is that Cursor puts an abstraction between you and tokens. You see an allowance draining. You do not, by default, see that a particular agent run consumed 400k input tokens because it retrieved half your repository.

And Cursor's agent mode has converged on the same behaviour as Claude Code. Once you are letting it plan, edit across files, run the test suite, and iterate, the token profile looks like an agent's, because it is one. The gap between the two tools is narrower than the tab-completion-era comparison suggests. What still differs is the default: Cursor's centre of gravity is a human in the editor approving small changes, and Claude Code's centre of gravity is walking away for ten minutes.

Cursor genuinely wins on some things. The editor integration is better than anything a terminal can do, inline diff review is faster to scan than a wall of terminal output, and the included allowance makes spend predictable for people who hate variable bills. If predictability is what you are buying, a subscription with a cap is a real product feature and I will not pretend otherwise.

How to actually measure this yourself

Feature comparisons are guesses. Your repository, your prompting style, and your tolerance for long autonomous runs dominate the result. Run the same task through both and look at the numbers.

• Pick one real task with a clear finish line. Not a toy. Something like adding a field end to end through a schema, an API handler, and a test.
• Run it in each tool from a clean checkout, same starting prompt, same model family where possible.
• Record four numbers per run: input tokens, cache read tokens, output tokens, and wall-clock time to a passing test.
• Divide cost by outcome, not by token. A run that costs three times as much and lands the change first try can still be the cheaper one.
• Repeat on a task where the agent is likely to flail. Cost distributions in agentic coding have a long tail, and the tail is where budgets die.
• Check your cache-hit ratio. If cache reads are not the large majority of your input tokens on a long session, something in your setup is invalidating the prefix.

For Claude Code specifically there are good local readers of the session logs that will give you cost per session and per day without any proxy at all. Start there if all you want is a number.

The measurement problem, and what I built

The reason this comparison is hard to settle is that each tool reports its own spend in its own units, and neither reports the other. If you use Claude Code in the morning and Cursor in the afternoon, you have two dashboards, two vocabularies, and no single line that says what today cost.

I built Probe0 because I wanted that line. It is a local proxy on your own machine. You install one certificate once, and every coding agent CLI on the box routes through it: Claude Code, Codex, Cursor. There is no Probe0 server, no per-tool config, and nothing about your prompts leaves the machine except the calls that were going to the provider anyway.

The Recording module keeps a full request ledger: model, tokens, real cost, latency, and which process made each call. That last field is the one that answers this article's question for your own workload, because it lets you attribute spend by tool rather than arguing about it. On top of that sit modules you switch on individually, each of which reports what it actually saved: Local Routing to a model already loaded in Ollama or LM Studio, with weak answers automatically retried on the cloud. Model Tiering that tries the cheap model first. An Exact Cache on local disk that never touches the network. A Semantic Cache over a local vector index with a strict similarity floor, which refuses to match anything carrying tool calls, because a wrong hit inside an agent run corrupts the run. Request Coalescing so simultaneous identical calls collapse into one upstream. Spend Guard with a hard cap per run and per day that warns first and then pauses. Because it sees actual usage, it can also tell you when you are paying for a plan tier above what you use.

The cheapest token is the one you never send twice. The second cheapest is the one a local model answered.

The limits are real and worth stating. Probe0 is macOS only and in private beta. It is a single-developer tool, not a team gateway with multi-user routing and RBAC. Provider coverage is what coding agents actually call, not a catalogue of a hundred APIs. Sign-in is Google or GitHub only, and the account system is new. If you need a hosted gateway your whole engineering org points at, this is the wrong shape and something like a managed LLM gateway is the right one.

What I would actually do

If your work is mostly small, reviewed, in-editor edits, Cursor on a subscription is the lower-variance choice and you will spend less time thinking about billing. If your work is long autonomous runs across many files, Claude Code will burn more tokens and usually finish more of the task per unit of your attention, and a Claude subscription plan converts that token burn into a flat number until you hit the limits. The expensive configuration is Claude Code on raw API keys with a long-running agent, no spend cap, and no visibility. That is the setup that produces the surprise invoice, and it is also the setup that a local proxy fixes for free by capping the run and showing you where the money went.

Measure once with real tasks before you switch tools. Most of the money in agentic coding is lost to context that did not need to be re-sent and to runs that should have been stopped, and both of those are cheaper to fix than a migration.