GPT-5.6 Cost Guide: Prompt Caching 90% Off, Reasoning Effort

GPT-5.6 moves both cost levers at once: cached input drops to 10% of the input rate (5.x discounted 50%), and with reasoning on by default, not sending reasoning_effort billed 1.5x as much as pinning it to none across our 50-call matrix, with identical answers. On the input side you can now pin up to four cache breakpoints explicitly; on the output side the effort knob decides how much thinking you pay for. We measured both levers through the gateway on the day-one models: Sol ($5/$30 per 1M tokens in/out), Terra ($2.50/$15), and Luna ($1/$6), every rate confirmed against the live usage.cost meter.

TL;DR

• Cached input bills at 10% of the input rate, measured $0.10/$0.25/$0.50 per 1M across the tiers; 5.x discounted 50%.
• Breakpoints deliver partial reuse: changing the block after a marker re-billed only 1,210 of 2,431 tokens.
• Prefixes under 1,024 tokens never cache and repeats can miss silently; budget hit rates below 100%.
• Cache writes bill at 1.25x on written tokens; a never-read write costs more than not caching.
• Omitting reasoning_effort billed 1.5x as much as none across a 4-task matrix, identical answers; pin it explicitly.

Measured 2026-07-10 through the Synthorai gateway (OpenAI-compatible chat completions), one day after OpenAI announced the family. All three models are live; the new caching parameters pass through unchanged.

Three tiers, one generation

The naming scheme is new: the number is the generation, and Sol, Terra, and Luna are capability tiers that replace the pro/mini/nano suffixes. All three share a 1M-token context window and 128K max output. Every rate below reconciles exactly against metered usage.cost on known token counts, including the cached column:

Sol is the flagship and the price-parity successor to gpt-5.5: the rate card is identical at $5/$30. Terra and Luna are the scaled-down tiers of the same generation, at half and a fifth of Sol’s price, taking the slots the mini and nano suffixes used to hold. For token counting the three are one model: all returned identical counts on every sample we sent.

How 5.6 caching works, per the docs

GPT caching used to be a single behavior: the API detected repeated prefixes of 1,024+ tokens on its own and billed the cached share at half price. Our provider comparison filed the GPT column under “fully automatic” for exactly that reason. The 5.6 caching guide replaces that with a two-mode design:

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

The rules that matter, condensed from the guide:

• A breakpoint marks the end of a cached prefix, covering that block and everything before it. implicit mode (the default) still auto-places a breakpoint on the latest message; explicit mode caches only what you mark.
• Four cache writes per request, and the implicit auto-breakpoint consumes one of them, so explicit markers get three slots in the default mode and four in explicit mode. Breakpoints from earlier conversation turns are read-only on later requests.
• The 1,024-token floor survives: a marked prefix below it is not cached.
• ttl: "30m" is a guaranteed minimum lifetime, not a cap (“at least 30 minutes… may retain it longer”). It replaces prompt_cache_retention, which is deprecated on 5.6, and that means the old 24h extended-retention option is gone with it.
• prompt_cache_key is how you get reliable matching: the guide recommends a stable key per tenant or session to route repeats to the same cache, with a soft limit around 15 requests per minute per key. Caches are scoped to your organization.
• Cache writes bill at 1.25x the input rate on 5.6+, reported in the new usage.prompt_tokens_details.cache_write_tokens field. Writes were free on 5.x and before.

GPT-5.5 and older reject the new parameters with a clean 400 (prompt_cache_options is not supported on this model), so version-gate any rollout.

If the design sounds familiar, it should: markers on content blocks, four breakpoints, a write premium, and a sliding read-only history are the shape Claude’s cache_control has had all along. The difference is the TTL: OpenAI’s 30-minute guaranteed floor is 6x Claude’s default 5 minutes.

What the meter says

Docs are claims; here is what the gateway’s meter returned, probe by probe. Full raw records are in the run log; every cost below reconciles to the digit against the tier rates.

Three of those rows deserve unpacking.

Partial reuse is real, and it is the reason to adopt breakpoints. With a stable block A and a swapped tail B, the meter re-billed only the tail: 1,212 tokens read back at the cached rate, 1,210 written for the new B at the write premium, out of a 2,431-token prompt, and the total reconciles against the rate card to the digit. That is the layered-prefix behavior (system prompt, then tools, then documents, each marked) that Claude users structure prompts around, and GPT’s automatic mode could never guarantee it. One footnote: on full repeats the matched length sometimes snaps below the mark (1,897 of a 2,422-token write in one probe), so budget on the discount rate, not on exact match counts.

