# Prompt Caching: Cached Input 10-40x Cheaper (Claude, OpenAI, Gemini)

> How prompt caching works on Claude, OpenAI, Gemini and DeepSeek: price multipliers, TTL, a break-even formula, OpenRouter measurements and why cache misses happen.
> Author: Roman Belov · Published: 2026-11-05 · Source: https://futurecraft.pro/blog/prompt-caching/

Prompt caching is an API mechanism where the provider stores the already processed beginning of a request and reuses it when the next request starts with the same prefix. Those input tokens cost less: on Claude Opus 5.5 and Sonnet 5.5 a cache read costs 5% of the base input price, on Haiku 5.5 10%. The cache only hits on an exact prefix match and expires after a limited time, from minutes to hours.

LLM API requests repeat a lot: the same system prompt, tool definitions, a reference document, a conversation history that grows every turn. Without a cache, every request pays full price for that prefix. In the author's test on Haiku 5.5, the input of the tenth conversation turn was 57 times larger than the first, because the whole history is sent again each time. The [context window](https://futurecraft.pro/blog/context-window/) article explains why.

This guide covers how prefix caching works at Anthropic, OpenAI, Google Gemini and DeepSeek, what it costs, from which request it pays off, and why the cache often misses without any error. Prices and parameters come from vendor documentation as of November 8, 2026. The author's measurements were taken on November 7 and 8, 2026 through OpenRouter, not directly against vendor APIs.

## What gets cached and why order matters

### The request prefix, not the answer

The model processes input tokens in order and computes an intermediate state for each one (the KV cache). If the start of a new request matches the start of a previous one byte for byte, that state doesn't need to be recomputed. The provider stores it and bills a reduced price for those tokens on a hit.

Only the input is cached. The answer is generated again: Anthropic, OpenAI and DeepSeek state this explicitly, and on DeepSeek temperature still produces different answers to identical requests. So caching doesn't affect answer quality. It changes the price and processing time of the input.

The match has to be exact. Anthropic's documentation says cache hits "require 100 percent identical prompt segments", up to and including the block marked with `cache_control`. One changed line at the start of a request turns everything after it into a new prefix.

### Order: tools → system → messages

Anthropic caches a request hierarchically: `tools` first, then `system`, then `messages`. A change at one level invalidates the cache for that level and every level after it. This gives the main rule for all vendors: static content first, variable content last.

| Part of the request | How often it changes | Where to put it |
|---|---|---|
| Tool definitions | Rarely, on release | At the very start |
| System prompt, instructions | Rarely | After tools |
| Reference documents, knowledge base | Sometimes | After system |
| Conversation history | Grows every turn | After documents |
| Current question, timestamp, request ID | Every request | At the very end |

