The Sub-$0.30 AI Tier Arrived. What It Actually Unlocks

Cheap LLM pricing stopped being a rounding error and became a planning input in the last week of July 2026. OpenAI reduced the price of GPT-5.6 Luna by 80% and GPT-5.6 Terra by 20% on July 30, Qwen3.7 Flash showed up on OpenRouter at three cents per million input tokens, and DeepSeek V4 Flash arrived with a published vendor rate of $0.14 per million. Three vendors, one week, one direction.

What makes this awkward to write about — and easy to get wrong — is that not one of those models has a single price. GPT-5.6 has a standard list, a batch rate, a flex rate, a fast-mode rate, a separate long-context tier and a cached-input rate. DeepSeek V4 Flash has a vendor list price and a cheaper dated-snapshot listing on OpenRouter. Qwen3.7 Flash has an OpenRouter provider rate and, as far as we could establish, no located vendor list page. Quoting “$0.10 per million” without naming the surface is not a shortcut; it is a different number.

This piece does three things. It labels every price by surface so you can audit the arithmetic. It publishes a workload-normalised cost table across all three vendors, recomputed from a stated formula. And it names the workloads that genuinely flip from too-expensive to routine at this floor, plus the ones that do not move at all.

The compression happened between July 27 and July 31, 2026. On July 27, Qwen3.7 Flash appeared on OpenRouter at $0.03 input and $0.13 output per million tokens with a one-million-token context, taking text, image and video input and returning text. On July 30, OpenAI published a banner on its GPT-5.6 page confirming a price reduction, alongside a dedicated post explaining it. On July 31, DeepSeek shipped V4 Flash with a published vendor rate — the release itself we covered separately in DeepSeek V4 Flash’s official release.

OpenAI’s own wording on the cut is unambiguous, and worth reading precisely because it names both models and the effective date rather than gesturing at “lower prices.” The vendor banner reads: Update on July 30, 2026: OpenAI reduced the price of GPT‑5.6 Luna by 80% and GPT‑5.6 Terra by 20%. The companion post dates the change to the same day and frames Luna as the volume tier.

OpenAI also attributes the cut to its own engineering rather than to competitive pressure alone. The post describes GPT-5.6 Sol autonomously rewriting and optimising production kernels inside a human-led process, work the company says reduced the end-to-end cost of serving the model by 20% while raising token-generation efficiency by more than 15%. Those are vendor-stated figures with no independent audit we could locate, so treat them as an explanation offered rather than a verified accounting.

The independent read was blunter. Simon Willison, writing the same day, put the Luna cut at the centre of the whole low-cost tier and backed it up by migrating a live agent demo from Gemini to Luna — the kind of move that says more about real deployment economics than any pricing table.

Willison also argues that Luna’s new rate now undercuts Google’s Gemini 3.1 Flash-Lite and Anthropic’s Claude Haiku 4.5. We are repeating that as his comparison, not as a verified fact: we did not confirm either competitor’s current list price against a vendor pricing primary in this pass, and a competitor-price claim is exactly the sort of thing that ages badly. If a Gemini or Claude comparison is load-bearing for your routing decision, pull those two numbers yourself from the vendors’ own pricing pages before you act on them.

Before any comparison is meaningful you have to fix the surface. For GPT-5.6, OpenAI’s pricing documentation exposes a standard short-context list, a batch rate, a flex rate, a fast-mode rate, a separate long-context tier and a cached-input rate. They are not variants of one number; they are different products with different latency and durability commitments. A cost model built on the wrong one is wrong by a factor of two to ten.

The table later in this post keeps to short-context pricing on purpose. Adding the long-context tier as a sixth column would make it unreadable without adding decision value, because most bulk workloads — classification, tagging, enrichment, chunk-level summarisation — sit far below any long-context threshold by construction. If your job genuinely needs a million tokens in one request, the long-context rate is the one to model, and roughly doubling the short-context figures gets you a first approximation for the OpenAI family.

That last bar is the compounding nobody put in a headline. The vendor announced an 80% cut, and the batch discount was already there. Stack them and Luna batch input today is one tenth of what Luna standard input cost on July 29 — $0.10 against $1.00 per million, with output following the same ratio at $0.60 against $6.00. For a workload that was already latency-tolerant and already on Luna, the bill fell by an order of magnitude without a single line of code changing.