The floor and the silent misses are the operational traps. A 621-token marked block cached nothing, twice, with no error and no usage hint beyond the zeros; if your “stable prefix” is a short system prompt, you are paying full price and nothing tells you. And a miss can arrive without a write, at full price, equally silently. Hit rate is a distribution, not a promise, whatever path your requests take: read cached_tokens in production and alert on it, the way our five-minute cache audit does.

The write premium is real, and it changes the break-even. Written tokens bill at exactly 1.25x the input rate on all three tiers (Luna writes meter at $1.25 per million, Terra at $3.125, Sol at $6.25), reconciling to the digit on every probe in our final run. That premium only pays back once the prefix is read again: a write that never gets a hit costs 25% more than not caching at all, the same trap we measured on Claude’s write premium in the LangChain post. Mark prefixes you know will repeat, not everything that looks stable.

The 30-minute floor held as far as we probed it. A keyed re-read 15 minutes after the write came back fully cached (1,313 of 1,313 tokens, reconciling at the 10% rate), well past the old in-memory horizon of 5 to 10 minutes, and a second keyed probe at the same gap repeated the result. We did not probe the full 30 minutes.

The same workload on GPT-5.5, for contrast

The fair comparison is price-parity: Sol carries gpt-5.5’s exact rate card ($5/$30), so it is the like-for-like successor, with Terra and Luna as the scaled-down tiers below it. Same sticker price, very different caching terms:

At the same sticker price, the caching terms are the upgrade. A 3,000-token prefix costs $0.0075 per call on 5.5 when its automatic cache decides to hit, and $0.0015 on warm Sol, 5x less on the cached share. The deeper change is control and visibility: 5.5’s hits depend on opaque prefix detection you can neither trigger nor debug, while 5.6 lets you mark exactly what should cache, route repeats with a prompt_cache_key, and watch every write land in usage. A miss now shows up as a zero in a field you created, not as silence. The step-down path stacks on top: if 5.5 was over-serving the workload, Terra halves the whole rate card and Luna divides it by five, and the same warm prefix drops to $0.00075 and $0.0003. The one thing 5.5 keeps is the optional 24-hour retention; if your traffic is a daily batch against a giant prefix, that trade-off runs the other way. And note the second lever cuts the other way on migration: 5.6 reasons by default, so a 5.5 workload moved over without pinning reasoning_effort picks up new output spend at the same rate card.

The second lever: reasoning effort

Caching governs what you pay for input; reasoning_effort governs the output side, because reasoning tokens bill at the output rate and, unlike your prefix, can never be cached. GPT-5.6 accepts none through xhigh on all tiers. The launch post also introduces a max effort for Sol; through chat completions it does not exist (400: 'reasoning_effort' does not support 'max' with this model, on Sol and Terra alike), so xhigh is the practical ceiling on the API path gateways and SDKs use.

We ran a 50-call matrix: four task shapes (classify a review, extract a field from a log line, a multi-step arithmetic word problem, a small code-generation task) across all six settings, none to xhigh plus the parameter omitted, on Terra and Luna with a Sol spot check. Every one of the 50 answers was correct at every setting. What varied was the bill. These are short-output calls (tens of visible tokens), so a few dozen reasoning tokens at the output rate dominate the total; the ratio column compares whole-call cost:

Three findings. First, 5.6 is adaptive on its own: on the two trivial shapes no setting spent a single reasoning token, so the knob is free there. Second, on shapes that look like they deserve thought (math, code), the default reasons even when it buys nothing: omitting the parameter cost 2.5x to 3.5x the none price on Luna’s math and code and Terra’s math (Terra’s code run happened to spend nothing at default) for the same correct answers, and 1.5x as much summed across the Terra and Luna grid. Third, the intermediate settings (not shown in the table) are noise, not a dial: Terra’s math run spent 19 reasoning tokens at low, zero at medium, 21 at high, and zero again at xhigh, and Luna’s code run spent 101 at xhigh against 41 at high. The names are intents, not budgets, the same behavior we measured on GLM 5.2.

Send reasoning_effort explicitly on every call, and default it to none for classification, extraction, routing, and short transforms. Escalate a specific call site only when your evals show the higher setting changing outcomes, not because the task feels hard. Our four shapes are short-output API workloads; genuinely hard multi-step work may earn its reasoning spend, but let measurements say so.

The two levers compound. Once a prefix is warm, the input side of a Luna call costs a tenth of list price, and the reasoning default becomes the largest remaining line item on short tasks: Luna’s math call was $0.00007 total at none and $0.00025 with the parameter omitted: the reasoning default alone added $0.00018, more than twice the entire managed call. Cache without pinning effort and the savings leak back out the other side.

What to recommend per workload

