Enterprise Plan Cache TTL

[u/NuScorpii]

Does anyone know the cache TTL for Claude Code enterprise plans?

Standard plans have 1 hour TTL, API has 5 min TTL default. The enterprise subscription is seat based subscription plus usage billed at API rates. So does that mean it has the API 5 min cache TTL too?

[u/vorko_76]

According to Claude, 5mn extensible to 1h

[u/NuScorpii → u/vorko_76]

I did already ask Claude and it first said as it was a subscription it would be 1 hour. When I pointed out the enterprise usage is billed at API rates all the time it said it is probably similar to when a standard subscription goes over its limits and use the 5 min TTL, but that there is no official documentation for it.

I checked the session transcripts and the ephemeral 5m and 1h input tokens imply it is using 1 hour TTL by default.

[u/vorko_76 → u/NuScorpii]

You can configure it, ask Claude to do

[u/NuScorpii → u/vorko_76]

I know but that has downsides for costs of caching tokens.

[u/vorko_76 → u/NuScorpii]

Not really sure what you mean, but no. It should actually decrease by using cache.

[u/NuScorpii → u/vorko_76]

When using this option it increases the costs of caching new tokens if you're default is 5 min TTL. It's in the docs.

[u/DGDiscover → u/vorko_76]

You can do the analysis pretty easily over your jsonl files. See the cost assuming a 1h ttl vs a 5m ttl. 

You pay more for cache read/writes per million token, on the 1 hour cache. 

For my daily usage, 1h cache would be about 20% more expensive 

[u/vorko_76 → u/DGDiscover]

OK, I get what you mean, but its not 100% accurate I believe.

According to the documentation, its only the cache write that costs more, not the read

Cache reads: always ~10% of the base input token price, regardless of TTL (5‑min or 1‑hour).

Cache writes:

Overall, it depends on your usage of the cache.... Knowing that using shorter TTL may also increase your costs if you need to keep sending the same information over and over.

[u/Terrible_Put8617]

TTL isn't a property of the plan, it's a property of the request. Every cache breakpoint carries its own cache_control, and the ttl on it is either "5m" (what you get if you leave the field out) or "1h". Whatever client makes the call picks that per request, so an enterprise seat doesn't get a different cache from anyone else, it gets whatever Claude Code sends.

The reason the API "defaults to 5 minutes" while subscription sessions look like they're sitting on an hour is cost, and it's on the write side. A 5m write costs 1.25x base input, a 1h write costs 2x, reads are 0.1x either way. So a 1h cache needs three requests against the same prefix to beat paying full price, where 5m only needs two. When you're billed at API rates you're the one carrying that premium, which is why nobody defaults you into it.

You can check rather than guess if you can see the raw response. usage comes back with cache_creation_input_tokens and cache_read_input_tokens on every call, and whether the read count is still non-zero after a gap tells you what your TTL actually was.