Bug Report: Abnormal Cache Token Counting / Billing Display Issue in Cursor Usage Dashboard

[w_w1 (w w)]

Bug Report: Abnormal Cache Token Counting / Billing Display Issue in Cursor Usage Dashboard

Summary
There appears to be a billing/usage tracking bug related to cache tokens (especially cache reads) when using the kimi-k3-max model. Cache read tokens are extremely inflated, and the Tokens column aggregates them into very large totals (shown in Chinese units such as “万” and “亿”), while actual input/output tokens remain relatively small. All entries are marked as “Included”.

Details / Reproduction

1. Open the Cursor usage/billing page.
2. Observe entries for model kimi-k3-max (and occasionally grok-4.7-xhigh-fast).
3. Hover over the Tokens value to see the breakdown tooltip.

Example from the UI (Sep 30 entries):

• Tokens displayed as 2.4亿 (≈ 240 million)
• Tooltip breakdown:
  • 缓存读取 (Cache Read): 239,628,756
  • 缓存写入 (Cache Write): 0
  • 输入 (Input): 202,010
  • 输出 (Output): 93,778
  • 全部的 (Total): 239,924,544

Similar patterns appear across multiple rows (e.g. 1.5亿, 2.4亿, 5205.5万, etc.), where cache-read tokens dominate the total while input + output stay in the tens/hundreds of thousands.

CSV Export Data (sample rows)
The exported data shows the same anomaly. Columns roughly correspond to:
Date | Type | Model | … | Cache Write? | Cache Read | Input | Output | Total | Cost

Examples:

• 2026-09-30T18:46:47.969Z … Cache Read ≈ 239,628,756 | Input 202,010 | Output 93,778 | Total ≈ 239,924,544
• Other rows show Cache Read in the tens of millions while Input/Output remain comparatively small.
• One column is consistently 0 (likely Cache Write).

Expected Behavior

• Cache read/write tokens should be accurate and not massively inflated.
• The Tokens column and tooltip totals should correctly reflect actual prompt + completion + legitimate cache usage.
• Billing/usage accounting should not treat abnormal cache-read volumes as normal included usage.

Actual Behavior
Cache-read counts are orders of magnitude higher than input/output tokens, producing unrealistically large totals that are still marked “Included”. This looks like either a cache-accounting bug or a display/aggregation error on the usage dashboard.

Additional Notes

• All listed usage is marked Type = “Included” and Cost = “Included”.
• Model names appear truncated in the CSV (kimi-k3-ma, grok-4.7-xh).
• Timestamps are in UTC.

Please investigate the cache token tracking logic for kimi-k3-max (and related models) and the aggregation shown in both the UI tooltip and CSV export.

Thank you!

[mohitjain (Mohit)]

Hey @w_w1,
These numbers are real usage, not a counting error. Each row is one message you sent, and it adds up every model call the agent made while working on it. Every call re-reads the conversation from cache, so a long agent run on a large conversation can reach hundreds of millions of cache-read tokens while input and output stay small. Cache Write shows 0 because Kimi K3 has no separate cache-write fee.

To keep this down:

1. Start a new chat for each new task.
2. If MAX Mode is on in the model picker, turn it off so the conversation stays smaller.
3. Hit Stop if the agent keeps repeating similar commands or searches.

More on how cache reads work: Why does Cursor consume an absurd amount of cache read tokens?