The decision now has real structure, so here is what we tell gateway customers:

Independent of shape: send a stable prompt_cache_key per tenant or session (the docs make the key the basis of reliable matching), keep every marked layer above the 1,024-token floor, and monitor cached_tokens because silent misses exist. Remember the caches are per-model: an A/B test across tiers re-warms from zero on each side. And set the other lever in the same commit: pin reasoning_effort per the matrix above, none unless an eval says otherwise.

On tier choice, the 90% discount changes the arithmetic more than the tier does. A workload replaying a 3,000-token prefix pays about $0.30 per thousand calls for that prefix on warm Luna traffic and $1.50 on warm Sol; the spread between tiers on the cached share is smaller than the spread on output tokens, so pick the tier for output quality and price, then let caching flatten the input side. Coming from gpt-5.5, Sol is the drop-in upgrade at the same rate card with 5x cheaper cache reads and control over when they happen; step down to Terra or Luna where your evals say the smaller tier holds, and the rate card halves or divides by five on top.

The tokenizer did not change

Our 24 samples (a narrative passage in nine languages, technical and news versions in six of them, a Python function, and a JSON tool-call) count identically across GPT-5.5, Sol, Terra, and Luna in every comparison that completed. Token budgets and cache-floor estimates calibrated on 5.5 carry over untouched; the cross-language behavior is in our tokenizer-by-language post and applies to 5.6 as-is.

Bottom line

• The cache discount deepening from 50% to 90%, with a 30-minute guaranteed TTL, is the real price cut in this release; the tier prices are the headline, but the caching terms move real bills more.
• Adopt explicit breakpoints for layered prompts: partial reuse is measured, not theoretical, and the mental model transfers from Claude one-to-one.
• Respect the 1,024-token floor, send a prompt_cache_key, and monitor cached_tokens; silent misses and silent not-cached-at-all both exist.
• Send reasoning_effort explicitly, default none: the unmanaged default billed 1.5x as much across our matrix, up to 3.5x on single tasks, for identical answers.
• xhigh is the reachable ceiling (max 400s through chat completions); no tokenizer re-baseline from 5.5.

FAQ

Does GPT-5.6 support explicit prompt caching like Claude? Yes. prompt_cache_options: {"mode": "explicit"} plus prompt_cache_breakpoint markers on content blocks, up to four writes per request (three in implicit mode, where the automatic breakpoint takes a slot). Measured through an OpenAI-compatible gateway, a marked 3,012-token prefix wrote on the first call and read back in full at the cached rate on the second.

What does cached input cost on GPT-5.6? 10% of the input rate, measured on all three tiers: $0.10 per million on Luna, $0.25 on Terra, $0.50 on Sol. GPT-5.x billed cached tokens at 50% of input, so the cached-token rate is 5x lower on 5.6.

Is GPT-5.6 caching better than GPT-5.5’s? On discount depth and control, yes: 10% cached rate versus 50%, four explicit breakpoints versus automatic-only detection you cannot trigger or debug, and a 30-minute keyed floor versus 5-10 minutes best effort. 5.5’s one remaining advantage is the optional 24-hour retention tier, which 5.6 drops.

How long does the GPT-5.6 cache live? The docs guarantee at least 30 minutes (ttl: "30m" is the only accepted value), possibly longer; the option replaces the deprecated prompt_cache_retention, including the old 24-hour extended tier. In our probes keyed re-reads 15 minutes after the write hit in full; we did not probe the full 30.

Do I need prompt_cache_key? Send it: the docs make a stable key per tenant or session the basis of reliable matching on 5.6, with a soft limit around 15 requests per minute per key. It costs nothing to include, and pairing it with cached_tokens monitoring is how you verify the discount is actually landing.

How much does reasoning_effort change GPT-5.6 cost? On our 50-call matrix (four task shapes, six settings, Terra and Luna), every setting produced correct answers, and omitting the parameter billed 1.5x as much as none overall, up to 3.5x on the arithmetic task. On trivial shapes (classification, extraction) no setting spent reasoning tokens at all. Pin none and escalate only on evals.

Is the max reasoning effort available on GPT-5.6 Sol? Not through chat completions. Requests with reasoning_effort: "max" return a 400 listing none through xhigh, on Sol and Terra alike.

Which GPT-5.6 tier should an API workload use? Sol is the price-parity successor to gpt-5.5 (identical $5/$30 rate card, 5x cheaper cached reads); Terra and Luna are the scaled-down tiers at half and a fifth of that. Once your prefix is stable and keyed, the 90% cache discount flattens the input side, so step down as far as your output-quality evals allow and let the tier set the output price.

← Back to blog