Block order in a prompt is covered in [how to write prompts](https://futurecraft.pro/blog/how-to-write-prompts/). For how text turns into billable tokens, see [tokens explained](https://futurecraft.pro/blog/tokens-explained/).

### Prompt caching vs semantic cache

These are different things. A semantic cache stores finished answers and returns them for similar questions by comparing [embeddings](https://futurecraft.pro/blog/embeddings-explained/) of the requests; the model isn't called at all. Prompt caching runs on the provider side, and the answer is always new. Semantic caching and other ways to cut spend are covered in [LLM cost optimization](https://futurecraft.pro/blog/ai-cost-optimization/).

## Prompt caching by vendor: summary table

Multipliers are relative to the model's normal input token price. Sources: documentation from [Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), [OpenAI](https://developers.openai.com/api/docs/guides/prompt-caching), [Google](https://aistudio.google.com/docs/caching), [DeepSeek](https://api-docs.deepseek.com/guides/kv_cache) and their price lists as of November 8, 2026.

| Vendor and model | How to enable | Read | Write | TTL | Minimum, tokens |
|---|---|---|---|---|---|
| Anthropic Opus 5.5, Sonnet 5.5 | `cache_control` at the top level or on blocks (up to 4) | 0.05x | 1.25x (5 min), 2x (1 h) | 5 min or 1 h, reads refresh it | 512 |
| Anthropic Haiku 5.5 | same | 0.1x | 1.25x / 2x | same | 512 |
| Anthropic Fable 5.1 | same | 0.025x | 1.25x / 2x | same | 512 |
| OpenAI GPT-5.6 | automatic; explicit via `prompt_cache_breakpoint` | 0.1x | 1.25x (30 min), 2.5x (12 h) | 30 min or 12 h | 1,024 |
| OpenAI GPT-6.1 Sol, Terra | same | 0.05x | same | same | 1,024 |
| Google Gemini 3.8 Flash | implicit by default; explicit via `caches.create` | 0.1x | implicit: no premium; explicit: storage fee | explicit 1 h by default; implicit not published | 4,096 (implicit) |
| DeepSeek V4.1 Flash | always on, disk cache | 0.02x | no premium | no fixed TTL | not documented |

OpenRouter's own summary table lists different read ratios for OpenAI, Gemini and DeepSeek (for example, 0.25x or 0.5x for OpenAI). The table above uses the vendors' primary price lists.

Prices in dollars per 1M tokens as of November 8, 2026:

| Model | Input | Write | Read |
|---|---|---|---|
| Claude Opus 5.5 | $4 | $5 (5 min) / $8 (1 h) | $0.20 |
| Claude Sonnet 5.5 | $2 | $2.50 / $4 | $0.10 |
| Claude Haiku 5.5 (prompts up to 100K) | $0.10 | $0.125 / $0.20 | $0.01 |
| Claude Fable 5.1 | $10 | $12.50 / $20 | $0.25 |
| GPT-6.1 Terra | $1.00 | $1.25 (30 min) | $0.05 |
| GPT-6.1 Sol | $2.00 | $2.50 (30 min) | $0.10 |
| Gemini 3.8 Flash (until 12/31/2026) | $0.75 | explicit storage $0.50 per 1M tokens per hour | $0.075 |
| DeepSeek V4.1 Flash (off-peak) | $0.15 | no premium | $0.003 |

Gemini 3.8 Flash prices are promotional: per Google's price list, they double from January 1, 2027 ($1.50 / $0.15 / $1.00). DeepSeek charges twice the off-peak price during peak hours.

## Anthropic prompt caching: cache_control

Without `cache_control`, the Claude API caches nothing. A full Claude API reference, including minimums for older models, is in the [developer guide](https://futurecraft.pro/blog/claude-api-developer-guide/). Here the focus is on two things: price and why the cache misses.

### Automatic mode and explicit breakpoints

There are two ways to turn caching on. Automatic: one `cache_control` field at the top level of the request. The API places the breakpoint on the last cacheable block and moves it as the conversation grows. Explicit: `cache_control` on specific blocks, up to 4 breakpoints per request. If you use both, the automatic breakpoint takes one of the 4 slots.

An example with an explicit breakpoint on a large system prompt:

```python
import anthropic

client = anthropic.Anthropic()
spec = open("spec.md").read()  # stable large context

def ask(question: str):
    r = client.messages.create(
        model="claude-sonnet-5-5",
        max_tokens=512,
        system=[{"type": "text", "text": spec,
                 "cache_control": {"type": "ephemeral"}}],  # "ttl": "1h" for an hour
        messages=[{"role": "user", "content": question}],
    )
    u = r.usage
    print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)

ask("What are the security requirements?")  # write
ask("What are the logging requirements?")   # read
```

In the documentation example, automatic mode looks like `client.messages.create(..., cache_control={"type": "ephemeral"}, ...)` with no per-block markup.

### Cache TTL: 5 minutes or 1 hour

By default the cache lives for 5 minutes, and a write costs 1.25x the input price. With `"ttl": "1h"` it lives for an hour, and a write costs 2x. In both cases a read refreshes the TTL at no cost. The TTL starts at the beginning of the request, so generation time counts toward it. If one request mixes both TTLs, the 1-hour entries must come before the 5-minute ones.

The 1-hour cache is for cases where pauses between requests to the same prefix exceed 5 minutes: an agent waits for the user, or a job runs on a schedule. It pays off from the third request, and over two requests it can cost more than no cache at all.

### Reading usage

| Field | Meaning |
|---|---|
| `cache_creation_input_tokens` | Tokens written to the cache (at the write rate) |
| `cache_read_input_tokens` | Tokens read from the cache (at the read rate) |
| `input_tokens` | Tokens after the last breakpoint, at the normal price |
| `cache_creation.ephemeral_5m_input_tokens`, `ephemeral_1h_input_tokens` | Write breakdown by TTL |

Total input equals the sum of the first three fields. If both cache fields are zero, the cache wasn't involved: either the prefix is below the minimum or `cache_control` never reached the API.

### What invalidates the cache

Per the invalidation table in Anthropic's documentation as of November 8, 2026:

| What changed | Tools cache | System cache | Messages cache |
|---|---|---|---|
| Tool definitions (names, descriptions, parameters) | invalidated | invalidated | invalidated |
| Enabling web search or citations, the `speed` setting | kept | invalidated | invalidated |
| `tool_choice`, adding or removing images | kept | kept | invalidated |
| Thinking parameters, `effort` | model-dependent | model-dependent | invalidated |

In practice, keep the tool set unchanged between calls and don't flip switches like web search mid-conversation.

One more limit: for each breakpoint, the API checks at most 20 positions back. In a long conversation with more than 20 blocks between the current breakpoint and the previous write, the hit is lost. The fix is a second explicit breakpoint closer to the start, or automatic mode, which moves the breakpoint itself.

## OpenAI prompt caching: automatic mode and explicit breakpoints

From GPT-5.6 onward, OpenAI has two modes. Implicit is on by default: OpenAI places a breakpoint at the end of the last eligible message. Explicit caches only at breakpoints the developer sets. The minimum is 1,024 visible input tokens.

The main change from earlier models: writes are no longer free. Before GPT-5.6 there was no write premium. On GPT-5.6 and newer, a write costs 1.25x with a 30-minute TTL and 2.5x with a 12-hour TTL. A read costs 0.1x, or 0.05x on GPT-6.1 Sol and Terra. The TTL is set in `prompt_cache_options`, breakpoints go in the `prompt_cache_breakpoint` field, with up to 4 writes per request.

A Responses API request body with an explicit breakpoint:

```json
{
  "model": "gpt-6.1-terra",
  "prompt_cache_options": {"mode": "explicit", "ttl": "30m"},
  "input": [
    {"role": "developer", "content": [{
      "type": "input_text",
      "text": "<stable instructions, 1,024+ tokens>",
      "prompt_cache_breakpoint": {"mode": "explicit"}
    }]},
    {"role": "user", "content": "<current question>"}
  ]
}
```

In explicit mode with no breakpoints, nothing is cached. Results show up in `usage.input_tokens_details`: `cached_tokens` (read), `cache_write_tokens` (write) and `cache_write_tokens_details` with `ttl_30m_tokens` and `ttl_12h_tokens`. Per the documentation, normal input is `input_tokens − cached_tokens − cache_write_tokens`.

On GPT-5.6 and newer, `prompt_cache_key` isn't needed for hits. It's useful for tracking cache usage separately per customer or user. On older models the key affected request routing, and the TTL was set with `prompt_cache_retention`.

Two more details from OpenAI's documentation: cached tokens count toward the TPM limit, and there's no manual cache clearing.

## Gemini and DeepSeek

### Gemini context caching: implicit and explicit

Google calls the mechanism context caching. On Gemini 2.5 and newer the implicit cache is on by default with nothing to configure. Google recommends putting large shared content at the start of the request and sending similar requests close together in time. The minimum for Gemini 3.8 Flash is 4,096 tokens. Google doesn't publish a TTL for the implicit cache; OpenRouter's documentation says it averages 3-5 minutes.

The explicit cache is created separately with `client.caches.create(...)`, and its name is then passed to `generate_content` via `cached_content`. It lives for 1 hour by default, and the TTL is set as a string like `"300s"`. On top of reads, you pay for storage: $0.50 per 1M tokens per hour on Gemini 3.8 Flash until December 31, 2026. Explicit caching works only through `generateContent` on Gemini 3 and 2.5 models; it isn't available in the Interactions API or on the Gemini 4 line and newer.

Explicit caching pays off with a steady stream of requests against one large document. For infrequent requests implicit is cheaper: there's no storage fee, but no guaranteed hit either.

### DeepSeek context caching on disk

DeepSeek's context cache is on for all users, with no code changes. Hits show up in `prompt_cache_hit_tokens` and `prompt_cache_miss_tokens`. There's no fixed TTL: the cache is cleared once it stops being used, usually within a few hours to a few days per the documentation. It's described as best-effort, with no guarantee of a 100% hit rate. The documentation doesn't state a minimum size.

There's no write premium: a miss costs the same as normal input. On V4.1 Flash a read costs $0.003 per 1M tokens against $0.15 for a miss off-peak, which is 50 times cheaper.

## Through OpenRouter

OpenRouter passes cache parameters to the provider and returns the result in `usage.prompt_tokens_details`: `cached_tokens` (read) and `cache_write_tokens` (write). For Claude, both top-level `cache_control` and explicit blocks work.

The cache lives at a specific provider, so a repeat request has to reach the same one. OpenRouter handles this with sticky routing. Per the [documentation](https://openrouter.ai/docs/guides/best-practices/prompt-caching), it only turns on when the provider's cache read is cheaper than normal input, a session stays sticky for 60 minutes without requests, and the session key is set with `session_id`. A manual `provider.order` disables sticky routing. Routing, ZDR and BYOK are covered in the [OpenRouter guide](https://futurecraft.pro/blog/openrouter-guide/).

## Does the cache pay off: formula and thresholds

Notation: B is the normal price of the prefix, N is the number of requests to it, w is the write multiplier, r is the read multiplier. If all requests fall within the TTL (counting refreshes on read):

- without cache: N·B;
- with cache: w·B + (N − 1)·r·B;
- caching wins when N > (w − r) / (1 − r).

| Mode | w | r | Threshold N | Wins from request |
|---|---|---|---|---|
| Claude 5 min, Haiku 5.5 | 1.25 | 0.1 | 1.28 | 2nd |
| Claude 5 min, Opus 5.5 / Sonnet 5.5 | 1.25 | 0.05 | 1.26 | 2nd |
| Claude 1 hour, Haiku 5.5 | 2 | 0.1 | 2.11 | 3rd |
| Claude 1 hour, Opus 5.5 / Sonnet 5.5 | 2 | 0.05 | 2.05 | 3rd |
| OpenAI 30 min, GPT-6.1 Terra | 1.25 | 0.05 | 1.26 | 2nd |
| OpenAI 12 h, GPT-6.1 Terra | 2.5 | 0.05 | 2.58 | 3rd |
| DeepSeek | 1 | 0.02 | 1 | 2nd |

In dollars: Sonnet 5.5, a 50K-token prefix. Without caching it costs $0.10 per request. A 5-minute write costs $0.125, a read $0.005. Ten requests within the TTL: $1.00 without cache against $0.125 + 9 × $0.005 = $0.17 with it, about 83% saved. With a 1-hour write: $0.20 + 9 × $0.005 = $0.245.

It gets harder when pauses are longer than 5 minutes but shorter than an hour. The 5-minute cache is then rewritten every time and costs 1.25·N·B, 25% more than no cache. The 1-hour cache costs 2·B + (N − 1)·r·B. With r = 0.1 and two requests, that's 2.1·B against 2.0·B without cache, so the 1-hour cache loses over two requests. Over three it already pays off: 2.2·B against 3.0·B.

There are two losing scenarios: a prompt sent once but with `cache_control` (25% more on Claude and GPT-5.6+), and pauses longer than the TTL. For Gemini explicit caching, add a storage fee proportional to the cache's lifetime.

## Measurements: Haiku 5.5, Sonnet 5.5 and three vendors via OpenRouter

These are the author's measurements, all taken through OpenRouter; Claude requests were served by the Claude Platform on AWS provider. Response times include gateway and network latency. Costs come from the `cost` field in OpenRouter's response.

### Baseline: 12,635 tokens on Haiku 5.5

On November 7, 2026, two identical requests to Haiku 5.5 with a 12,635-token system prompt and `cache_control: {type: "ephemeral"}` cost $0.00158 (write) and $0.00013 (read of 12,619 tokens): the second was 12 times cheaper. The table and details are in the [OpenRouter guide](https://futurecraft.pro/blog/openrouter-guide/).

The charges match Anthropic's prices: 12,635 × $0.10 per 1M = $0.00126, and with the 1.25 write multiplier that's $0.00158; 12,619 × $0.01 per 1M = $0.00013. Sixteen tokens weren't read from cache, probably the tail after the breakpoint (the user message and markup). Response time was 1.51 s against 1.41 s, which on 12K tokens is within noise.

### 5-minute TTL

November 8, 2026, Haiku 5.5, the same 12.6K-token system prompt:

| Time (UTC) | Step | cached | cache_write | Cost |
|---|---|---|---|---|
| 08:51:34 | write | 0 | 12,618 | $0.00158 |
| 08:55:36 | 4 min later | 12,618 | 0 | $0.00013 |
| 09:01:38 | 6 min after the previous request | 0 | 12,618 | $0.00158 |

After 4 minutes the cache is read. Six minutes after the last request it's gone: the request writes the cache again and costs as much as the first one.

### 80K prefix: cost and time to first token

November 8, 2026, streaming, Haiku 5.5 (three write-read pairs) and Sonnet 5.5 (one write, four reads). TTFT is the time to the first token of the response.

| Model | Step | Input, tokens | TTFT, s | Cost |
|---|---|---|---|---|
| Haiku 5.5 | write (×3) | 80,802 | 2.47 / 2.78 / 1.71 | $0.0101 |
| Haiku 5.5 | read (×3) | 80,802, 80,786 from cache | 1.27 / 1.63 / 1.29 | $0.00081 |
| Sonnet 5.5 | write | 80,804 | 1.69 | $0.2020 |
| Sonnet 5.5 | read (×4) | 80,804, 80,788 from cache | 1.32 / 1.32 / 1.33 / 1.21 | $0.00815 |

At 80K, a read is 12.5 times cheaper than a write on Haiku 5.5 and 25 times cheaper on Sonnet 5.5. TTFT on reads is shorter, but the spread is wide: 1.3-1.6 s against 1.7-2.8 s on Haiku, about 1.3 s against 1.7 s on Sonnet's single write. The main gain is cost. Times were measured through the gateway; direct API numbers will differ.

On OpenRouter, Sonnet 5.5 reasoning can't be turned off: `reasoning: {enabled: false}` returns a 400 error with the message "Reasoning is mandatory for this endpoint and cannot be disabled". So Sonnet's read cost includes reasoning tokens. On Haiku 5.5, reasoning can be disabled.

### Three vendors on one prefix

November 8, 2026, a prefix of about 18K tokens, no explicit cache parameters, requests sent back to back a few seconds apart:

| Model | Provider | Call | cached | cache_write | Cost |
|---|---|---|---|---|---|
| GPT-6.1 Terra | OpenAI | 1 | 0 | 18,234 | $0.02282 |
| GPT-6.1 Terra | OpenAI | 2 | 18,234 | 0 | $0.00094 |
| Gemini 3.8 Flash | Google | 1 / 2 | 0 / 0 | 0 | $0.01336 each |
| Gemini 3.8 Flash | Google | new prefix, 1 / 2 / 3 | 0 / 0 / 12,261 | 0 | $0.01334 / $0.01336 / $0.00508 |
| DeepSeek V4.1 Flash | not pinned | 1 / 2 | 0 / 0 | n/a | $0.000115 / $0.00349 |
| DeepSeek V4.1 Flash | DeepInfra (pinned) | 1 / 2 / 3 | 0 / 18,304 / 18,304 | n/a | $0.00257 / $0.0000843 / $0.0000843 |

What this shows for the three vendors:

- GPT-6.1 Terra caches automatically and bills the write at the higher rate: 18,234 × $1.25 per 1M ≈ $0.0228. A read is 24 times cheaper than the write.
- On Gemini 3.8 Flash, the implicit cache hit only on the third call, and only partially: 12,261 tokens out of 17,779. Hits aren't guaranteed.
- Without a pinned provider, two identical requests to DeepSeek V4.1 Flash went to different providers (Relace and Wafer). There was no cache hit, and the prices differed 30-fold. With the provider pinned via `provider: {order: [...], allow_fallbacks: false}`, reads were 30 times cheaper from the second call. These are DeepInfra's prices, not DeepSeek's price list.

## Where caching helps most

### Agents and coding agents

An agent loop sends the same tools and system prompt at every step while the history grows. This is the best case for caching: a large prefix, frequent requests, short pauses. Anthropic's automatic mode moves the breakpoint along with the history, so each step reads almost all of the previous context from cache. If the agent waits for the user longer than 5 minutes, run the 1-hour option through the formula above. Agent loops are covered in the [AI agents guide](https://futurecraft.pro/blog/ai-agents-complete-guide/).

### RAG with a large fixed context

If every request carries the same knowledge base of tens of thousands of tokens, caching cuts the cost of resending it by 90-95% on most Claude and OpenAI models (not counting the first write). Retrieved chunks and the user's question go after it. When it's cheaper to keep everything in context with caching and when to retrieve chunks is covered in [Context Engineering vs RAG](https://futurecraft.pro/blog/context-engineering-vs-rag/).

### Chatbots and support

A long instruction set, company policy and FAQ are the same for every user. The user's name, data and the current time go at the end, after the breakpoint. Otherwise every user gets their own prefix and the cache is never reused.

### Parallel requests and batch

On Anthropic, a cache write becomes available only after the response to the first request starts. If you send 20 requests with the same prefix at once, each of them may write the cache from scratch. The fix: send one request, wait for its response to start, then launch the rest in parallel.

## Anti-patterns and diagnostics

### A timestamp at the start of the prompt: measured

A common mistake is a line with the current time, a request ID or a user name at the start of the system prompt. Test on November 8, 2026, Haiku 5.5, a 12.6K-token system prompt:

| Variant | Request | cached | cache_write | Cost |
|---|---|---|---|---|
| `Current time: …` at the start of system | 1 / 2 / 3 | 0 / 0 / 0 | 12,638 each | $0.00158 each |
| static block with `cache_control`, time in a separate block after it | 1 | 0 | 12,626 | $0.00158 |
| same | 2 / 3 | 12,626 | 0 | $0.00013 |

One changing line at the start disables caching completely, and every request pays for a write, which is 25% more than no cache at all. The fixed version:

```json
{
  "system": [
    {"type": "text", "text": "<long static instructions>",
     "cache_control": {"type": "ephemeral"}},
    {"type": "text", "text": "Current time: 2026-11-08T08:51:45Z"}
  ]
}
```

### Other causes of misses

- Tools are generated dynamically or in a different order. On Anthropic, changing tools invalidates the entire cache.
- `tool_choice`, thinking parameters or the set of images change between calls.
- The prefix is below the minimum: 512 tokens on Claude 5.5, 1,024 on OpenAI GPT-5.6+, 4,096 for Gemini 3.8 Flash's implicit cache. There's no error, and no cache either.
- A pause longer than the TTL.
- Parallel first requests without a warm-up.
- More than 20 blocks between the breakpoint and the previous write in a conversation.
- On DeepSeek and Gemini's implicit cache, hits aren't guaranteed by design.
- Through OpenRouter: requests go to different providers.

### Checklist: is the cache working

1. Log three numbers for every request: read from cache, written to cache, normal input.
2. Compute the hit rate as the share of cache-read tokens in total input.
3. Compare actual charges with the formula: if every request writes, the prefix is changing.
4. Check that the first difference between two consecutive requests comes after the breakpoint.
5. Put the hit rate on a dashboard and alert on drops; collecting such metrics is covered in [LLM observability](https://futurecraft.pro/blog/llm-observability-langfuse/).

Fields to log by vendor:

| Vendor | Read | Write |
|---|---|---|
| Anthropic | `cache_read_input_tokens` | `cache_creation_input_tokens` |
| OpenAI | `input_tokens_details.cached_tokens` | `input_tokens_details.cache_write_tokens` |
| DeepSeek | `prompt_cache_hit_tokens` | none (miss: `prompt_cache_miss_tokens`) |
| OpenRouter | `prompt_tokens_details.cached_tokens` | `prompt_tokens_details.cache_write_tokens` |

On Gemini the field name depends on the API and SDK: the Interactions API documentation uses `usage.total_cached_tokens`, and in `generateContent` the counter comes in `usage_metadata`.

## Summary

Prompt caching makes a resent prefix 10 to 50 times cheaper to read, depending on vendor and model (10x on Haiku 5.5, 20x on Opus 5.5 and Sonnet 5.5, 40x on Fable 5.1, 50x on DeepSeek V4.1 Flash). It only works under three conditions:

1. Static content goes at the start of the request, and everything that changes goes after the breakpoint.
2. The TTL matches the real pauses between requests: 5 minutes for a steady stream, an hour for agents that wait on the user.
3. Hits are checked in usage on every request, not assumed.

Prefix caching is one of several ways to cut LLM spend. The others (choosing the model for the task, batch, semantic caching, trimming context) are covered in [LLM cost optimization](https://futurecraft.pro/blog/ai-cost-optimization/).