What 1.5 trillion tokens a month actually costs A Cursor profile showing 1.5 trillion tokens processed in 30 days would cost roughly $500,000 a month at blended list rates, not the $132 million a year developer Peter Pimentel initially estimated on X, because about 97% of an agent's tokens are cache reads billed at 5 cents on the dollar. Pimentel retracted the viral figure after Theo's 30-minute video rebuttal, and Cursor's Kevin Neilson confirmed on the company forum that Cursor's dashboard and public profiles sum four separately billed categories: uncached input, cache writes, cache reads and output. The correction matters because the token-count gap between engineers running agents at scale and everyone else is far smaller in dollar terms than the original headline implied. What 1.5 trillion tokens a month actually costs I stumbled over a Cursor profile https://cursor.com/@lauren that processed 1.5T tokens in 30 days and I couldn't wrap my head around it. That is literally 55x more than my best month of 27B and I'm running agents 24/7 So I did what any aspiring ai maxi would do: I tweeted about it https://x.com/peterpme/status/2107847615463219252 . After doing some sloppy math I said those tokens cost $132M a year. The post went viral. So viral that Theo made a 30m video https://www.youtube.com/watch?v=FHGfSjDGUIw about how wrong I was and I was https://x.com/theo/status/2107924138094703084 . Watching that video hurt but getting it wrong and misunderstanding hurt more so I went on a mission to figure out how tokens are actually billed across providers. TLDR: at a blended rate, 1.5T tokens costs about $500k a month. I was off by 20x because I wasn't accounting for cache. It turns out around 97% of an agent's tokens only cost five cents on the dollar, and I had priced every one of them at full price I did leave this caveat but the headline is what sells . The gap I was gesturing at got obscured by a bad number so I'm here to admit that I'm wrong and move on to the more interesting bits. There is a class of engineer running agents at scale I can't even begin to comprehend at a cost that runs more per month than a startup's entire payroll. That productivity gap between lab engineers and the rest of us is the question I care about and I think it's a lot more interesting than the $132M number because hopefully our day of token maxing will soon come too. But until then, let's learn about how the labs calculate the cost of your slop. A token count is four different numbers added together Similar to a stateless server, the model has no memory. At every turn the harness includes the entire message history: the system prompt, your request, every file it read & every command it ran. It’s one big array that gets appended to every time you send a message. Caching is the provider agreeing to keep a copy of that data for a few minutes so you don't have to pay full price for them to read the whole thing over again. So when a dashboard says you used a trillion tokens, it's summing four categories that are billed at different rates: | Category | What it is | Price | |---|---|---| | Uncached input | Text the model has never processed before | Full input price | | Cache writes | Text stored in the prompt cache so later turns can reuse it | 1.25x input for a 5-minute cache, 2x for 1 hour Claude | | Cache reads | Text replayed from that cache instead of processed again | 5% of input on Opus and Sonnet 5.5, 10% on most others, 25% on Grok 4.7 in Cursor | | Output | What the model writes back, thinking included | The most expensive | Cache reads are the important one. Cursor's dashboard and public profiles report the sum of all four according to Cursor's Kevin Neilson on their forum https://forum.cursor.com/t/discrepancies-between-cursor-cli-usage-and-billing/164471 . Lauren hasn't said what hers cost and probably can't bc it's an internal number for a company that owns the inference. Everything below is "what this would cost at list price", which is the only version of the question anyone like me can answer. How caching actually bills you Say you're using Opus 5.5 $4/M in, $5/M to cache-write for 5 minutes, $8/M for an hour, $0.20/M to cache-read and your agent is 500k tokens deep. The first request writes the whole 500k to the cache: $2.50 or $4.00 on the 1-hour cache . Every turn after that re-reads it for $0.10, plus a couple of cents to file the new tool result, and each read resets the timer, so a busy session never expires. Then you go to lunch. You're gone for an hour. You're still running agents locally and your computer went to sleep. Oops. The timer runs out and your next turn finds the cache empty and all 500k tokens are rewritten: another $2.50. The expensive event in an agent session isn't the reading. It's the rebuild. Plain input $4/M and a cache write $5/M are the same work for the model: it reads the tokens and builds its state either way. That extra $1 is a storage fee for keeping that state around. In a typical harness like Claude Code or Codex almost everything is cached. For example, my Cursor account has literally 2 uncached tokens out of billions. The one place caching doesn't happen is small requests. OpenAI won't cache a prefix under 1,024 tokens and Anthropic won't cache under 512 to 4,096 depending on the model. So stuff like "translate this sentence" gets processed and discarded every time, by design, because storing it would cost more than it could ever save. Kind of clever. Reasoning is paid once Thinking tokens are billed as output, at the full output price, the moment they happen. There's no discount for the fact that you never see them: on Opus 5.5 a 3,000-token think costs the same 6 cents as 3,000 tokens of visible reply, at $20/M, the most expensive number on the price card. So the higher the reasoning effort, the more you spend per turn. But Anthropic strips earlier turns' thinking out of the context before the next request, so you never re-read your own reasoning. It's a one-time charge, not something that compounds through cache reads. Why cache reads end up being almost all of it Because the whole history goes back every turn. Only the newest tool result and the newest reply are fresh on any given turn; everything else hits the cache. A task that takes 200 turns re-reads its context 200 times, so the token count grows with roughly the square of the session length. The bill mostly doesn't, because the reads are cheap. Every published log I found comes out around 97%. My own logs say about that too depending on the tool. This is the whole mistake in one sentence: I took a number that was 97% cache reads and priced it as if it were 100% fresh input and output. How token costs are calculated The formula is one line, with token counts in millions: reads × p +