# GPT-5.6: What Actually Changed on Your Bill > Source: > Published: 2026-07-12 13:49:09+00:00 *Read the diff, not the demo. Field notes on the GPT-5.5 to 5.6 migration, where the flagship price held but a few things that used to be free now cost money and several defaults moved underfoot.* **The short version** When a model announcement leads with a benchmark chart, the document worth reading is usually the other one: the pricing table and the migration section of the model guide. The benchmark chart is written for the demo. The pricing table is written for your bill. They rarely tell the same story, and on the GPT-5.5 to 5.6 transition they tell almost opposite ones. The demo story is that 5.6 is smarter and more token-efficient. True, and pleasant. The story that will actually show up in your monthly invoice is that a thing which used to be free is now a line item, several defaults quietly changed behavior, and the levers that decide your cost moved without moving the headline price at all. None of that is in the launch post. It is in the fine print, which is exactly where a platform owner should be reading. These are field notes for people who run this in production at some volume and care about where the cost actually goes, not just whether the model is better. The change most important to understand and the change most expensive to pay are rarely the same change. Keeping them apart is most of cost governance. GPT-5.6 ships as three named models: sol, terra, and luna. Resist the urge to treat this as novel architecture. It is the same flagship, mid, small size split the industry has always shipped, previously spelled with mini and nano suffixes, now spelled with words. sol is the flagship, and the gpt-5.6 alias routes to it. At standard rates sol costs exactly what 5.5 costs: five dollars per million input tokens, thirty per million output. The flagship did not get cheaper. What changed is underneath. Start with the change that breaks an assumption, because it is the one your code and your cost model both get wrong. On 5.5 and 5.4 the cache-writes column in the pricing table is blank. On every 5.6 row it has a number, and it appears in no headline. That is the pattern to notice on a mature release: capability is marketed, economics is disclosed. Read the pricing table column by column and the migration paragraph in the model guidance, which is where the real release notes live. Here is what that column means. On 5.5 and earlier, writing content into the prompt cache was free. You paid full input rate to process a prompt the first time, and any prefix that got cached cost nothing extra to store. Cache reads were, and still are, discounted about ninety percent. Caching was therefore free money: it could only ever help. On 5.6, a cache write is billed at 1.25 times the uncached input rate. Reads stay at roughly ten percent of input. So the arithmetic of caching changed from “always good” to “a bet that pays off from the second reuse.” The break-even is worth internalizing, because it reframes a decision your code has been making implicitly. For a prefix of P tokens, express cost in units of P times the input rate: ``` 5.6, cached path: 1.25 (first pass, the write) + 0.10 x (N - 1) (later reads)No-cache baseline: 1.00 x N php Caching wins when: 1.25 + 0.10(N - 1) < N -> N > ~1.28 ``` Translation: from the second reuse onward, caching still wins comfortably. But a prefix that gets written and never read again costs you twenty-five percent more than if you had never cached it. On 5.5 that outcome was impossible, because the write was free. Now think about which workloads churn prefixes and never reuse them: agents whose context is rebuilt every step, retrieval pipelines that splice fresh documents into the front of the prompt, anything with a volatile prefix. Those are precisely the systems most likely to trip the penalty, and precisely the systems most likely to have a caching layer someone turned on once and forgot. A common example: a retrieval endpoint that reassembles its prefix on every call. On 5.5 that was merely a missed optimization. On 5.6 it is a surcharge. Now the magnitude, because how important a change is and how much it costs are different questions, and a cost review that merges them lands in the wrong place. The write premium is 0.25 times the uncached rate, charged only on tokens actually written, only on a miss, only on the first pass. What it costs depends on write volume, and write volume is exactly the thing your current telemetry does not show you. Take a hypothetical heavy-caching service where 45 percent of input tokens are served as cache reads. The tempting read is that 45 percent of input is now exposed to a repricing. It is not, and the reason is the trap worth naming. That 45 percent counts reads, the repeated hits on prefixes that were reused. It says nothing about writes, because a write is a cache miss, and on 5.5 a miss that populated the cache was billed as ordinary input and surfaced as nothing special. The prefixes that were written once and never read again, the exact population the 1.25x rate punishes hardest, produced zero reads and cost zero to write, so they appear in neither the 45 percent nor anywhere else. On 5.5, free and invisible were the same thing. On 5.6 they stop being either, and you find out how many of them you had. So the quantity that sets your exposure, written tokens, cannot be recovered from the read side. Writes equal your reads divided by R, the average reads per write, and you do not have R until you measure writes directly. What you can do before then is bound the range. Holding reads at that hypothetical 45 percent and sweeping across plausible write volumes: ``` Reads-per-write R (currently unmeasured) Write premium, share of input spend 10x (heavy reuse) ~2% 5x ~4% 3x ~6% 1x (little reuse) ~19% ``` At heavy reuse the change is a low-single-digit tax on the input half of the bill, smaller still against the total once output is counted. As reuse falls it climbs, and it passes the bottom of that table entirely when one-time writes outnumber reused ones, which drives R below 1. The model does not decide where you land. Configuration does: a TTL short enough that entries expire before they are reused, prefixes volatile enough to be rewritten every call, or per-prefix concurrency high enough that requests overflow to machines without the cache and rewrite it. Each of those manufactures writes with no matching reads, and each was free on 5.5, which is why no one has been watching them. Two operational consequences follow. First, stop reporting cache hit rate alone and start reporting cache_write_tokens, which 5.6 surfaces for the first time. It is the measurement 5.5 never gave you: the write side that was free and therefore never counted. Divided into your read tokens it gives you R, and R is the number that sets your exposure. The read percentage does not close the gap, because it lives entirely on the other side of the equation. Until you have the write count, you are guessing. Second, understand why explicit caching exists. 5.6 introduces prompt_cache_options with an explicit mode and cache breakpoints, replacing the old retention flag. OpenAI did not add manual control for elegance. They added it because implicit caching now has a downside, and the escape hatch is to mark only the prefixes you know will be reused and let the volatile ones pass through uncached. There is a design consequence beyond the tactics. If you front OpenAI with a shared gateway that caches on everyone’s behalf, cache policy has just become a cost-control surface, and one global default is the wrong shape for it. A stable system prompt reused across millions of calls and a per-request retrieval prefix that is never seen twice want opposite policies, and only the calling service knows which it is sending. The write cost pushes that decision down to the route that owns the prefix, or forces the gateway to carry per-route policy. Either way, “cache everything by default” stopped being free and became an architectural choice with an invoice attached. The mental model “caching is free money” no longer holds. Caching is now a position you take, and like any position it can be wrong. Most teams do not set most parameters. They inherit defaults. Which means the defaults are the actual interface your bill runs through, and a version bump that changes a default is a silent production change with no code diff to review. Three defaults deserve attention on this bump. Reasoning effort still defaults to medium, which is fine, but 5.6 adds a new max level above xhigh, so there is now more headroom to accidentally spend. Implicit caching is still on by default, which is now a cost decision rather than a free one, per the note above. And the quiet one: image detail. On 5.6, original and auto detail no longer resize images down to a patch budget the way earlier models did. Same code, same image, larger input-token count, because the default rendering behavior changed underneath you. A service that passes user-uploaded images through with default detail will see its input tokens rise on large images with zero code change and no error. The discipline this calls for is dull and worth enforcing: audit defaults on every model bump. Diff the parameter behavior, not just the parameter names. A changed default is a deploy you did not review. Reasoning tokens are billed as output, which on the flagship costs six times the input rate. They are invisible in the response, they occupy the context window, and depending on the task they range from a few hundred to tens of thousands. This makes reasoning effort, not model tier, the dominant cost lever for most reasoning workloads. High effort can roughly double token consumption versus low for the same task, and you pay for all of it whether or not it improved the answer. 5.6 hands you two orthogonal dials that both spend on this expensive side. Reasoning effort now runs none, low, medium, high, xhigh, and max. Reasoning mode adds a separate standard-versus-pro switch, where pro does more model work for more tokens, billed at standard rates and independent of the effort setting. You can stack pro and max, and the token bill compounds accordingly. There is a genuine countervailing force here, and it is the real generational win: 5.6 is tuned to reach comparable quality with fewer output tokens. That efficiency shows up on the output side, which is where the money is, so it is a more meaningful improvement than the unchanged headline price suggests. But it is a reason to re-tune effort downward on migration and measure, not a reason to leave everything at the settings you inherited from 5.5. The standard advice, which happens to be correct, is to carry over your current effort as a baseline and test one level lower. The stateful conveniences read as free and are not. Chaining a conversation with previous_response_id feels like the platform is holding your context for you at no charge. It is holding it, and it is billing every prior input token as input on every subsequent turn. History is a cost that compounds with turn count, and the convenience API does nothing to change that; it only hides the accounting. 5.6's persisted reasoning, via reasoning.context set to all-turns, is the same shape of tradeoff: carrying reasoning forward can improve multi-turn quality and cache efficiency, and it adds input tokens to do so. The mitigation that exists for this is compaction, which compresses the running context into an encrypted item that carries forward the state you need in fewer tokens. The point for a platform owner is architectural, not tactical: in any long-running or agentic loop, context growth is the cost curve, and you need an explicit strategy for bending it. Treating context as something the API manages for free is how a chat feature ships fine in testing and becomes the top line on the bill in production. For budgeting continuity this is the reassuring part. 5.5 and 5.6 both use the o200k-family encoding, so identical text produces identical token counts and your input-side estimates carry over unchanged across the migration. One honest caveat here: OpenAI does not publish a separate tokenizer specification per 5.x model. “Identical counts” is a well-supported inference, drawn from tiktoken and third-party counters mapping the whole GPT-5 line to o200k, rather than an explicit vendor statement that 5.5 and 5.6 share an encoder. It is very likely true. It is still an inference, and I mark it as one. For numbers you will put in a contract or a capacity plan, use the API token-counting endpoint rather than local tiktoken, which can lag new model IDs and does not capture per-message and tool-schema overhead. While I am on counting: if you forecast multi-vendor spend by running everything through one tokenizer, your estimate drifts by double digits on code and non-English text, where the encoders diverge most. English prose is the forgiving case that lulls people into the single-tokenizer habit. Do not generalize from it. This is the pattern worth carrying past this release. As a model line matures, the generation-over-generation capability delta shrinks and the economic and operational delta grows. The 4-to-5 jumps were capability events. The 5.5-to-5.6 jump is a cost-and-defaults event with a modest efficiency dividend attached. That is not a criticism of the release. It is what maturation looks like, and it changes what your organization needs to be good at. The muscle that pays off is no longer another round of prompt tuning. It is cost governance: per-endpoint cost audits before rollout, deliberate tier routing so cheap traffic runs on the small tier and only the hard cases escalate, cache instrumentation that tracks writes and not just hits, and a standing habit of diffing defaults on every bump. The engineers who compound value here are the ones who know these levers cold, the way a database team knows query plans and cache invalidation. A good test of that fluency is whether someone can explain, without notes, where the money goes in a multi-step agent loop. It is a sharper signal than benchmark familiarity, and a rarer one. There is a planning consequence as well. A cost that was structurally zero is now a variable in your unit economics, and it moves with configuration rather than cleanly with volume, which is the awkward kind of variable to forecast. If you are negotiating committed throughput or volume discounts, the cache-write line is new surface area in that conversation. Any budget built on the 5.5 assumption that writes were free is now wrong in a direction that scales with your caching ratio, which means the teams that cache the most, usually the ones who optimized hardest, inherit the largest correction. Optimize in the order the launch coverage suggests and you will spend a week on the newest feature and miss the biggest number. Rank by magnitude, not novelty. The distinction that matters for this migration: the biggest lever overall is tier and reasoning, but the biggest new delta from 5.6, the one thing you were not already managing on 5.5, is the cache-write cost. Govern the biggest lever, and act first on the newest exposure. Condensed, because a playbook that does not fit on one screen does not get followed. Pick the size tier by workload, not habit: sol for the hardest reasoning and coding, terra for near-flagship quality at roughly half the price, luna for high-volume and latency-sensitive traffic. Re-tune reasoning effort down from your 5.5 baseline and measure, because 5.6 often holds quality with fewer tokens. Turn on cache_write_tokens tracking today, and move volatile or low-reuse prefixes to explicit caching so you stop paying the write premium on prefixes you never reuse. Audit image detail on any endpoint that passes images with default settings, and pre-resize or set detail explicitly. In multi-turn and agentic paths, put an explicit context-growth strategy in place and enable compaction before the loop gets long, not after the invoice arrives. Confirm token counts against the API endpoint. And before you migrate a single production route, run its real prompts through a cost model with the cache-write column populated, because on 5.5 that column was zero and your old spreadsheet is now wrong. Field notes are only useful if the facts underneath them hold, so I verified each load-bearing claim against OpenAI’s own documentation: the pricing page, the model pages, the model-guidance and reasoning and prompt-caching and images-vision and compaction guides. The pricing, the 1.25-times cache-write cost, the default and maximum reasoning behavior, the image-detail change, the long-context surcharge above 272K tokens, and the convenience-API billing are all grounded there. Two claims are honest inference rather than verbatim vendor statements, and I said so where they appear: the tokenizer identity between 5.5 and 5.6, and the roughly 1.05M context-window figure, which comes from secondary trackers rather than the model-page text I could retrieve. Confirm both against the live model page before you build on them. Distinguishing what you verified from what you inferred is not pedantry. It is the difference between a field note and a rumor. The maturation of a model line looks like the maturation of any piece of infrastructure. Early on, the capability is the story and you will forgive almost anything to get it. Later, the price stabilizes, the semantics get subtle, and the teams that do best treat each release as a migration with a cost diff rather than a capability announcement to celebrate. GPT-5.6 is squarely in that later phase. The flagship price held and the efficiency improved. What moves your bill is still what always moved it, tier and reasoning effort, now joined by three things to watch: a cost on something that used to be free, a set of defaults that shifted underfoot, and two fresh ways to spend on invisible tokens. Read the diff, not the demo. The demo is for the launch. The diff is for the people who have to run the thing. Primary sources verified for this piece. OpenAI moves documentation paths periodically, so confirm against the live version before you build on any figure. [GPT-5.6: What Actually Changed on Your Bill](https://pub.towardsai.net/gpt-5-6-what-actually-changed-on-your-bill-bcafcbd646c5) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.