Here is the specific error we nearly shipped ourselves, and the reason it is worth a section rather than a footnote. A live pull of OpenRouter’s model catalogue shows openai/gpt-5.6-luna at $0.10 input and $0.60 output per million, and openai/gpt-5.6-terra at $1.00 and $6.00. Those are OpenAI’s batch and flex rates, not its standard list. A reader building a cost model from the aggregator would understate interactive Luna spend by half.

The obvious correction — “OpenRouter shows batch pricing for GPT-5.6” — is also wrong. The same pull shows openai/gpt-5.6-sol at $5.00 and $30.00, which is the standard list rate, not the $2.50 / $15.00 batch rate. The mismatch holds for Luna and Terra and does not hold for Sol. That asymmetry is what makes it dangerous: the natural verification instinct is to spot-check one model, and if you happen to check Sol you will conclude the aggregator is fine and carry a 2× error into every Luna line item.

This generalises well beyond one week in July. Aggregators are genuinely useful for discovery, for failover and for reaching models you have no direct contract with. They are a poor source of truth for unit economics, because a listing can reflect a specific upstream provider, a promotional rate, a particular service tier, or a snapshot the vendor does not price separately at all. Every one of those cases appears in this post. If you are maintaining a running price table — we keep one in our Q2 2026 pricing index — anchor each row to a vendor page and treat aggregator figures as a second column, never as the column.

Below is the honest state of each candidate at the time of writing, including the parts we could not resolve. Where a figure is a provider rate rather than a vendor list price, it says so. Where two sources disagree, both appear.

The Qwen figure deserves the caveat it carries. Three cents per million input tokens is the lowest number on this page by a wide margin, and it is exactly the kind of figure that gets screenshotted without its label. What we can say is that OpenRouter lists Qwen3.7 Flash at $0.03 / $0.13 with a one-million-token context. What we cannot say is that Alibaba prices it there, because we did not find the vendor page. Those are different claims and only the first one is supported.

DeepSeek has the opposite problem: a clear vendor price that a specific aggregator SKU undercuts. DeepSeek’s own API pricing lists V4 Flash at $0.14 cache-miss input and $0.28 output. On OpenRouter, the base deepseek/deepseek-v4-flash listing matches that exactly, at 1,048,576 context. But a newer listing, deepseek/deepseek-v4-flash-0731 — with -latest pointing at the same snapshot — is priced at $0.09 / $0.18 on the same context. Both figures are real and correctly sourced. We are deliberately not explaining the gap: the cause is unconfirmed, and inventing a plausible reason is how a pricing post becomes a pricing rumour.

Per-million-token prices are the wrong unit for a planning conversation, because nobody buys a million tokens — they run a million rows. The table below converts each surface-labelled price into cost per 1,000 calls for five representative bulk workloads. Multiply any cell by 1,000 to get the cost of a million-call job.

The formula for every cell is (input_tokens × input_price + output_tokens × output_price) ÷ 1,000,000 × 1,000, with prices in dollars per million tokens. The token counts are illustrative modelling assumptions we set, stated in the second column so you can substitute your own — they are not vendor figures and not benchmark-derived. Every cell was recomputed from that formula rather than carried over from another framing.

Two things jump out. The first is that the whole table fits inside a single dollar per thousand calls. A million product descriptions enriched at 400 input and 150 output tokens comes to $260 on Luna standard, $130 on Luna batch, $98 at DeepSeek’s vendor rate, $63 on the cheaper DeepSeek OpenRouter SKU and $31.50 at Qwen3.7 Flash’s OpenRouter rate. Those are all numbers a marketing team can approve without a finance review, which is the actual behavioural change here — not the percentage cut.

The second is the row where Luna batch and DeepSeek vendor standard land on exactly the same figure: $0.350 per 1,000 document-chunk summarisations. That is a coincidence of this particular token shape, not a general equivalence — shift the ratio toward output-heavy work and Luna’s $0.60 batch output rate pulls ahead of DeepSeek’s $0.28 in the wrong direction, while input-heavy work favours Luna, whose $0.10 batch input undercuts DeepSeek’s $0.14. Which is the practical lesson: at this price floor, model choice is decided by your input-to-output ratio far more than by headline rates.

