What changed
- Luna fell 80%. From $1 / $6 to $0.20 / $1.20 per million input and output tokens. In both directions, a fifth of what it cost the day before.
- Terra fell 20%. From $2.50 / $15 to $2 / $12 per million tokens. A real reduction, but a modest one next to Luna's.
- Sol did not move. The flagship stays at $5 / $30 per million tokens. No cut, no restructuring, no introductory window.
- The timing is unusually tight. The GPT-5.6 family reached general availability on 9 July 2026. The cut landed roughly three weeks later, on a lineup that had barely settled into production stacks.
- The stated reason is efficiency. OpenAI attributed the reductions to improvements in its models, inference infrastructure, production software and context-management systems — a supply-side explanation for a change that is also, plainly, a competitive one.
The tiering itself is not new. Sol, Terra and Luna have carried the same nominal roles since the family reached general availability earlier this month: a frontier model, a workhorse, and a small fast model for the volume work. What changed on 30 July is the distance between them. Before the cut, moving a workload from Sol down to Luna saved you a factor of five on input. After it, the same move saves you a factor of twenty-five.
That is not an incremental adjustment to a rate card. It is a large enough gap that the arithmetic on several categories of workload — classification, extraction, routing, summarisation of things nobody will read closely, first-pass drafting behind a human review step — now comes out differently than it did last week. If your team last audited its model routing when the family went GA, the audit is already stale.
The ratio that matters
Headline percentages are a poor way to reason about API pricing, because a percentage cut on a small number is still a small number, and a percentage cut on a large number can still leave you with a bill you cannot defend. The useful frame is the ratio between the tiers you might actually route between, and the absolute cost of a million tokens in each direction.
| Model | Input / million tokens | Output / million tokens | 1M in + 1M out | Input as % of Sol |
|---|---|---|---|---|
| GPT-5.6 Sol (unchanged) | $5.00 | $30.00 | $35.00 | 100% |
| GPT-5.6 Terra (was $2.50 / $15) | $2.00 | $12.00 | $14.00 | 40% |
| GPT-5.6 Luna (was $1 / $6) | $0.20 | $1.20 | $1.40 | 4% |
| Gemini 3.6 Flash (launched 22 July 2026) | $1.50 | $7.50 | $9.00 | 30% |
| Claude Sonnet 5 (introductory, to 31 Aug 2026) | $2.00 | Not compared here | Not compared here | 40% |
Read down the fourth column and the shape of the market becomes legible. A million tokens in each direction costs $35 on the flagship and $1.40 on Luna. Terra sits at $14, which is now seven times Luna's input price and ten times its output price — the middle tier has quietly become the expensive option for anything that does not strictly need it. Google's Gemini 3.6 Flash, launched on 22 July 2026 at $1.50 / $7.50 with built-in Computer Use, is a capable small model at a price that looked aggressive nine days ago and now sits well above Luna on raw tokens. Claude Sonnet 5, which launched on 1 July 2026 at $2 per million input tokens, is running introductory pricing through 31 August 2026 — a date worth putting in your calendar rather than your assumptions.
Compare on cost per completed task, not cost per million tokens. A cheaper model that needs two attempts, a longer prompt, or a repair pass from a stronger tier is not cheaper. We worked through that arithmetic in detail when the earlier Flash tier landed — the method in that cost-per-task breakdown transfers directly to this comparison.
Why the flat flagship is the real signal
If this were purely a cost pass-through — inference genuinely got cheaper, so prices fell — you would expect the saving to show up across the range. Serving efficiencies in inference infrastructure, context management and production software are not tier-specific in any obvious way. Yet Luna fell 80%, Terra fell 20%, and Sol fell not at all.
The likeliest reading is that two different things are being priced. At the frontier, buyers are relatively insensitive to price because the work they are doing cannot be done at all by the cheaper tiers; that is where margin is defended. At the cheap end, the model is close to a commodity, the switching cost is a configuration change, and pressure is arriving from several directions at once — cost-conscious enterprise buyers running high-volume workloads, Chinese labs pricing aggressively, and other large technology firms with their own inference estates to fill.
None of that is a criticism. It is simply the structure a builder should hold in mind when planning: expect the low tier to keep getting cheaper and expect the flagship to hold its line. Budget accordingly. If your architecture assumes the flagship will drift down towards the cheap tier over the next few quarters, you are planning against the observable trend rather than with it.
There is a second-order point here that shows up on any infrastructure invoice. Analysts estimate that somewhere between 55% and 80% of enterprise AI GPU spend now goes to inference rather than training — a wide range, and one worth treating as directional rather than precise. But the direction is unambiguous: the recurring cost of running models has overtaken the one-off cost of building them, which is exactly why per-token prices are now a competitive battleground rather than a footnote. We unpacked how that shift reshapes budgets in our look at the economics of inference at scale.
Re-running your routing decision
The temptation after a cut like this is to change one line in a config file, point everything at the cheap tier, and enjoy the invoice. Resist it. A routing change is a change to the behaviour of your product, and it deserves the same care as a change to your prompt or your retrieval layer.
Start with the escalation ladder, not the swap
The pattern that survives contact with production is not "use the cheap model" but "try the cheap model first, and escalate when it fails a check you can actually run". The ladder looks like this: send the request to Luna; validate the output against something deterministic — a schema, a required field, a regular expression, a confidence signal, a rule about length or format; if the validation fails, retry once at Terra; if it fails again, send it to Sol. Log which rung each request finished on.
The economics of a ladder are far better than a straight swap, because the expensive tier is only invoked on the small fraction of requests that need it, and you keep a hard quality floor. The failure rate on the first rung also becomes a live metric: if escalations to Sol start climbing, something upstream has changed and you find out from a dashboard rather than from a customer. This is the same discipline as caching and prompt compression, and it composes with both — the cache, route, compress sequence is still the order to work in.
Put an eval gate in front of the change
Before you shift a single percent of live traffic, you need a set of examples drawn from real production requests, with known-good outputs, that you can run against both the current tier and the candidate. Fifty to two hundred cases is usually enough to see a meaningful difference in pass rate; the point is not statistical elegance but catching the obvious regressions before your users do.
Run the set against both models. Compare not just the pass rate but the shape of the failures. A cheap tier that fails on 4% of cases in a way your validator catches is a different proposition from one that fails on 2% of cases silently and plausibly. If your evaluation set does not exist yet, build it before you change the routing, not after — and put it in continuous integration so the next price cut is a one-hour decision rather than a one-week project. The practical mechanics are in our guide to running evals in CI.
The dangerous outcome of a routing change is not an outage. It is a quiet quality regression: outputs that still parse, still return, still look fine in a spot check, and are subtly worse in ways that only show up in support tickets, churn, or a manual review three weeks later. Ship routing changes behind a percentage rollout with a quality metric attached, and give it at least one full weekly traffic cycle before you move the rest.
Know which workloads should not move
Some categories move down a tier comfortably: classification, tagging, entity extraction against a schema, deduplication, routing decisions, retrieval reranking, first-pass drafts that a human or a stronger model will review, and any bulk transformation where a validator can check the result. Others should stay where they are: multi-step agentic loops where an early error compounds, anything with a regulatory or financial consequence, tasks where the output goes straight to a customer without review, and long-context reasoning where the model has to hold several constraints at once.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →What this looks like on an Indian or UK budget
For a team in Bengaluru or Pune running a rupee-denominated infrastructure budget, an 80% cut on the tier that handles the bulk of request volume is not a rounding adjustment — it is the difference between an AI feature that has to justify itself every quarter and one that disappears into general cloud spend. The same is true for a London or Manchester team working to a pound-denominated cost line, with the added wrinkle that both are paying in dollars and carrying the currency movement on top of the rate card.
That currency exposure is a reason to think in ratios rather than absolute figures when you plan. A cut of this size gives you headroom against exchange-rate drift as well as against volume growth, and it is worth deciding explicitly which of the two you are spending the saving on. Teams that treat a price cut as free budget for more calls tend to end up back where they started within two quarters, only with a more complex system.
There is a second, less obvious benefit for smaller teams on both sides. Workloads that were previously uneconomic — running an evaluation suite on every pull request, scoring an entire back catalogue of support tickets, generating structured metadata across a large document corpus, backfilling classifications on historical data — become affordable at a fifth of the previous price. If you keep a list of "things we would do if inference were cheaper", this is the week to reopen it.
Instrument spend per feature before you re-route, not after. If you cannot say which product surface is generating which share of your token bill, a price cut will not make your costs legible — it will just make them smaller and equally opaque. The tagging and caching patterns in our prompt caching and model routing guide are the cheapest place to start.
The caveats, stated plainly
Three things are worth holding onto as you plan around this.
The quality figure is the vendor's own. Luna is reported to offer approximately 85% of Sol's quality. That number should be read as a company-stated summary rather than an independent benchmark result, and even taken at face value, a single aggregate percentage tells you almost nothing about how a model behaves on your particular task distribution. A model can score well on average and fail systematically on the exact narrow thing your product depends on. The only figure that matters for your decision is the one your own evaluation set produces.
Introductory pricing expires. Claude Sonnet 5's $2 per million input tokens runs through 31 August 2026. Any comparison that treats a promotional rate as a permanent one will mislead you at the point the promotion ends. Note the expiry date alongside the price in whatever spreadsheet or document your team uses for this.
A price cut is not a commitment. Nothing about a reduction announced on 30 July constrains what any provider does in October. Prices in this market have generally moved downward, but "generally" is not a guarantee, and a business case that only works at the current rate for the current tier is a fragile business case. Build the routing layer so that changing a model is a configuration decision — that portability is the real hedge, and it pays whether prices fall further or not.
Three weeks between general availability and an 80% price cut is a short interval. If you priced a customer contract, a pilot, or an internal business case against the launch rate card, the assumptions in that document are now wrong in your favour — but they are still wrong. Go and correct them before someone else finds the discrepancy.
What to do this week
The whole story reduces to a short list. Pull the last month of token usage and break it down by feature, so you know where the volume actually is. Identify the two or three highest-volume workloads that have a checkable output, and build or dust off an evaluation set for them. Run that set against your current tier and against Luna, and compare failure modes rather than headline scores. If the cheap tier holds, put it behind an escalation ladder with a validator and a fallback, roll it out to a slice of traffic, and watch a quality metric for a full week before committing. Then write down what you assumed, including the date the introductory pricing you relied on expires.
None of that is glamorous work, and none of it is new. What has changed is the size of the prize for doing it. When the cheap tier sat at a fifth of the flagship price, careful routing was a nice optimisation. At a twenty-fifth, it is the single largest lever most teams have on their inference bill — and the teams who already built the eval harness are the ones who will collect on it this week rather than next quarter. More coverage of pricing and platform changes sits in our product news section.