I’m trying to understand the exact cache TTL (Time-To-Live) behavior in Cursor.
I know that starting a conversation writes the context to a cache to speed up subsequent prompts and reduce token usage. While standard LLM provider docs (like Anthropic) often list prompt cache persistence at around 5 minutes, my experience in Cursor is different. I often take breaks longer than 5 minutes within a thread, yet the next prompt still feels cached (no heavy delay or full “cache write” cost).
How long does Cursor actually keep the prompt cache alive before it expires? Is there any background keep-alive happening, or does Cursor’s custom setup persist it longer?
We use the standard caching provided by our providers (that means 5 minutes for Anthropic and 24 hours for most OpenAI models, though things are changing for GPT 5.6+). We don’t do anything special to keep the cache warm!
Also, cache hits can occur between chats (the system prompt rarely changes, for example). That might be part of what feels snappier!
You’re right @aebp! We can’t do better than what the model providers allow, so in the case of GPT 5.6 it would be 30 minutes. Updated my previous response.
@Colin thanks for the answer.
I have to ask.
I have an open conversation from about 5 days ago, I went to holiday.
continued today that conversation, and after checking in the billing page the corresponding line for my first prompt made today - I have only cache read, without cache write.
Thanks for clarifying how Cursor handles TTL for Anthropic and OpenAI models!
Could you also share what the cache persistence/TTL behavior looks like for Composer 2.5 and Grok 4.5 in Cursor? Do they follow standard provider defaults, or is there a specific duration we should expect when taking breaks between prompts?
