{"slug": "tokenomics-the-349-minute-rule-for-gpt-5-6", "title": "Tokenomics: the 349 minute rule for GPT-5.6+", "summary": "OpenAI's GPT-5.6 and GPT-6 models now bill cache writes at 1.25x the input price and cache reads at 0.1x, with a cache lifetime of at least 30 minutes, according to a Tokenomics analysis of OpenAI's documented prices and behavior. Because a rewrite costs as much as 12.5 reads, the analysis concludes keeping a GPT-5.6/GPT-6 cache warm beats rewriting it for 349 minutes, refreshing every 29 minutes, and that paying for the write is worthwhile once the odds of reuse exceed 27.8%. The write is repaid by the first reuse, though OpenAI does not document a way to send a cheap refresh request, and GPT-6 at least allows reasoning to be turned down on refresh requests.", "body_md": "[← Posts](https://skids.dev/blog/)\n\n# Tokenomics: the 349 minute rule for GPT-5.6+\n\nGPT-5.6 onwards made cache writes cost 1.25x. When is the write worth paying for, and how long is the cache worth keeping warm?\n\nSo far I’ve only talked about Anthropic in my series on [Tokenomics](https://skids.dev/blog/tags/tokenomics/), because I almost exclusively use Anthropic models for everything so I haven’t needed to optimise for OpenAI’s cache too much. In one of my previous posts, I (with substantial help from my clanker, of course) calculated the [62.5-minute rule](https://skids.dev/blog/anthropic-cache-tokenomics/) for Claude’s 5-minute prompt cache, and earlier this month I [reran the numbers](https://skids.dev/blog/fable-cache-tokenomics/) once Fable 5.1 made reads cheaper.\n\nOpenAI never got the same treatment, both because of the above and because there wasn’t anything to work out—caching was automatic and writes were free. That changed with the release of GPT-5.6 (and subsequently GPT-6) models, because all of them now bill a cache write at 1.25x the input price and a read at 0.1x, with a lifetime of at least 30 minutes. This is a pretty significant departure from Anthropic’s cache policy, which only has a lifetime of 5 minutes (or 1 hour, if you pay the tax).\n\nIf those multipliers look familiar, it’s because they’re exactly the same ones from my first post in this series about Anthropic—except the cache lasts a whopping six times longer than our favourite “it’s time to pace the frontier” lab.\n\nSo that begs the question: if the cache is about to expire and I don’t have a real request to send, is it cheaper to send a dumb refresh request or let it die and pay for the rewrite later? OpenAI also writes to the cache by default, which raises a question opt-in caching never did—is the write worth paying for at all?\n\ntl;dr: A rewrite costs as much as **12.5 reads**, so keeping a GPT-5.6/GPT-6 cache warm beats rewriting it for **a smidge under six hours** - 349 minutes, refreshing every 29. That only holds true if a refresh costs next to nothing, and OpenAI doesn’t document a way to send one, although GPT-6 at least lets you turn the refresh requests’s reasoning down. The write itself is repaid by the first reuse, and it’s worth betting on once the odds of that reuse are better than **27.8%**.\n\nEverything below is worked from OpenAI’s documented prices and behaviour, rather than my own traces.\n\n## Two caches under one roof\n\n“OpenAI prompt caching” now means two different systems depending on the model, and the [prompt caching guide](https://developers.openai.com/api/docs/guides/prompt-caching#summary-of-model-differences) makes the distinction clear at GPT-5.6:\n\n| Behaviour | GPT-5.6 onwards | Earlier models | \n|---|---|---|\n| Cache write | 1.25x input | no extra charge | \n| Cache read | 0.1x input | model-dependent | \n| Breakpoints | implicit and explicit | implicit only | \n| Minimum prefix | 1,024 tokens | varies with request settings | \n| Lifetime | at least 30 minutes after a write or hit | best effort, usually 5-10 idle minutes in memory | \n| `prompt_cache_key` | optional, routing is automatic | recommended for routing | \n\nOn an earlier model there’s nothing to think about—Letting the first request populate the cache costs nothing, so there’s no reason not to. On the newer models, a write that never gets left unread is a straight 25% overpay on that prefix. Thankfully the whole GPT-5.6 and GPT-6 family sits on that interesting of the line, and the [standard short-context prices](https://developers.openai.com/api/docs/pricing) as of September 27th are:\n\n| Model ($ / MTok) | Input | Cache write | Cache read | Output | \n|---|---|---|---|---|\n| GPT-6 Astra | $10.00 | $12.50 | $1.00 | $50.00 | \n| GPT-6 Sol | $2.00 | $2.50 | $0.20 | $10.00 | \n| GPT-6 Luna | $0.10 | $0.125 | $0.01 | $0.50 | \n| GPT-5.6 Sol | $4.00 | $5.00 | $0.40 | $20.00 | \n| GPT-5.6 Terra | $2.00 | $2.50 | $0.20 | $12.00 | \n| GPT-5.6 Luna | $0.20 | $0.25 | $0.02 | $1.20 | \n\nGPT-6 Sol is exactly half the price of GPT-5.6 Sol, which is itself on a promotional price until at least November 21st, so GPT-6 Sol is the one I’ve used for the worked examples below. All three GPT-6 models price output at 5x input, same as GPT-5.6 Sol, while GPT-5.6 Terra and Luna charge 6x.\n\nEvery input token lands in exactly one of three buckets, and the 1.25x is the whole price of a written token rather than a surcharge on top of the 1x. The usage block reports them as `input_tokens`, `input_tokens_details.cached_tokens` and `input_tokens_details.cache_write_tokens`, and plain input is whatever’s left over once you subtract the other two.\n\nBatch and Flex halve everything, Fast doubles it, and regional processing adds 10%. Those modifiers hit reads, writes and plain input together, so none of the ratios below move.\n\n## The cache write starts paying off from the very next request\n\nTake a stable prefix that costs `C` to process uncached, and send it `N` times:\n\nOn a single request, caching is a flat 25% loss. By the second request, the write has already paid for itself, at `1.35C` against `2C`. For a 100K-token prefix on GPT-6 Sol, that’s a $0.25 write and $0.02 reads against $0.20 uncached:\n\n| Prefix uses | No cache | Cache | Saving | \n|---|---|---|---|\n| 1 | $0.200 | $0.250 | -$0.050 | \n| 2 | $0.400 | $0.270 | $0.130 | \n| 5 | $1.000 | $0.330 | $0.670 | \n| 10 | $2.000 | $0.430 | $1.570 | \n\nTen prefix hits is a 78.5% saving, creeping towards 90% as the write gets spread thinner. Output and anything after the prefix cost the same either way, so they null out.\n\nThat table assumes you know the second request is coming, and a lot of the time you might not—which makes the write a bet. Say exactly one later request might reuse the prefix, and `p` is the chance it shows up while the entry can still be hit:\n\nBoth strategies are straight lines in `p`, so the only thing to look for is where they cross:\n\nWriting wins anywhere to the right of the 27.8% line. With more than one possible reuse, swap `p` for the expected number of full-prefix reads and the threshold is still 0.2778 of a read. That number falls out of the prices rather than anything OpenAI publishes, and `p` has to cover everything that can turn a reuse into a miss - the TTL, routing, and a prefix that’s almost-but-not-quite byte-identical.\n\nThe way to act on it is `prompt_cache_options.mode: \"explicit\"`. In the default implicit mode, OpenAI puts a breakpoint at the end of the latest message and bills the write whether or not anything ever comes back to that boundary. In explicit mode, only the content blocks you mark with `prompt_cache_breakpoint` get written, everything after the last one is plain input, and a request with no breakpoints at all isn’t cached or charged for it. One-shot requests against a prefix you’ll never see again belong in that last bucket.\n\n## Twelve reads, not 375 minutes\n\nA hit refreshes the 30-minute lifetime without another write charge, so the same cache warming/refresh approach that works with Anthropic also works here. Once the initial write is paid for, compare `k` refreshes plus the eventual real request against letting the entry expire and rewriting it:\n\nThe lazy version of this sum multiplies the read budget by the TTL and gets `12.5 * 30 = 375 minutes`. That’s tempting, but it’s wrong in two ways. It drops the final `+ 1`, because coming back to a warm cache still costs a read, and there’s no such thing as half a refresh. For the 100K Sol prefix:\n\n| After the initial write | Cost | \n|---|---|\n| 11 refreshes + return | 12 * $0.02 = $0.24 | \n| 12 refreshes + return | 13 * $0.02 = $0.26 | \n| Expire, then rewrite | $0.25 | \n\nSo eleven refreshes is the limit. The 30 minutes is a minimum measured from the latest write or hit, and a refresh that lands right on the boundary isn’t guaranteed anything, so space them at 29 minutes-ish. They go out at minutes 29 through 319, the entry is guaranteed until minute 349, and a real request at minute 348 is the twelfth read and still (just) beats the rewrite. So, around 5 hours 48 minutes.\n\nAs with Anthropic, the model’s price and the prefix size sit on both sides and cancel, leaving `1.25 / 0.1`. That means GPT-6 Astra and GPT-6 Sol on the same 100K prefix should cross their rewrite lines at the same minute, even though Astra costs five times as much:\n\nAstra’s lines sit higher and both staircases go over at minute 349. Inside the first 30 minutes the two strategies are the same request, which is why the dashed lines start low and then jump.\n\nThe dollars follow the same pattern as with Anthropic models. One cycle on GPT-6 Sol is a write, `T` idle minutes with a refresh every 29, then the next actual request:\n\n| Prefix size | Strategy | T = 60 min | T = 180 min | T = 300 min | T = 420 min | \n|---|---|---|---|---|---|\n| 50K tokens | keep warm + read at T | $0.155 | $0.195 | $0.235 | $0.275 | \n| 50K tokens | rewrite at T | $0.250 | $0.250 | $0.250 | $0.250 | \n| 100K tokens | keep warm + read at T | $0.310 | $0.390 | $0.470 | $0.550 | \n| 100K tokens | rewrite at T | $0.500 | $0.500 | $0.500 | $0.500 | \n| 250K tokens | keep warm + read at T | $0.775 | $0.975 | $1.175 | $1.375 | \n| 250K tokens | rewrite at T | $1.250 | $1.250 | $1.250 | $1.250 | \n\nAfter an hour away, keeping a 250K Sol prefix warm saves $0.475. After five hours it saves $0.075, and after seven it costs $0.125 more than letting the entry go (multiply all of that by 5 for Astra). Right before the crossover there’s barely any money left to save, so it doesn’t take much of a refresh cost to wipe it out.\n\n## A refresh isn’t free\n\nThe previous 62.5-minute Anthropic rule assumed a refresh that costs one read and nothing else, and Anthropic documents exactly that: a `max_tokens: 0` request that touches the cache without billing any output. OpenAI’s caching guide unfortunately has nothing like it. The closest thing is a `prompt_cache_options.prewarm` boolean that [landed in the Python SDK](https://github.com/openai/openai-python/pull/3888) on September 17th, which the API spec describes as preparing the prompt cache without generating output. The guide doesn’t mention it, nothing says what it bills or whether it refreshes an entry that already exists.\n\nWithout it, a refresh is just an ordinary request that generates output, reasoning tokens included. Output on every GPT-6 model is 5x input and a read is 0.1x, so one output token costs the same as reading 50 cached ones. A refresh that reads `N` cached tokens and generates `o` output tokens is worth more than one read:\n\nKeeping all eleven refreshes needs `o < N / 1,100`. For the 100K Sol prefix that’s 90 output tokens per refresh, which squares with the money: eleven refreshes and the return cost $0.24 against a $0.25 rewrite, so the refreshes have one cent between them for everything that isn’t the cached read. A reasoning model can easily spend that deciding how to say hello.\n\nThis is also where the prefix size stops cancelling—The read scales with `N` and the output doesn’t, so the same chatty refresh does a lot more damage to a small cache than a big one:\n\nAt 500 output tokens per refresh, a 250K prefix is still worth bridging for 320 minutes and a 20K prefix for 175. At 2,000 tokens the 20K prefix gets one refresh and 59 minutes. GPT-5.6 Terra and Luna price output at 6x, which tightens the budget to `N / 1,320`. Anything after an explicit breakpoint in the refresh is plain input at 1x on top, and a refresh that misses is another 1.25x write.\n\nGPT-6 does give you one lever that GPT-5.6 doesn’t: the obvious way to shrink a refresh is to turn its reasoning down, but changing the top-level `reasoning.effort` [can change OpenAI’s hidden instructions](https://developers.openai.com/api/docs/guides/prompt-caching#which-settings-affect-the-cached-prefix), and those are a key part of the cache… key. A GPT-5.6 refresh sent at a lower effort than the real requests risks missing, which swaps a 0.1x read for a full 1.25x write.\n\nOn the GPT-6 family you can leave the top-level setting alone and append a [`configuration_update`](https://developers.openai.com/api/docs/guides/reasoning) item after the prefix instead. It changes the effort for whatever follows without touching anything before it, so a refresh can drop to `low` and still hit. Sol and Luna also list `none` as an effort level (Astra doesn’t), though the docs don’t say whether an update accepts it. It still generates output, and I haven’t measured what a low-effort refresh actually bills, but it’s the closest thing to a cheap refresh OpenAI documents.\n\nSo the almost-six-hour number is a ceiling, and you only get near it with a big prefix and a refresh that barely says anything. For a small prefix refreshed by a model that likes to think out loud, the real answer is a couple of hours, or maybe less.\n\n## The long context pricing cliff\n\nEvery number so far has used short-context prices. Once a request’s input goes over 272K tokens, OpenAI bills the whole request at [long-context rates](https://developers.openai.com/api/docs/pricing), not just the tokens past the line. Input, cache writes and cache reads all double, and output goes up 1.5x:\n\n| Model ($ / MTok) | Input | Cache write | Cache read | Output | \n|---|---|---|---|---|\n| GPT-6 Astra | $20.00 | $25.00 | $2.00 | $75.00 | \n| GPT-6 Sol | $4.00 | $5.00 | $0.40 | $15.00 | \n| GPT-6 Luna | $0.20 | $0.25 | $0.02 | $0.75 | \n| GPT-5.6 Sol | $8.00 | $10.00 | $0.80 | $30.00 | \n| GPT-5.6 Terra | $4.00 | $5.00 | $0.40 | $18.00 | \n| GPT-5.6 Luna | $0.40 | $0.50 | $0.04 | $1.80 | \n\nGPT-5.6 Terra and Luna’s model pages only say “2x input and 1.5x output”, so I’ve assumed their cache rates double along with input, the same as everyone else’s.\n\nBecause reads and writes double together, a rewrite still costs 12.5 reads. The 27.8% odds and the 349-minute window don’t move, and the dollars just double. On GPT-6 Sol:\n\n| Prefix size | Strategy | T = 60 min | T = 180 min | T = 300 min | T = 420 min | \n|---|---|---|---|---|---|\n| 300K tokens | keep warm + read at T | $1.860 | $2.340 | $2.820 | $3.300 | \n| 300K tokens | rewrite at T | $3.000 | $3.000 | $3.000 | $3.000 | \n| 500K tokens | keep warm + read at T | $3.100 | $3.900 | $4.700 | $5.500 | \n| 500K tokens | rewrite at T | $5.000 | $5.000 | $5.000 | $5.000 | \n| 800K tokens | keep warm + read at T | $4.960 | $6.240 | $7.520 | $8.800 | \n| 800K tokens | rewrite at T | $8.000 | $8.000 | $8.000 | $8.000 | \n\nAfter an hour away, keeping a 500K prefix warm saves $1.90, and after seven hours it costs $0.50 more than letting it go.\n\nThe output ratio is the one thing though that does move. Output only goes up 1.5x while reads double, so an output token costs 37.5 cached reads on every GPT-6 model instead of 50:\n\nEvery prefix in long-context territory is over 272K, so a refresh gets about 330 output tokens before the window starts shrinking, and a 1M prefix gets 1,212. GPT-5.6 Terra and Luna’s 6x output makes it 45 reads per output token and `N / 990`, or about 275 tokens at the line. It’s one of the rare cases where a bigger bill makes refreshes cheaper.\n\nThe line itself is the part that actually stings. It’s measured on the request’s input, not the cached prefix, so a 270K prefix plus a 5K tool result is a 275K request, and every one of those 270K cached tokens gets billed at the long-context rate:\n\nReading 272K cached tokens on GPT-6 Sol costs $0.0544. One more token and it’s $0.1088, which is what a 544K read would cost at short-context rates, and the output from that request costs 1.5x as well.\n\nIf a session has drifted over the line, trimming it back under (dropping old tool results, say) means paying for a fresh write at short-context rates in exchange for halving every read after it. With `N` tokens over the line, `M` under it, and everything in multiples of the short-context input price:\n\nTrimming a 300K prefix to 250K pays for itself on the ninth call, and trimming it to 270K takes ten. A 500K prefix trimmed to 250K pays back in four. That ignores fresh input and output, which also get cheaper under the line, so real payback comes a bit sooner. It’s also fairly easy to actually model, because dropping tool results doesn’t bill a summary. It does cost the model whatever was in them, though.\n\n## Footguns\n\n**Implicit mode writes the bit you won’t reuse.** A static developer message followed by a changing user message looks super cacheable, but the implicit breakpoint goes at the end of the latest message. The write runs straight through the part that changes, and the next request can’t match it. Put an explicit breakpoint after the static block. The implicit breakpoint also takes one of the four write slots a request gets, which leaves three for yours.\n\n**Extending a message loses its boundary.** Turning message `A` into `A + B` can drop the old entry that ended after `A`. Append `B` as a new message, or give `A` its own content block with a breakpoint. Top-level `instructions` can’t carry a breakpoint at all, so reusable instructions belong in an `input_text` block inside a developer message.\n\n**Small prefixes don’t cache, and padding them can be cheaper.** The floor is 1,024 visible tokens, and OpenAI’s hidden system tokens don’t count towards it. The guide [works through the slightly odd consequence](https://developers.openai.com/api/docs/guides/prompt-caching#escape-the-minimum-cacheable-length-cost-trap): sending a short prefix uncached `N` times costs `N * L`, while padding it up to the floor costs `1,024 * (1.25 + 0.1 * (N - 1))`. Padding wins from 692 tokens at two requests, 338 at five and 221 at ten. Pad with instructions or examples you’d actually want in there, because filler changes the model’s behaviour too.\n\n**Cached tokens still eat your rate limit.** A 500K-token read is billed like 50K of plain input, but it takes the full 500K out of your tokens-per-minute allowance. Every refresh does the same, so a warm cache on a big agent is paid for in TPM as well as dollars.\n\n**Configuration updates come with rules.** They only work in standard, single-agent mode, so not with Pro, and the API rejects two updates next to each other. They also can’t be combined with automatic compaction or truncation, and moving or dropping an update in the replayed history changes the prefix just as much as editing a message would.\n\n**Older models play by different rules.** GPT-5.5 and earlier charge nothing for writes, so there’s no 27.8% bet, but the read discount is all over the place: 0.1x on GPT-5.5 and GPT-5.2, 0.25x on GPT-4.1, 0.5x on GPT-4o and no discount at all on GPT-5.5 Pro. Retention is best effort rather than a guaranteed 30 minutes, and hit rates depend on a stable `prompt_cache_key` that the new models don’t need. Those variables make it a little too complex to reliably reason about.\n\n## Where the six-hour rule falls flat\n\nThe rule assumes you’re eventually coming back. A refresh schedule for a session that gets abandoned buys absolutely nothing, and the 27.8% math from earlier is the better tool for that call. It also assumes expiry actually happens. Thirty minutes is a minimum and OpenAI says it may keep entries around for longer, so some of the rewrites the rule is trying to avoid would’ve been plain reads anyway. That pulls the real break-even earlier still, and there’s no real way to plan around it.\n\nI’ve left compaction out on purpose. The formula needs to know how the summary’s tokens are metered, and OpenAI’s [compaction guide](https://developers.openai.com/api/docs/guides/compaction) doesn’t say enough about that to reuse it. The caching guide only warns that compacting changes the prefix, which costs you the exact cache you were trying to save money on.", "url": "https://wpnews.pro/news/tokenomics-the-349-minute-rule-for-gpt-5-6", "canonical_source": "https://skids.dev/blog/openai-cache-tokenomics/", "published_at": "2026-09-27 00:00:00+00:00", "updated_at": "2026-09-27 08:59:44.107113+00:00", "lang": "en", "topics": ["large-language-models", "ai-infrastructure", "ai-tools"], "entities": ["OpenAI", "GPT-5.6", "GPT-6", "GPT-6 Astra", "GPT-6 Sol", "GPT-6 Luna", "GPT-5.6 Sol", "GPT-5.6 Terra"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/tokenomics-the-349-minute-rule-for-gpt-5-6", "markdown": "https://wpnews.pro/news/tokenomics-the-349-minute-rule-for-gpt-5-6.md", "text": "https://wpnews.pro/news/tokenomics-the-349-minute-rule-for-gpt-5-6.txt", "jsonld": "https://wpnews.pro/news/tokenomics-the-349-minute-rule-for-gpt-5-6.jsonld"}}