Understanding Write Cache

Support Help
1

Describe the Bug

We’re trying to better understand Cursor’s caching behavior for context window data that gets sent back to the server. Specifically, we’d like to know how the cache works, how long the cache remains active, and whether the behavior changes depending on the environment, such as local, cloud, or self-hosted deployments.

Our current understanding is that when previously cached context is resent, the cost is significantly lower than a full resend. What we’re unclear on is the length of that cache window and how best to work within it so we don’t leave a conversation open long enough to trigger a more expensive re-seeding of the cache.

Any detail you can share about cache duration, refresh behavior, and whether those timings vary by environment would be greatly appreciated.

Steps to Reproduce

Not a bug.

Expected Behavior

Not a bug.

Operating System

MacOS

Version Information

Not a cursor problem

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Brandyn_Brosemer!

When you send a request, we build the prompt in a cache-friendly way and hand it to the underlying model provider (Anthropic, OpenAI, etc.), and the provider’s own cache is what decides whether you get a cache hit or a full re-seed. So the cache duration and refresh behavior are ultimately defined by the model provider, not by Cursor, and they don’t change based on whether you’re running locally, in a Cloud Agent, or self-hosted.

Anthropic is the only provider that has an explicit “cache write” — the first request that establishes a cached prefix costs more than a normal input token, and subsequent requests that hit that prefix are billed at the much cheaper “cache read” rate.

Cursor uses Anthropic’s default cache window of ~5 minutes, which is a sliding window: every cache hit extends it, so an actively used conversation stays warm indefinitely. If a conversation with a Claude model sits idle for more than ~5 minutes, the next turn will be a full re-seed (and a new cache write)!

One gotcha: provider caches require an exact token-prefix match, so things like switching models mid-thread, editing an earlier message, or toggling tools/rules will re-seed the cache even well inside the 5-minute window. The biggest wins for cache hits usually come from keeping the early part of the conversation stable, not from watching the clock.

8

The biggest wins for cache hits usually come from keeping the early part of the conversation stable, not from watching the clock.

Respectfully I have to strongly disagree here.

It’s self evident that 5 minutes is not enough time for a developer to review large code output from AI and follow up.

This results in a 10x uncached read cost on the next prompt. This added cost is a deal breaker for me using Cursor and forces me to use Claude Code.

The only thing that would need to change is to allow pass through of this env variable to the Anthropic API call for users who want it:

ENABLE_PROMPT_CACHING_1H=1

And more generally, does Cursor have plans to expand a whitelist of safe configuration options to API providers?

9

12.5x cause cashe write is 12.5x expensive than cashe read

Are you sure that this won’t make the service even more expensive?
Storing cache also costs money.

10

Yeah I should acknowledge that a 1hr cache costs more money ($10/mtok) than the 5min cache ($6.25/mtok) per Anthropic’s docs (link below).

However there are a lot of people who feel strongly (link below) that 1hr is the better option. In principle it seems to me that cost optimization should be up to the user.

11

Sounds interesting. It would be great to add a 5m/1h switch to the model setting selector.

12

OMG, just imagine how much the Claude Mythos 4.7 Max MAX 1h Fast will cost :joy: