Sudden change in token/cache usage after subscription renewal

Support Help
1

Hi,

I noticed a significant change in my Cursor usage immediately after my subscription renewed, and I’m trying to understand whether this is expected behavior or a change in how caching/token usage is being handled.

Looking at my usage data:

  • Before September 28: Input (w/ Cache Write) was consistently 0.
  • Starting September 28: Input (w/ Cache Write) suddenly started appearing with significant values.
  • At the same time, Input (w/o Cache Write) became very small and almost constant, often around 4 tokens.
  • Cache Read also became extremely large in many requests, sometimes reaching several million tokens.
  • As a consequence, the Total Tokens per request increased considerably compared with the previous period.

For example, before the change, requests looked roughly like:

Input (w/ Cache Write): 0
Input (w/o Cache Write): tens/hundreds/thousands
Cache Read: hundreds of thousands or millions

After the change, I see patterns such as:

Input (w/ Cache Write): 100k–400k+
Input (w/o Cache Write): ~4–100
Cache Read: several million
Total Tokens: several million

The timing is particularly interesting because this happened right around September 28, when my subscription renewed.

Could someone from the Cursor team clarify:

  1. Was there a change around September 28 in how context caching / cache writes are handled?
  2. Is this related to the subscription renewal or to a change in the usage/billing system?
  3. Does Input (w/ Cache Write) now count differently toward usage compared with before?
  4. Could this explain why my token consumption increased considerably even though my usage pattern/workflow did not change significantly?
  5. Is the large amount of Cache Read expected, and how does it affect the usage percentage?

I’m attaching my usage CSV so the change can be seen directly in the data.

I’d especially like to understand whether this is simply a reporting/measurement change, or whether Cursor is actually sending significantly more billable input tokens after the renewal.

Thanks!

usage-events-2026-10-01.csv (105,3 KB)

4

Check this out - Bug/Help: Other Models % hits 100% while usage-export at published API rates only reconstructs ~65% — how to reconcile the meter?

6

Hey, thanks for the detailed report and the CSV. It makes things really clear.

This isn’t related to renewal. Around Sep 28, the model that handles your Auto requests changed, and the new one reports prompt caching differently. New context now shows up as Input (w/ Cache Write) instead of plain Input. So one column jumped from 0 to large values, and the other dropped to just a few tokens. That’s a reporting change in how cache is counted, not that you’re suddenly sending more billable input.

A couple important notes:

  • For Auto, cache-write tokens are billed at the same rate as normal input, so this reporting shift by itself doesn’t make requests more expensive.
  • Cache Read was already high before. It’s the conversation being re-read on each agent step, and it’s priced at a noticeably lower rate than input. Total Tokens includes cache reads, so it looks much bigger than what actually drives usage. More details here: Why does Cursor consume an absurd amount of cache read tokens?

Where usage really did grow is Sep 28. That day had about 4x more agent steps than your usual day, which explains the spike. Starting Sep 29, daily usage went back to the same range as before.

If you want more predictable usage, you can pick a specific model instead of Auto with /model in the CLI. Also, starting a new chat per task helps keep context and cache reads smaller.

Let me know if anything in the data still looks off.