On July 30th OpenAI cut the prices of its API. GPT‑5.6 Luna came in at $0.20 per million input tokens and $1.20 per million output — an 80% cut. Terra came in at $2 and $12 — a 20% cut. Sol, the tier above, stayed exactly where it was.
Most coverage stopped at the first number. I think the interesting one is the third.
A discount tells you nothing. An asymmetric discount tells you a lot.
When a provider cuts evenly across the line, you’re looking at a defensive move: someone’s taking their share and the answer is margin. When a provider cuts 80% at the bottom, 20% in the middle, and 0% at the top, you’re looking at three distinct markets that happen to share a brand.
At the bottom, the product is tokens. Luna competes on price per unit of sufficiently good output, and the floor of that competition is whatever the cheapest operator can survive on. An 80% cut is what it costs to stay on the list.
In the middle, the product is a tradeoff. Terra is where you fall when Luna isn’t enough and Sol isn’t justified. A 20% cut moves that line — it makes it cheaper to win the argument of “use the bigger model and call it a day,” and that’s worth more to OpenAI than the margin it gave up.
At the top, the product isn’t tokens. It’s the capability you can’t get anywhere else. Sol didn’t move because nothing’s squeezing it, and OpenAI is telling you that by leaving the number alone. If you’re paying for Sol, you’re not in a price negotiation.
That’s the map. Before you read this as news about OpenAI, look at where your own workloads fall on it — because the tier you’re standing on determines whether this news is a stroke of luck or a rounding error.
Where the margin came from — and why that’s the part with shelf life
Price cuts usually come from somewhere nobody spells out. This one came with an explanation, published the day before, and the explanation is more durable than the prices.
According to OpenAI, they pointed GPT‑5.6 Sol at their own inference stack. Two results:
Production kernels. Sol rewrote and optimized the kernels that execute the model’s mathematical operations — written in Triton and Gluon, the GPU programming languages that OpenAI maintains as open source. The stated effect is a 20% reduction in end-to-end serving cost. OpenAI also says it relies on FpSan, an open source floating-point sanitizer, to validate the correctness of the kernels the model writes.
Speculative decoding. Sol redesigned its own draft model — the small model that proposes tokens the big one verifies — running hundreds of experiments on size, structure and features, then launching and monitoring the speculator’s training, stepping in on hardware failures and training instability. Stated effect: more than 15% improvement in token generation efficiency.
Read those two things together and the price announcement becomes a footnote to another story. This is a company saying its model improved its own serving economics enough to finance an 80% price cut, and showing you which two levers it moved.
Honest caveats: all figures are self-reported. OpenAI doesn’t disclose the GPU model, the baseline configuration, the speculator’s acceptance rates, or anything about the experimental setup. The only third-party number in the announcement is the Artificial Analysis Coding Agent Index, which measures capability, not serving cost. Nobody outside OpenAI verified either the 20% or the 15%.
But you don’t need to verify the percentages to take the mechanism seriously — and the two levers are things you can inspect. Triton, Gluon and FpSan are public. What OpenAI applied at frontier scale is the same technique available to anyone serving models: kernels tuned to your actual workload instead of the general case, and a draft model shaped like your actual traffic instead of the one that came with the framework. The scale is theirs. The technique isn’t.
Fast mode: latency becomes a separate line item
The third change got the least attention and might be the one that touches your architecture.
Fast mode replaces Priority Processing in the API: up to 2.5× faster than Standard at double the price, with no change in intelligence. Existing requests with the priority tag keep working.
Watch what’s being sold there. Not a better model — the same model as before. That’s a price axis that separates latency from capability, and it makes explicit a question most teams answer by accident today: which of your calls are really latency-sensitive?
If you were going to a bigger model to make an interaction feel responsive, you were paying for capability to buy speed. Fast mode puts an honest price on that. In many stacks the right answer now is a smaller model in Fast mode instead of a bigger one in Standard — and the only way to know is to look at your own p95, endpoint by endpoint, instead of guessing.
What I’d do this week
Three things, in order:
- Redo your routing math. Anywhere you ruled out Luna for quality and stayed on Terra deserves a second look — the cost gap between the two changed by a factor that invalidates any spreadsheet that justified that decision.
- Separate your latency-sensitive calls from your capability-sensitive ones. They’re not the same set, and until Fast mode existed there was no reason to keep the list.
- Don’t build on the price. Build on the tier. The number that moved 80% is going to move again; the structure — commodity floor, disputed middle, undisputed ceiling — is what you’re really designing around.
Luna at $0.20 is the headline. Sol unchanged is the market telling you where the leverage is, and it’s not at the bottom.
Did you redo your model routing after this cut, or are you still running the old numbers? I’m curious what tier your workloads ended up falling into.
https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/