Bug in usage report

Describe the Bug

Looking at my usage report, I see that there is some apparent problems with the fields, and the relevant math. I’m pasting my current usage report here (from my dashboard).

Current billing period: Jul 12, 2025 - Aug 12, 2025
Pro comes with at least $20 of included usage per month. We work closely with the model providers to make this monthly allotment as high as possible. You’ll be notified in-app when you’re nearing your monthly limit.
MODEL INPUT (W/ CACHE WRITE) INPUT (W/O CACHE WRITE) CACHE READ OUTPUT TOTAL TOKENS API COST COST TO YOU
auto
232,357 23,910,240 72,392,852 494,183 97,029,632 $81.17 $0
claude-4-sonnet
4,508 41 57,922 1,631 64,102 $0.01 $0
Total 23,910,281 495,814 236,865 72,450,774 97,093,734 $81.18 $0

Notice the following:
input w/ cache write:
auto 232,357
claude-4-sonnet 4,508
Total 23,910,281. (I think the total should be closer to 236,865).

input w/o cache write:
auto: 23,910,240
Claude-4-sonnet 41
Total: 495,814

other fields that show issues are the cache read column (72mil, 57k, total 236k), output (494k, 1k, 72.4 mil)

I think that at least some of those columns really don’t make any sense. How can cache read for sonnet be almost 15 times what the input was?

I cannot in good faith trust any of these numbers. It seems like a simple fix to actually have the correct numbers in the correct places in the columns - customers are paying good money for this product, and need to be able to trust the billing and usage information.

Steps to Reproduce

Go to Cursor - The AI Code Editor

Expected Behavior

Included usage summary needs to actually have the correct value in each field.

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.2.4 (Universal)
VSCode Version: 1.99.3
Commit: a8e95743c5268be73767c46944a71f4465d05c90
Date: 2025-07-10T16:55:16.443Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for flagging this.

The way that LLMs work (in all apps, not just Cursor!) is that every time a tool call occurs, the whole conversation prior to that tool call is re-evaluated by the LLM. As the conversation has already been seen by that model, these tokens count as ‘Cache Read’ tokens, which are the cheapest type of token.

This does mean that, in long threads with lots of tool calls, the cache read tokens can be higher than expected! This would be the case in any AI application that follows this pattern and is unfortunately just how LLMs handle tool calls right now.

We’re hoping to bring some better in-app features for seeing your token usage and managing it soon, to help make the most of your monthly usage!

My issue is less the numbers, than the fact that the numbers don’t add up to the totals of each column. Look at the picture.

The first four columns all have totals that are flat out wrong based on the numbers above them.

Drew