Prompt Caching on Claude, GPT and Gemini, Measured: Same Price, Different Bills

Claude Sonnet 5.5, GPT-6.1 Sol and Gemini 4 Argon list the same prices: $2 per million input tokens, $10 for output, and $0.10 for a cached read. So prompt caching should save the same on all three. It doesn't.

We sent one prompt to each model several times, with a different question each time, and the bills went three ways. GPT cached it without being asked. Claude cached it only when we put the cache breakpoint in the right place, and in the wrong place it cost more than not caching at all. Gemini 4 Argon cached nothing.

How we tested: On October 27, 2026 we sent one 18 KB prompt (three MIT-licensed Laravel source files and a two-line instruction) to Claude Sonnet 5.5, GPT-6.1 Sol and Gemini 4 Argon, plus Gemini 3.7 Flash as a control, through OpenRouter, each pinned to its own maker's API at standard prices, with a different question each time. We recorded the tokens and cost every response reported. Each setting ran once, and we didn't call the providers' own APIs or test Claude's 1-hour or OpenAI's 12-hour cache. That came to 22 calls and 0.21 USD.

What did the same prompt cost on each model?

Input cost only, from each response's usage data. Output varied with the answer, so it's left out.

Prices checked on October 27, 2026. Gemini 4 Argon's are introductory. From December 1, 2026, input goes to $4 and cached reads to $0.20 per million tokens.

Why is the same prompt more tokens on Claude?

Each company counts tokens its own way, and the list price is per token. Our prompt came to 6,460 tokens on Claude, 4,861 on Gemini and 4,265 on GPT. That's 51% more on Claude than on GPT for the same text.

So at the same $2 list price, sending the prompt once with no caching costs $0.0129 on Claude, $0.0097 on Gemini and $0.0085 on GPT. That last one is arithmetic (4,265 tokens at $2 per million), because GPT caches by default and never ran uncached. That's one PHP-heavy prompt. Prose may split differently, but check the token count of your own prompt before you compare list prices.

How does GPT-6.1 Sol cache?

Without being asked. The first call wrote 4,262 tokens to the cache at OpenAI's write rate of $2.50 per million, so it cost $0.01066, 25% more than the $0.0085 an uncached call would have cost. The next call, 90 seconds later with a different question, read 4,246 tokens from the cache and paid $0.00047 for its input. That's 96% less than the first call.

The changing question didn't matter. OpenAI's prompt caching guide says requests look for the longest prefix already in the cache, and the shared files were that prefix. It was still cached 5.6 minutes later. After 53.7 minutes without a request it was gone, and that call paid the write rate again. We can't tell when in that gap it expired. OpenAI gives the default cache a minimum lifetime of 30 minutes from the last write or read, and a 12-hour option in its Responses API that costs 2.5 times the input price on the write.

How do you cache on Claude Sonnet 5.5?

You have to ask, and where you ask decides the bill. With no cache setting, every call paid the full $0.0129.

With a single cache_control at the top level of the request (Anthropic's "automatic caching", which OpenRouter passes through), every call wrote a fresh cache and none ever read one. Each paid about $0.0162 for input, 25% more than not caching. Three calls in a row, same result.

The reason is in Anthropic's prompt caching docs. Automatic caching puts the breakpoint on the last block of the request, and our last block was the question, which changed every time. Anthropic describes it as best for multi-turn conversations, where the growing history is what you want cached. For a fixed context with a new question each time, it caches the wrong thing.

Moving the breakpoint fixed it. With cache_control on the system block that holds the files, the first call wrote 6,436 tokens and the second, 30 seconds later, read them back. Its input cost $0.00069, 96% less than the first call and 95% less than uncached.

Then we waited 5.5 minutes. The cache was gone, and the next call paid the write rate again. Claude's default cache lives 5 minutes, refreshed free on every hit. A 1-hour cache costs twice the input price on the write. We saw the same pattern inside Claude Code. In our test of what burns a Claude Code limit, resuming a session after its one-hour cache expired cost 10 times a resume within it.

Does Gemini 4 Argon cache at all?

Not for us. Five calls, two of them with cache_control on the system block, and not one cached token. OpenRouter reported no cache writes either.

Google's caching docs say explicit caching isn't supported on Gemini 4 Argon, and that implicit (automatic) caching applies from 4,096 tokens. Our prompt was 4,861. The same page says that on Gemini 4, when a request adds fewer than 2,050 tokens to the previous one, Gemini re-processes the last 2,050 at the full rate. If that applies to separate requests like ours, it leaves about 2,800 reusable tokens, under the minimum. It doesn't explain the next report, though. A Google AI Developers Forum thread from October 14 reports zero cache hits on Argon with a 36,000-token prefix, and a forum moderator replied the next day that they are looking into it.

As a control, we ran the same prompt on Gemini 3.7 Flash (Google's deprecation page says that endpoint now routes requests to Gemini 3.8 Flash, and OpenRouter billed its 3.7 Flash rates, which equal Google's 3.8 Flash prices). Its implicit caching found nothing in three calls either. With cache_control on the system block it worked at once. The first call wrote 4,829 tokens to the cache and read them in the same request, and its input cost $0.00057 against $0.00363 uncached, 84% less. So explicit caching through OpenRouter works on Gemini Flash. It's Argon, and implicit caching, that didn't deliver in our test.

What does that mean on a real workload?

Say a support bot sends this prompt 100 times within an hour, never more than a couple of minutes apart. Input cost, from our per-call numbers, assuming every repeat hits the cache the way ours did:

Same list prices, a 28-fold spread between the cheapest and the most expensive setup.

Which setup should you use?

On Claude: put cache_control on the last block that doesn't change (the system prompt, tool definitions or documents), not at the top level of a single-question request. Keep repeats under 5 minutes apart, or pay double on the write for the 1-hour cache.

On GPT: nothing to switch on. Put the shared part first and expect the first call to cost 25% more than uncached.

On Gemini 4 Argon: don't plan your costs on caching yet. If caching is most of your bill, Gemini Flash (we called it as 3.7 Flash, which Google routes to 3.8) did cache for us with an explicit cache setting.

Everywhere: read the cache fields in the usage data of your first few responses (cached_tokens and cache_write_tokens on OpenRouter, cache_read_input_tokens and cache_creation_input_tokens on Anthropic's own API). That's how we caught the top-level setting writing a new cache on every call, and it's the quickest way to know caching works for your prompt. If your numbers come out differently, tell us on X at @devtoolpicks. For where these models stand on quality and price, see our Gemini 4 Argon vs Claude 5.5 test.