Notice also what the table does not tell you. It is a token-cost model, not a total-cost model. It says nothing about how many of those thousand calls return an answer you can actually use, which is the number that decides whether a cheap model is cheap. That is the argument for measuring cost per successful task rather than cost per token — a model at a third of the price that needs two attempts is not a saving.

Three vendor events in five days are hard to stack mentally. The table below puts each change on one line with the multiple recomputed as old price divided by new price, per side. Rows are grouped by what kind of change they represent, because a vendor cutting its list price, a new generation replacing an old one, and a discount surface applied to an unchanged model are three different events that all look like “it got cheaper.”

The Qwen row is the one to read twice, and not because of its size. Input got 6.25× cheaper and output got 8.65× cheaper between Qwen3.6-Flash and Qwen3.7 Flash — the output side fell further than the input side, which is unusual. Most generational price moves preserve the input-to-output ratio because it tracks serving cost fairly directly. Breaking that ratio, if it persists, changes which workloads a model suits: generation-heavy jobs that were priced out on the previous generation become disproportionately more viable than retrieval-heavy ones. Both figures are OpenRouter listings for both generations, so at least the comparison is surface-consistent.

The Terra row is the counterweight to the excitement. A 20% cut is real but it is a 1.25× multiple, not a 5×. Terra at $2.00 / $12.00 standard is not a cheap-tier model and nothing about last week made it one. The gap between Terra standard and Luna standard is now 10× on input and 10× on output, which is a much starker routing decision than it was on July 29 — and a much better reason to be deliberate about which tier each call goes to. The three-tier family itself we covered at GPT-5.6’s public GA.

A price cut only matters where price was the binding constraint. For a lot of AI work it was not — the constraint was accuracy, governance, latency or the absence of anyone to own the output. The matrix below sorts the common bulk candidates by whether last week actually changed the decision.

The forward-looking read is that the interesting constraint has moved from token cost to job engineering. When a million-row enrichment pass costs $63 of tokens — the 400-in / 150-out row above on the DeepSeek V4 Flash-0731 OpenRouter rate — the thing standing between a team and that pass is not budget approval. It is idempotency, partial-failure recovery, sampling QA on nondeterministic output and a hard cost guard that stops a runaway loop before it becomes an invoice. Those are unglamorous problems and they are now the rate limiter. We have written them up separately in the bulk LLM job engineering guide and worked the specific DeepSeek case in the V4 Flash bulk workloads playbook.

Our own expectation for the next two quarters is that the sub-$0.30 tier stops being a story about which vendor is cheapest and becomes a story about switching cost. When several models sit within pennies of each other on input, the differentiator is how quickly you can re-point a pipeline when one of them cuts again — and, given that this week produced three separate price events, the answer needs to be days rather than a quarter. Teams that hard-code a model name into a hundred call sites will keep paying last month’s rate simply because moving is expensive.

A price cut you do not act on is a press release. Five moves convert it into an actual line-item change, roughly in order of effort against return.

Re-price your existing jobs before changing anything. If you already run Luna, your bill fell on July 30 without any work. Establish that new baseline first, because it changes which further optimisations are worth the engineering. A migration that saves 30% of a bill that just fell 80% may no longer clear the bar.

Audit which surface each job actually uses. Most teams discover at least one latency-tolerant pipeline running on the standard endpoint out of habit. Moving it to batch or flex is a 50% cut on OpenAI’s published rates, and the failure mode is a slower job, not a wrong answer.

Check your cache-hit rate before switching vendors. Cached input on Luna runs around $0.02 per million against $0.20 standard, and DeepSeek’s cache-hit input rate is $0.0028 against $0.14 cache-miss. A prompt restructure that lifts cache hits can beat a vendor migration, and it does not require re-running evaluations.

Set the cost guard before the first big run. A hard spend ceiling per job, enforced in code rather than in a dashboard alert, is what makes it safe to be relaxed about the rest of this. Our token-budget and cost-control framework covers the mechanics.

Re-verify prices on a calendar, not on a rumour. Three vendors moved in five days. Any internal price table older than a month should be treated as a hypothesis. Anchor each row to a vendor pricing page, record the surface and the retrieval date in the table itself, and re-pull monthly.

If you want help turning this into an actual routing and cost architecture — model selection per workload, batch versus interactive paths, caching strategy, spend guards and the evaluation harness that tells you whether the cheap tier is good enough for a given job — that is the shape of our AI transformation engagements, and it is also how we run our own content engine at volume.