필사 모드: GPT-5.6 and the Limits of Price-Performance — How to Find Your Workload's Place on the Curve

• Introduction — What an 80% Cut Three Weeks After Launch Tells You
• What Changed Between July 9 and July 30
• The Slope of the Curve — And a Vendor Efficiency Claim
• Compute From the Mix, Not the Headline Price — Except This Time the Mix Does Not Change Anything
• Where Caching Moves the Curve, and Where It Cannot
• Fast Mode — Latency Now Has Its Own Price Sheet
• What the Benchmarks Do Not Capture
• Closing — The Curve Keeps Falling, but Only You Can Measure Where You Sit on It

Introduction — What an 80% Cut Three Weeks After Launch Tells You

On July 30, 2026, OpenAI cut the price of GPT-5.6 Luna by 80%. It went from $1 input and $6 output per 1M tokens to $0.20 input and $1.20 output. The middle tier, Terra, came down 20% to $2 input and $12 output, and the top tier, Sol, stays at $5 input and $30 output. The GPT-5.6 family went generally available on July 9, so this is an adjustment three weeks in.

A second item announced the same day makes the character of the move clearer. The existing Priority processing was renamed Fast mode, and for Sol only it offers up to 2.5x the standard speed at twice the standard price. OpenAI's API docs describe it as speed only, with no change in intelligence. In other words, the lower tiers cut price to defend volume, while the upper tier has begun selling latency as a separate product.

There is one number frequently cited as background. Several outlets citing CNBC reporting said that Chinese models took 46% of US enterprise token usage on OpenRouter. I could not verify how that figure was originally compiled, so I treat it strictly as a reported claim. That said, the asymmetry of the cut (80% at the bottom, 0% at the top) hardly needs an explanation of what it is aimed at.

The subject of this post is not the news of a price cut. Cost per capability has been falling along a curve for years, and any individual cut is one point on that curve. There is only one useful question — where on that curve does my workload sit, and did this move actually shift its position?

What Changed Between July 9 and July 30

Putting the metrics Artificial Analysis compiled at launch into one table alongside this cut gives the following. The post-cut values for cost per index task are numbers I computed by applying the announced cut rates directly, assuming identical token consumption.

On the same index, Claude Fable 5 scores 60 at maximum effort. So Artificial Analysis's summary at launch was that Sol trails by one point on composite intelligence while costing about a third as much to finish the index.

Reading the table vertically is more interesting. The intelligence index steps down 59, 55, 51 — four points at a time — while cost per index task drops 1.04, 0.44, 0.042, an order of magnitude at a time. What it costs to buy four points of intelligence index differs tenfold from band to band. This is why the word curve is the right one. At the top end, a tiny amount of capability costs an enormous amount of money; at the bottom, the same money buys far more capability.

The Slope of the Curve — And a Vendor Efficiency Claim

Citations about how fast cost per capability is falling are everywhere, but most of them have murky sources. The version cited relatively often is that, holding a given benchmark level fixed, the price of that performance has been falling by a single-digit to tenfold factor per year. This cut is one point on that trend line, and only the three-week interval is unusual; the direction itself is not new.

One vendor claim here is worth checking. At the GPT-5.6 launch, OpenAI said in effect that token efficiency had improved 54% on certain tasks, and several outlets carried it. That is a vendor claim with the qualifier "certain tasks" attached. The independent aggregation, by contrast, is far more modest — by Artificial Analysis's count, Sol used 15,000 output tokens to complete one index task, about 6% fewer than the 16,000 of the previous generation, GPT-5.5.

The two numbers do not contradict each other. The 54% came from selected tasks and the 6% from the composite index as a whole. But the one you can put into a practical plan is the latter. When a vendor attaches "on certain tasks," that qualifier is itself a do-not-generalize sign. Token consumption on your own tasks has to be measured directly, and that measurement is exactly what must happen before any model swap.

Compute From the Mix, Not the Headline Price — Except This Time the Mix Does Not Change Anything

The usual first trap when comparing two models is looking only at the input price. Because the output-to-input multiple differs by vendor, the cost ranking of the very same two models flips depending on the workload's token mix.

But this cut eliminated that trap inside the GPT-5.6 family. Line up the three tiers' post-cut prices and input is 5, 2, 0.20 while output is 30, 12, 1.20. Both axes are exactly 25 to 10 to 1.

Sol   : input 5    output 30      -> 25x Luna
Terra : input 2    output 12      -> 10x Luna
Luna  : input 0.20 output 1.20    -> baseline

Whatever (input tokens, output tokens) pair you plug in, the total ratio stays fixed at 25 : 10 : 1.
The mix gives you no information at all about which tier to pick.

If the mix cannot change the ranking within the family, tier selection has to be decided on a different axis. That axis is the cost of being wrong. Let us compute it on a real workload.

Workload — classifying 1,000,000 product descriptions
  4,000 input tokens / 300 output tokens per request

  Luna  : (4,000 x 0.20 + 300 x 1.20) / 1e6 = 0.00116 dollars/item -> 1,160 dollars
  Terra : 10x the above                                            -> 11,600 dollars
  Sol   : 25x the above                                            -> 29,000 dollars

  Now add c, the per-item cost of a human fixing a wrong answer.
  Assume a 4% error rate for Luna and 2% for Terra:

  Luna  total =  1,160 + 0.04 x 1e6 x c
  Terra total = 11,600 + 0.02 x 1e6 x c

  The point where the two are equal:
  10,440 = 0.02 x 1e6 x c   ->   c = 0.522 dollars

