GPT-5.6 Luna Got 80% Cheaper. Amazon's $1.8 Million Overrun Is the Same Story.

OpenAI repriced its cheapest tier the same week Amazon told staff about a five-month spend overrun on a project that never shipped. Here is how to put a real ceiling on an agent loop before you route more work through it.

A million input tokens through GPT-5.6 Luna costs twenty cents as of today. Yesterday the same million cost a dollar. Output fell from $6 to $1.20, and the reduction runs through every service tier on the sheet, so Batch and Flex land Luna near a dime.

Two days earlier, Amazon engineering leadership walked staff through a project that spent $1.8 million on Claude Sonnet matching author records against product listings. It ran 860% over budget. Nobody surfaced it for five months. The deployment failed anyway.

Those two events read like they belong to opposite arguments. They are the same argument, seen from each end.

The thing that got cheaper is the thing you will now do more of

OpenAI's own post is careful about what changed. Luna drops 80%, to $0.20 in and $1.20 out. Terra drops 20%, to $2 and $12. Sol holds at $5 and $30. Priority Processing is gone, replaced by Fast mode, which runs Sol up to 2.5x standard speed at twice the price and accepts requests already tagged priority without a code change.

Read the stated source of the savings, because it is the most interesting sentence in the announcement. OpenAI says Sol, working inside a human-led process, rewrote production GPU kernels and ran hundreds of experiments on the speculative-decoding draft model, cutting end-to-end serving cost 20% and raising token-generation efficiency by more than 15%. That is a model paying for its own price cut. It is also OpenAI's measurement of OpenAI's stack, unaudited by anyone outside the company.

Now look at what a customer says the price does to behavior. Blitzy's CTO, quoted in the same post, describes moving from a single structured-output call to a full tool-calling agent loop, with prompt-cache reuse climbing from 24% to 90%. That is the whole mechanism in one sentence. A cheaper tier does not make your existing workload cost less. It makes a workload you would not have built become worth building, and that workload calls the model many more times.

One call became a loop. Loops do not have a fixed length.

I have watched this happen on a much smaller scale in my own work. Route a classification step down to a cheap model, notice it is now cheap enough to retry on low confidence, add the retry, then add a verification pass because retries are cheap too. The per-call price fell by four fifths and the monthly bill went up. Nothing broke. Nothing errored. The system got better and more expensive at the same time, which is the hardest kind of regression to notice.

The failure mode is an invoice, and invoices arrive monthly

Here is the part of the Amazon story that builders should sit with, and it has nothing to do with Amazon.

A retry loop that re-sends the same context throws no exception. It does not crash a process, fill a disk, spike a latency graph, or page anyone. Every request returns HTTP 200. Every response is well-formed. The only artifact the failure produces is a line on a bill, and bills close monthly.

That is why the gap between mistake and signal was measured in months rather than minutes. Your observability stack was built for systems that fail loudly. Token spend fails politely.

The Financial Times reported the internal meeting, and coverage lists two smaller cases alongside the headline one: roughly $541,000 on financial auditing tools and about $134,000 on logistics delivery-speed work, that last one caught after two weeks. Amazon's position is that presenting isolated examples as business as usual misrepresents how its teams operate, which is a fair objection to the framing and irrelevant to the mechanism. The mechanism is available to every team with an API key.

Two weeks is the number I would stare at, not five months. Two weeks was the good outcome. Two weeks is what happens when someone is paying attention.

Google shipped the fix as a parameter, two days before the story broke

On July 28, Google added budget controls to Managed Agents in the Gemini API. You pass max_total_tokens inside agent_config and it caps total consumption across input, output, and thinking tokens together.

The behavior at the limit is the part worth copying. The agent does not error. Execution pauses, the interaction returns status: "incomplete", the sandbox environment is preserved, and you resume by passing previous_interaction_id with a fresh budget. A bounded run that stops and waits is a design decision, not a crash.

