The Cache Hit Is Cheap. The Write Is Not.

1. The hit is the discount. The write is a premium.

Prompt caching is often described as “send the same prefix twice and the second call is cheaper.” That is the hit, not the write. On current Claude models, and on OpenAI from GPT-5.6, writing the prefix costs more than sending it as ordinary input. A bill that looks expensive on the first cached call is often the write rate doing what the pricing page says.

The Claude pricing page states the multipliers. A five-minute cache write is 1.25 times base input. A one-hour write is 2 times. Hits and refreshes are 0.1 times on most models, 0.05 times on Claude Opus 5.5 and Sonnet 5.5, and 0.025 times on Fable 5.1 and Mythos 5.1. The same page does the break-even math: one five-minute write plus one hit is 1.35, against 2 for sending the prefix twice with no cache, so the first full reuse pays it back. A one-hour write is already 2. It needs two hits (2 + 0.2 = 2.2, against 3 for three uncached sends). One write and no second request inside the window is a premium. Unit prices move. The multipliers are what to reconcile, and the pricing page is where to recheck them.

The OpenAI prompt caching guide prices writes at 1.25 times uncached input from GPT-5.6 onward. Reads are 0.1 times on most of those models and 0.05 times on GPT-6.1 Sol. At the 0.1 read rate, one write plus one full read is 1.35 times the prefix, against 2 times for two uncached sends. One write and nine full reads is 2.15, against 10. Models before GPT-5.6 have no extra write charge. They only discount the cached read, at a rate that depends on the model. The 2024 “automatic half price” memory does not describe a GPT-5.6 write. The write rate replaces the normal input rate for those tokens. It is not added on top of it.

2. The clock starts with the request

Claude’s prompt caching docs default to five minutes. Lifetime is measured from the start of the request that writes or reads the entry, not from the end of the response. Their example: if a response streams for four minutes, a follow-up that wants the same prefix must start within about a minute of that response finishing. Generation time counts against the cache. A hit refreshes the lifetime and does not add another write charge. You still pay the read price for that hit. “No extra write” does not mean the hit is free.

The one-hour TTL is explicit, and the write is 2 times base input. It buys a longer window, not a cheaper hit. Automatic caching stays on five minutes unless you set the longer TTL. A top-level cache_control whose TTL disagrees with an explicit breakpoint on the last block returns 400. So does adding automatic caching when four explicit breakpoints already exist. Falling under the minimum length does not error. It just skips the cache. The usage fields in the next section are how you tell those cases apart.

A cache entry becomes readable only after the first response begins. Parallel requests sent together cannot see a write that has not started its response yet, so each of them pays a write. Wait for the first response to begin, then send the rest, if the point was a hit.

On GPT-5.6 and later, prompt_cache_options.ttl supports only 30m, and that is the default. A prefix stays eligible for at least 30 minutes after the latest write or reuse. Reuse refreshes that lifetime without another write charge. OpenAI may keep the entry longer. “May” is not a billing promise. Earlier models use prompt_cache_retention. in_memory typically lasts about 5 to 10 minutes of inactivity, up to an hour. 24h typically stays available around 30 minutes and can last up to 24 hours. Where both exist, organizations without Zero Data Retention default to 24h. Organizations with it default to in_memory. A short window is the retention policy, not a failed request. Caches are not shared across organizations or processing regions.

3. A breakpoint on changing text writes every time

Claude writes one cache entry at the block you mark with cache_control. The hash covers the whole prefix up to that block, in order: tools, then system, then messages. Change any block at or before the breakpoint and the next request is a new write. Reads walk backward from the breakpoint looking for entries earlier requests already wrote, at most 20 positions. The walk does not discover stable text sitting behind a suffix you forgot to mark. Automatic caching puts the breakpoint on the last cacheable block. If that block is the user message that changes every turn, every turn is a write. Put the breakpoint on the last block that stays identical across the calls you want to share. In a growing conversation, the final block still works while each turn adds fewer than 20 blocks. Past that lookback, the previous write sits outside the window, and you need a second breakpoint closer to it, written before you need the hit.

