# Cache lifetime

A cached prefix expires after a limited window, so the first call after a long break re-reads the whole conversation at full price.

> A cache entry lives for a limited time, the TTL. Each reuse extends it; once it expires, the next call rebuilds the whole prefix at full fresh-input price.

Source: https://ai-sw-factory.mellicci.dev/cost/cache-lifetime

**Diagram:** Reuse within the TTL is cheap and extends the window; a call after expiry rebuilds the whole prefix at full price.

- Call — prefix cached
- → within TTL
- Reuse — cheap read, window extended
- → idle too long
- Cache expired — full rebuild on next call
- → next call
- Rebuilt prefix — whole context at fresh price

A cached prefix is kept for a limited window, the TTL (time to live). The length differs by provider and plan, and is typically somewhere between a few minutes and an hour. Every call that reuses the cache before it expires resets or extends the window.

A session with a live cache is **warm**; one whose cache has expired is **cold**. You can feel the difference only on the bill: the conversation looks identical, but the next call prices it very differently.

## Why it matters

The first call after expiry pays to rebuild the entire prefix at full fresh-input price. That is the single most expensive event a normal session produces, and it grows with the size of the conversation ([context growth](https://ai-sw-factory.mellicci.dev/cost/context-growth)).

It is also invisible. Nothing in the chat changes when the cache lapses, so a lunch break looks free until you add up the day.

## How it works

| Gap since the last call | Cache state | What the next call pays |
|---|---|---|
| Seconds to a few minutes | Warm, window extended | Cheap read of the prefix |
| A coffee break | Usually still warm | Usually a cheap read |
| Longer than the TTL | Expired | The whole prefix again at full price |

The TTL differs between providers, so check yours rather than assuming a number. The price ordering is the same everywhere: a [cache read](https://ai-sw-factory.mellicci.dev/cost/why-tokens-cost-differently) is the cheapest input, fresh input costs several times more, and a cache write costs more than fresh input. [Prompt caching](https://ai-sw-factory.mellicci.dev/cost/prompt-caching) explains what is held in the prefix; this page covers how long it stays.

## Example

On `ticket-service`, a developer works for hours in one session that has grown to 200,000 tokens, then leaves for lunch. The cache expires while they are away. Their first call back can go three ways, shown here for that one call.

| First call back | Cache read | Rebuilt at full price | Notes |
|---|---|---|---|
| Resume as is | 0 | 200,000 | Everything is kept; the whole conversation is re-read at full price |
| Fresh session with a handover note | 0 | about 10,000 | Instructions, tools and a short note; detail from the old session is gone |
| Compact before leaving | 0 | about 30,000 | A summary replaces the history; compaction is lossy |

Compacting before leaving does not keep the cache alive. It shrinks what the cold call must rebuild, and every later call then re-reads a smaller context too. The cost is what the summary dropped.

## What helps, what hurts

Helps:

- Keep calls coming while you work, so each reuse extends the window.
- Before a long break, compact or write a handover note, so the rebuild covers a small prefix.
- Start a fresh session for unrelated work after a long gap rather than reviving a large one ([context growth](https://ai-sw-factory.mellicci.dev/cost/context-growth)).

Hurts:

- Resuming a very large session after a long gap, which rebuilds all of it at full price.
- Assuming a break is free because the conversation looks unchanged.
- Leaving an automated session idle just past the window, then waking it for one small question.

## Trade-offs

- A handover note is cheap to rebuild but loses detail: decisions, dead ends and file knowledge the old session held.
- Compaction shrinks the prefix but is lossy; the summary may omit what you need after lunch.
- Compacting is itself a call: it reads the whole context and writes a summary. Do it while the cache is still warm, before you leave, not after you come back.
- Resuming as is keeps every detail and costs the most. It is the right choice when the detail is hard to recreate.
- Keeping a session warm by polling it costs reads, and only pays off if you will actually continue.

## See it in your own sessions

One way to see this in your own sessions is [Agent Tokenwatch](https://github.com/mellicci/agent-tokenwatch) ([project page](https://mellicci.dev/work/agent-tokenwatch)), an open-source command-line tool for Claude Code, Codex CLI and GitHub Copilot CLI. It records only token counts and structure, never prompts, code or transcripts. Its status line shows whether the session's cache is warm or cold, and its cost coach skill walks through a real cold break from your own telemetry.

## Related

- [Prompt caching](https://ai-sw-factory.mellicci.dev/cost/prompt-caching) - what the cache holds.
- [Why tokens cost differently](https://ai-sw-factory.mellicci.dev/cost/why-tokens-cost-differently) - cache write versus cache read.
- [Context growth](https://ai-sw-factory.mellicci.dev/cost/context-growth) - bigger context, bigger rebuild.

## Key terms

- **TTL (time to live)** - how long a cache entry survives without reuse.
- **Warm session** - cache alive; the next call reads cheaply.
- **Cold session** - cache expired; the next call rebuilds the prefix.
- **Rebuild** - re-processing the whole prefix at full price.