Here is how to read it. If fixing one wrong answer costs less than $0.52, Luna wins; if it costs more, Terra wins. If the task takes a human one minute per item, labor cost is already far past $0.52. Conversely, in a pipeline where a wrong answer is resolved by a simple retry, the retry costs $0.00116 and Luna wins overwhelmingly.

The lesson from this calculation is simple. The regime where a 10x difference in token price shows up as a difference in total cost is only the regime where the cost of being wrong is the same order of magnitude as the token cost. In most in-house workflows the cost of being wrong is two or three orders of magnitude larger than the token cost. Spending hours comparing price sheets on that kind of workload is optimizing on the wrong axis.

Where Caching Moves the Curve, and Where It Cannot

The GPT-5.6 family's cache policy is a 90% read discount, a write at 1.25x the input price, and a 30-minute minimum retention. Let us compute the case of a 40,000-token fixed prefix on Terra.

40,000-token prefix, Terra input 2 dollars per 1M

  no cache         : 40,000 x 2.00 / 1e6 = 0.080 dollars (every call)
  cache write (1x) : 40,000 x 2.50 / 1e6 = 0.100 dollars
  cache read       : 40,000 x 0.20 / 1e6 = 0.008 dollars

  Break-even over N calls:
  0.100 + (N-1) x 0.008  <=  N x 0.080
  0.092 <= 0.072 N   ->   N >= 1.28   ->  pays off from the second call on

Break-even is the second call. The real constraint is not the break-even point but the 30 minutes. If the same prefix does not come back within 30 minutes, you pay the write premium and collect nothing. So what decides whether caching actually works is not the discount rate but request density per prefix. In a service where 10,000 users each call twice a day with a different prefix, caching increases your cost.

And it bears repeating that a discount rate is not a savings rate. In the workload above, the 300 output tokens cost $0.0036, so input is 95% of the total. With the cache fully warm, per-item cost falls from $0.0836 to $0.0116, a 86% cut. In an output-heavy workload (2,000 input / 10,000 output), by contrast, input is only 3% of the total, so the same 90% discount cannot take even 3% off the total. The same policy splits into 86% and 3% depending on the workload. The general form of this calculation is followed through provider by provider in How to Actually Cut Your LLM API Bill.

Fast Mode — Latency Now Has Its Own Price Sheet

Fast mode is worth looking at separately because it signals that an axis orthogonal to model selection now exists. Per the API docs, you put fast (or priority, kept for backward compatibility) in the service_tier parameter, and the current target is gpt-5.6-sol. Long context, fine-tuned models, and embeddings are excluded. The docs say it is up to 2.5x faster than standard with more consistent latency, and they do not state the multiplier, deferring to the pricing page. Per the announcement materials, the premium is twice the standard price.

The arithmetic is simple. You pay 2x for 2.5x speed, so it only pays off when one second of latency is worth more than half the token cost of that request. For an interactive path where a user is waiting in front of a screen this generally holds; for an overnight batch or a pipeline that piles work into a queue it never does. If you make that distinction not at the code level but as a project-wide setting, your batch traffic pays 2x as well. Confirm that the docs offer both per-request and per-project settings, and it is safer to leave the default at standard.

The phrase about no change in intelligence is also fair to take at face value. What that sentence guarantees, though, is that the model weights are the same — not what tail latency does under load. If you are buying this option because you need consistent latency, measure p99, not the average.

What the Benchmarks Do Not Capture

Finally, let me lay out what the numbers in this post cannot cover. Start with the fact that rankings flip from benchmark to benchmark. In the published aggregations, on SWE-Bench Pro Sol is 64.6% and Terra is 63.4% while Claude Fable 5 leads at 80.0%. On Terminal-Bench 2.1, by contrast, Sol is at the top at 88.8% (91.9% in ultra mode), and on Agents' Last Exam it is reported at 53.6, ahead of Fable 5 by 13.1 points. Three benchmarks produce three rankings. The attempt to extract "who is number one" from this is itself the wrong question.

And there are items that no benchmark measures at all.

• Instruction adherence over a long session. Most benchmarks are one-shot tasks, while a real service is a session of dozens of turns. Whether it forgets a system-prompt constraint on turn 20 does not enter the index.
• Reliability of tool-call schemas. The rate at which a model fills a schema incorrectly determines the real failure rate of an agent pipeline, but an aggregate score reflects it only as success or failure.
• Refusal rates and over-safety in my domain. The rate at which legitimate requests are refused in medical, financial, and security domains is not published by vendors and not measured by benchmarks.
• Tail latency and rate limits. Average response speed is available everywhere, but p99 and the 429 rate under a traffic surge can only be learned by measuring them yourself.
• The gap between measurement conditions and your real settings. Every index score in the table above was measured at maximum reasoning effort. Not much production traffic runs at that effort, and the score curve at lower effort is not published.

Closing — The Curve Keeps Falling, but Only You Can Measure Where You Sit on It

Over the past three weeks, the prices of GPT-5.6's lower two tiers came down 80% and 20%, and the top tier stayed put while its speed started being sold separately. The price curve will keep going down, and each time there will be news of a cut. But the three numbers computed in this post survive independent of any cut.

First, after the cut the three tiers' unit prices are pinned at 25 to 10 to 1 on both axes, so within the family the token mix gives you no information about tier selection. Second, the actual decision is therefore set by the cost of fixing one wrong answer, and in the example workload that break-even was about $0.52 per item. Third, caching cuts 86% on a workload where input dominates the invoice but cannot cut even 3% on an output-heavy one.

No vendor can do any of these three calculations for you. The inputs you need are three numbers sitting in your own logs — the median input and output tokens per request, the within-30-minutes reuse rate per prefix, and the real cost of handling a single wrong answer. When the next price-cut announcement arrives, the thing to read is not the headline but the table with those three numbers plugged back in.