Prompt caching

Prompt caching in Claude Code and Codex

The provider caches the start of the prompt, and on Claude Opus 5.5 a cached token read back costs a twentieth of a fresh one. If anything changes text inside that cached part, the next call writes it to cache again at a higher price, so Context Mode changes tool output only the first time it passes and sends the same bytes on every later turn.

Key facts

What it is: How the gateway keeps Claude Code and Codex requests cache-friendly: the first-sight rule, cache marks on the fixed part of the prompt, and a cache for fetched pages.
Who it is for: Developers and CTOs who see high cache-write costs in Claude Code, or want to know whether a proxy breaks the prompt cache.
Clients: Claude Code and Codex. The system split and the list moves act on Claude Code requests.
Measured result: The results are measured cost, so every cache write is in them: Claude Code on Claude Opus 5.5 cost 65.5% less on a long agentic coding session, which went from $7.20 to $2.49, 4 of 4 pairs cheaper, run on 2026-10-03. Over 168 shorter paired runs on 2026-09-29, 155 cost less and 168 of 168 tasks passed in both arms. Method and evidence.
Limits: On very long threads the gateway rewrites cached text at fixed steps, and one request writes the history to cache again at each step. The provider accepts at most 4 cache marks.

What cache reads and writes cost

A cached token read back costs a twentieth of a fresh one on Opus 5.5 and a tenth on Haiku 4.5. A token written to cache costs 1.25 times a fresh one with a 5-minute mark, and twice with a 1-hour mark (Anthropic prompt caching, read 2026-10-01). So a saving that rewrites cached text can cost more than it saves. OpenAI also prices repeated input far lower than new input (OpenAI prompt caching).

What makes a coding agent write the cache again

Changed tool output. If a tool or a proxy changes text inside the cached part of the conversation, the next call writes it to cache again.
Per-session text in the system prompt. Claude Code joins the fixed and the per-session parts of its system prompt into one block, so each new session writes the fixed part again.
Changing lists. The skill list and agent-type list change between sessions. When they sit in the cached start, a change breaks the cache for what follows.
Fetched pages. Claude Code hands each WebFetch page to a small helper call with no cache mark, so each read of the page is charged as fresh input.

What the gateway does

First sightA tool result is changed only the first time it passes. The change depends only on the result's text, so every later request carries the same bytes and the provider reads them from cache.

System splitThe gateway cuts Claude Code's system prompt at the first per-session heading, so the fixed part gets its own cache mark.

Lists moveThe skill and agent-type lists move, unchanged, into the descriptions of the tools they describe, and those tools move to the end of the tool array. Nothing is added, removed or reworded.

Page cacheA WebFetch helper call is split into the page and the question, and the page is marked for a 5-minute cache. The next read of that page within 5 minutes is a cache read.

Mark budgetThe gateway never removes a mark your client set, and adds its own only while a slot is free. If the provider refuses the mark count, the request is retried once with no gateway marks.

Every change is listed, with its limits, in Context Saving.

Context Saving Benchmarks