The same release added environment hooks, which are a second lever on the same problem. Drop an .agents/hooks.json into the environment and your script runs on pre_tool_execution or post_tool_execution events, matched by regex against tool names. Return {"decision": "deny", "reason": "..."} from a pre-execution handler and the tool call is skipped, with your reason passed into the model's context so it can adapt rather than retry blindly. That is a place to put a counter.

Google shipping token caps into its agent platform two days before Amazon's overrun became public is not clairvoyance. It is two companies reading the same room.

Put this into practice

Pick one agent loop you already run. Not your most important one, your longest one.

Set a hard ceiling on that loop today. On Gemini Managed Agents it is literally max_total_tokens in agent_config. On other stacks you write it yourself: a counter in the loop body that sums usage from each response and breaks when it crosses a threshold you chose on purpose.
Handle "stopped early" as a real outcome. If your only two branches are success and exception, a budget cap has nowhere to land. Add a third path that persists state and reports what got done. Gemini's incomplete status plus a preserved environment is the shape to imitate.
Log token spend per run next to latency. Not per month. Per run. The signal you are missing is variance between runs of the same task, and a monthly total averages that signal out of existence.
Alert on tokens-per-completed-task, not tokens-per-day. Volume growth is expected when you make something cheaper. A rising cost per finished unit of work is the thing that means something went wrong.
Move one workload down a tier and measure both numbers. The bill and the call count. If the bill fell and calls stayed flat, you saved money. If calls tripled, you bought capacity, which may be exactly what you wanted, but you should know which one happened.
Put the ceiling where the loop runs. A budget review is a report about the past. A cap in the deployment path is the only thing that stops a run in progress.

The cheapest version of this is one afternoon and a counter. Do that before you change any defaults.

Honest limitations

A token cap you can reset in one line is a speed bump. Gemini's budget applies per interaction, and continuing with previous_interaction_id and a fresh budget is trivially easy, which is good ergonomics and bad enforcement. A project-level ceiling is a different control and Google's announcement does not describe one.

A cap also cannot tell a productive long run from a retry storm. Both look like token consumption. The counter buys you a bounded blast radius, not a diagnosis, and the diagnosis still needs a human reading traces.

The Amazon reporting is secondhand for most readers. The Financial Times account sits behind a paywall, the figures come from an internal meeting rather than a filing, and Amazon disputes the characterization. I would not build a slide deck on the exact dollar amounts. The pattern of a spend failure hiding inside a billing cycle survives even if every number moved.

OpenAI's efficiency figures are self-reported and unaudited, and the Blitzy numbers are a vendor-published customer quote in a pricing announcement. Both are plausible. Neither is independent evidence.

The strongest counterargument is that cheaper tokens are straightforwardly good, and I agree. Work that was uneconomic last week is economic today, and Luna handling tool calls and multi-step flows at a fifth of its old price is a real expansion of what is worth automating. I am not arguing against the price cut. I am arguing that the price cut changes the shape of your risk without announcing that it did.

There is also a version of this where I am overfitting to one bad week of news. Most teams running agent loops are not going to lose $1.8 million. Most will lose four hundred dollars they never notice, on a run they forgot was scheduled.

The number nobody is publishing

Every vendor this week published a price. None of them published the distribution of what a single agent run actually costs on their platform, and that is the number that decides whether you get burned.

You can measure it yourself by Friday. Take one loop, cap it, log the per-run token spend for a week, and look at the tail rather than the mean. If the ninety-fifth percentile run costs twenty times the median, you do not have a pricing problem. You have a workload nobody bounded, and today's price cut just made it five times cheaper to be wrong at scale.

Sources: OpenAI, "Advancing the price-performance frontier with GPT-5.6"; Google, "Gemini API Managed Agents: 3.6 Flash, hooks, and more"; CNBC on the GPT-5.6 price cut; Tom's Hardware on the Amazon overrun, reporting on the Financial Times account.