According to reporting by the Financial Times, an internal Amazon project used Claude Sonnet to match author information with product listings.
The project reportedly reached $1.8 million in cost, ran 860 percent over budget, and continued for roughly five months before the overrun was identified. It never launched.
Two other internal examples in the same reporting added hundreds of thousands of dollars in unplanned cost.
Amazon has said that isolated examples do not represent AI use across the company, which is a fair caution. A company that large runs many experiments, and some experiments fail.
But the interesting part is not that an AI project failed.
The interesting part is that a metered workflow could run for months without a working relationship between consumption, accepted output, and business ownership.
That is the control failure smaller companies should study.
The Meter Was Not the Missing Part
AI cost discussions often collapse into the price of a token.
Use a cheaper model. Compress the prompt. Cache the context. Route simple tasks locally. Reserve the frontier model for difficult cases.
All of that can reduce cost. None of it answers the operating question.
Should the workflow be running at all?
A token meter tells us how much text a model read and wrote. Cloud billing can tell us which account, model, service, or API key consumed it. Engineering may be able to trace a request through a queue and see how many retries occurred.
Those are technical measurements.
A business needs another one: what accepted outcome did the spending produce?
For an author-matching workflow, that could be the cost per product record accepted without rework. For an invoice agent, it could be the cost per invoice reconciled and posted. For customer support, it could be the cost per case resolved without reopening. For a contract workflow, it could be the cost per clause reviewed and accepted by the responsible person.
Without that denominator, token consumption is only activity.
It is possible to optimize the cost per model call while the workflow produces nothing useful. It is possible to celebrate lower latency while exceptions accumulate in a human queue. It is possible to reduce the price of inference while retry logic runs against records that should have been rejected before the first call.
A cheaper unnecessary loop is still an unnecessary loop.
The Unit of Control Is the Workflow
Traditional enterprise software was easier to budget because much of it arrived in recognizable commercial units.
Seats. Servers. Annual licences. Maintenance contracts. Storage tiers.
The invoice in December was not always pleasant, but it usually resembled the budget approved in January.
Metered inference behaves differently. Cost follows activity, and agentic systems can create their own activity. An agent can read a document, search a catalogue, call a tool, reject a partial match, retry with more context, ask another model to verify the result, and then repeat the path across millions of records.
Each individual step may be inexpensive.
The composition is what becomes expensive.
This is why the unit of governance cannot be the token, the model, or even the cloud account. It has to be the business workflow.
Every recurring AI workflow should have four things before it receives a recurring budget.
First, a named business owner. Not only an engineering owner who keeps the service running, but the person responsible for deciding whether the outcome is worth buying.
Second, a unit of accepted output. Not drafts generated, prompts sent, or tokens consumed. Something the business can inspect and accept.
Third, an explicit budget boundary with alerts before the monthly close. Not a dashboard someone may remember to open. A threshold that changes the system’s behaviour.
Fourth, a safe stopping path. If the AI workflow pauses, the underlying business must still be able to continue, perhaps more slowly, through a deterministic or manual fallback.
Those controls turn inference from a variable technical expense into an owned operating process.
Dashboards Can Still Reward the Wrong Thing
The same Financial Times reporting described an internal usage leaderboard associated with Amazon’s Kiro coding tool. Employees reportedly found ways to increase their measured AI use, a behaviour that became known as tokenmaxxing.
That pattern is older than AI.
When we measured developers by lines of code, people produced more lines. When consulting firms measured delivery through billable days, longer projects produced more revenue. When a dashboard ranks people by token consumption, it should not surprise us when token consumption rises.
The dashboard was visible.
The value was not.
This matters because many AI cost-control programmes begin by exposing usage. Visibility is necessary, but visibility into the wrong unit can make the problem worse. It tells people which behaviour is being rewarded, even when that behaviour has little relationship to completed work.
The useful dashboard starts from the other side.
How many records were accepted?
How many cases reached completion?
How many required human correction?
How many were rejected before inference because the input was incomplete?
How much did each accepted outcome cost, including model calls, retries, review, and rework?
Only then does token usage become operationally meaningful.
Local AI Changes the Cost Shape, Not the Need for Ownership
This is where private and local AI become commercially interesting.
A local inference server or a Mac Mini running an open model changes a variable bill into a more predictable capital and operating cost. The hardware is purchased. Power, maintenance, and support remain, but the organization is no longer surprised by a token invoice each time a workflow becomes busy.
That predictability has value.
It does not make local inference automatically cheaper, and it does not make every workload suitable for a local model. Frontier cloud models may still be the right choice for difficult reasoning, occasional high-value analysis, or workloads whose volume does not justify dedicated infrastructure.
The architecture can mix both.
Routine classification, extraction, and private document handling may stay local. Unusual or difficult cases can escalate to a stronger external model when policy allows. Deterministic code should continue to handle stable calculations, exact validation, and high-volume control paths that do not need a language model at all.
But whether the inference is local or cloud-based, the workflow still needs an owner.
Predictable waste is still waste.
The Kill Switch Has to Preserve the Business
A kill switch sounds dramatic until a metered workflow runs ten times more than planned.
The difficult part is not stopping the agent. It is stopping the agent without stopping the operation.
If an invoice reconciliation agent exceeds its budget, invoices still need to move. If a support classifier fails, cases still need a queue. If a forecasting workflow is paused, stores still need an order path.
That fallback should be designed before the workflow becomes important.
It may be manual review. It may be a deterministic rule set. It may be a smaller local model. It may be reduced functionality with stricter limits. The right answer depends on the operational consequence of stopping.
This is not only cost governance.
It is business continuity for a dependency whose price changes with use.
Someone Must See the Problem Before Finance Does
The Amazon numbers are large because Amazon is large.
For a mid-sized company, the surprise might be $18,000 rather than $1.8 million. The governance failure is the same if the first person to recognize it is the finance team after the books close.
Engineering sees model calls.
Cloud operations sees service consumption.
Finance sees the invoice.
The business owner should see cost per accepted outcome while there is still time to change the workflow.
Metered inference is not the problem. Unowned metered inference is.
If one of your agents ran ten times more than planned last month, who would see it first, what accepted output would they compare it with, and could they stop it without stopping the business?