Breakpoints themselves are not a fee. You can place up to four. You pay for tokens written and tokens read. A prefix shorter than the model minimum is processed without caching and without an error. If both cache_creation_input_tokens and cache_read_input_tokens are 0, the prompt was not cached. The docs list minimums of 512, 1024, 2048, and 4096 tokens depending on the model. Use the row for the model you called. Another model’s threshold will send you looking for the wrong bug.

Invalidation follows the same order. Editing tool definitions invalidates tools, system, and messages. Toggling web search or citations, or switching speed between fast and standard, invalidates system and messages. Changing tool_choice or adding and removing images invalidates messages. None of that returns an error. The next call is simply priced as a write. Thinking blocks cannot carry cache_control by themselves. They can be cached as part of an earlier assistant turn, and when they are read back they count as input tokens.

From GPT-5.6, OpenAI lets you place explicit breakpoints. Set prompt_cache_options.mode to explicit and place none, and the request does not use prompt caching and does not create a write. Tokens after the last breakpoint are ordinary input, with no write charge. That is how you keep a changing tail out of the write. Implicit mode puts a breakpoint at the end of the latest eligible message. If that message changes every turn, the write follows it. Earlier models are implicit only. Reported cached_tokens drop hidden system tokens and then round down to a multiple of 128, so the usage figure can be shorter than the prefix you think you sent. Entries live on a machine. Above about 15 requests a minute, traffic can overflow onto a machine that does not hold the entry, and the call misses. Before GPT-5.6, prompt_cache_key influences routing. It does not guarantee a hit. On GPT-5.6 and later, routing is automatic and the key separates cache accounting between customers. It is still not a hit switch. The minimum cacheable prefix on GPT-5.6 and later is 1,024 visible input tokens. Hidden system content does not count. On earlier models the minimum also depends on tools, images, output schema, and reasoning effort.

4. The two usage objects are not the same ledger

Claude’s input_tokens counts only tokens after the last breakpoint, not the whole prompt you sent. Total input is cache_read_input_tokens plus cache_creation_input_tokens plus input_tokens. Multiply input_tokens by the base rate and you drop both the hit and the write, then the invoice looks like an overcharge. On a stream, those three fields are on the message_start usage object, not on the last text event.

OpenAI reports cached_tokens and cache_write_tokens under usage.input_tokens_details. Ordinary input is input_tokens minus those two. Write tokens take the 1.25 rate instead of the base rate, not in addition to it. Adding Claude’s three fields onto an OpenAI response, or subtracting OpenAI’s two details from a Claude response, invents either a double charge or a discount that was never priced. Diagnostic miss counts can disagree with usage. Bill from the usage on this response. Diagnostics add no fee of their own, but extra baseline or retry requests you send for the comparison are billed as those requests.

Multipliers stack. Claude applies cache multipliers on top of the Batch discount, long-context pricing, and data residency. On Claude 4.6 and later, inference_geo set to US-only inference adds 1.1 times to input, output, writes, and reads. Claude Haiku 5.5 prices a prompt over 100,000 tokens on a higher schedule, and cache reads and writes count toward that length. A request over the line pays the higher prices even when part of it is a hit. Shorter earlier requests keep the price they were billed at. This is not the DeepSeek or Qwen context-cache discount. That meter cuts a repeated prefix. Here, on current Claude and on OpenAI from GPT-5.6, the first write can cost more than leaving caching off.

5. Topping up the API account does not create a hit

Reconcile four columns. First, this response’s usage: write tokens, read tokens, and ordinary input after the breakpoint, each at its own multiplier. Do not sum them and multiply once. Second, the clock: Claude counts five minutes or one hour from the start of the request; OpenAI from GPT-5.6 keeps a prefix at least 30 minutes, and earlier models follow in_memory or 24h, including whether the organization has Zero Data Retention. Third, whether the prefix is actually the same: tool definitions, system text, message order, and whether speed flipped between fast and standard. Fourth, whether later calls left before the first response began.

Funding the API account is a fifth ledger. Moving stablecoins on-chain into assets that can top up the platform happens before that credit lands. It does not create a cache hit, and it does not reprice a write that was already recorded at 1.25 or 2 times. When that funding step is what you need, AllSwap swaps on-chain without registration and without custody. A completed swap only means the assets changed hands. The breakpoint, the TTL, and the usage fields still have to be fixed on the request.