Amazon’s $1.8M Claude Overrun: Why AI Agent Costs Can Spiral Out of Control

Introduction

AI agents can fail in a way ordinary software rarely does: they can keep trying.

A human employee who hits a broken workflow eventually gets tired, asks for help, goes home, or waits until the next morning.

An autonomous agent can continue calling a model, reading its own output, retrying a tool, rewriting a plan, and starting another loop for hours or days.

That persistence is useful when the task is difficult.

It is expensive when the task is broken.

According to a July 2026 Financial Times report citing Amazon employees and people familiar with internal projects, one Amazon project using Claude Sonnet accumulated roughly $1.8 million in AI costs while trying to enrich author information on Amazon’s website.

The reported bill was about:

860% over the project budget

The overrun reportedly went unnoticed for:

five months

And despite the spending, the project was reportedly not successfully deployed.

That combination makes the story more important than one unusually large invoice.

It illustrates a new enterprise software problem:

small logic error
×
autonomous retries
×
usage-based pricing
×
weak observability
=
large financial loss

The problem is not unique to Claude, Amazon, or any one AI provider.

Agentic systems turn compute into a variable operating expense. When they are allowed to run independently, cost becomes part of application behavior rather than a simple software subscription.

A bug no longer only produces the wrong result.

It can produce the wrong result millions of times while continuing to spend money.

The $1.8 Million Amazon Claude Incident

The task described in the Financial Times report sounds ordinary.

Amazon wanted to improve information about authors on its website.

A Claude Sonnet-based workflow was reportedly used to help match or generate the required author information.

The project then consumed far more AI resources than expected.

Amazon staff reportedly described the final cost as approximately:

$1.8 million

That represented an estimated:

860% budget overrun

The most striking detail may be the detection delay.

The cost problem reportedly remained active or undiscovered for around five months.

That suggests the failure was not only an AI-model problem.

It was also a monitoring and governance problem.

If an enterprise workload can spend seven figures without a clear alert, the system lacks one or more of the controls that would normally be expected around other metered infrastructure.

Those controls might include:

• Per-project budgets.
• Hard spending limits.
• Daily anomaly alerts.
• Per-agent quotas.
• Maximum retry counts.
• Maximum task duration.
• Per-user attribution.
• Cost-per-success dashboards.
• Automatic shutdown rules.

The Financial Times reported that Amazon had seen other examples of unexpectedly high AI costs and that engineers were working on automated guardrails.

Amazon told the publication that such cases were isolated learning experiences rather than representative of its broader AI work.

That distinction is worth preserving.

The $1.8 million incident is a reported internal project failure.

It is not evidence that Amazon’s entire AI program is economically unsuccessful.

The Source’s “600 Billion Tokens” Estimate Needs Context

The original Chinese article makes a dramatic calculation.

It says that at a price of $3 per million input tokens, $1.8 million could buy as many as:

600 billion input tokens

The arithmetic is straightforward:

$1,800,000
÷
$3 per million tokens
=
600,000 million tokens
=
600 billion tokens

But that is not a measurement of the Amazon project’s actual token consumption.

It is only an illustrative upper-bound calculation under several unrealistic assumptions:

1. Every dollar was spent on input tokens.
2. The project used a Claude Sonnet version priced at exactly $3 per million input tokens.
3. There were no output-token charges.
4. There were no cache-write or cache-read charges.
5. There were no platform-specific AWS pricing differences.
6. There were no other inference or infrastructure costs.

Anthropic’s current pricing also varies by Sonnet generation.

As of August 2026, Anthropic lists:

Model	Standard Input	Standard Output
Claude Sonnet 5	$2 / MTok	$10 / MTok
Claude Sonnet 4.6	$3 / MTok	$15 / MTok
Claude Sonnet 4.5	$3 / MTok	$15 / MTok

The Financial Times report identifies Claude Sonnet but the public reporting does not provide enough billing detail to reconstruct the exact model version, input/output mix, cache behavior, or true token count.

So the defensible conclusion is:

The project cost about $1.8 million according to the report; its exact token consumption is not publicly known.

This matters because enterprise AI cost analysis becomes misleading when a dollar bill is automatically converted into tokens using one list-price number.

Why Agent Costs Are Harder to Predict Than Normal Software Costs

Traditional software often has relatively predictable cost drivers.

A team can estimate:

• Number of servers.
• Database size.
• Bandwidth.
• Storage.
• User licenses.
• Requests per second.

LLM agents add another layer.

One user request may trigger:

1 model call

or:

200 model calls
+ tool calls
+ retries
+ context replay
+ web search
+ code execution

The user may see only one final answer.

The cost meter sees the entire trajectory.

Context Gets Repeated

Agents often resend large portions of their working context during each reasoning step.

A long repository, large document, tool history, or conversation can therefore be charged repeatedly.

Output Creates More Input

An agent’s previous generated text often becomes context for the next model call.

The system effectively pays to generate information and then pays again to read it.

Retries Can Multiply Cost

A failed tool call may trigger:

1. Error interpretation.
2. New reasoning.
3. A modified call.
4. Another result.
5. Another model turn.

A retry loop that looks harmless in code can produce large token consumption.

Costs Are Stochastic

Research on agentic coding has found that token use for the same task can vary dramatically from run to run.

A 2026 study examining several frontier models on SWE-bench Verified reported differences of up to roughly 30× between runs on the same task.

More tokens also did not consistently produce better results.

That makes “estimate the bill from task difficulty” an unreliable budgeting method.

Amazon’s Automation Dream Is Much Bigger Than One Failed Project

The source article then moves from the $1.8 million incident to a broader point.

Amazon is not backing away from AI.

It is increasing its investment.

CEO Andy Jassy has repeatedly argued that generative AI and agents will reshape both customer products and Amazon’s internal work.

In June 2025, Jassy told employees that Amazon already had more than:

1,000 generative AI services and applications

either built or in progress.

He also predicted:

There will be billions of AI agents
across companies and fields.

Jassy said agents could perform work such as:

• Web research.
• Deep research.
• Coding.
• Anomaly detection.
• Translation.
• Data analysis.
• Workflow automation.

He also said broader AI adoption would change Amazon’s workforce mix and that efficiency gains would likely reduce the company’s total corporate workforce over time.

The $1.8 million Claude incident therefore happened inside a company that is deliberately pushing toward far more automation, not less.

Amazon Is Spending About $220 Billion in 2026

Amazon’s infrastructure commitment is enormous.

During its second-quarter 2026 earnings cycle, Jassy raised the company’s expected 2026 capital expenditure to roughly:

$220 billion

up from the earlier approximately $200 billion plan.

Much of that spending is connected to:

• AWS data-center capacity.
• AI infrastructure.
• Custom chips.
• Servers.
• Networking.
• Power.
• Robotics and other long-term infrastructure.

Amazon’s 2025 shareholder letter had already explained that the company was not making its earlier $200 billion estimate “on a hunch.”

Jassy said AWS had substantial customer commitments that justified much of the infrastructure buildout.

That creates a useful contrast:

Amazon is spending hundreds of billions
to expand AI capacity

while simultaneously learning
how to stop individual AI workloads
from wasting millions.

Those two problems are not contradictory.

Infrastructure capacity and workload efficiency are separate questions.

AWS Is Producing Real Returns From the AI Boom

The source correctly notes that Amazon’s AI and cloud spending is not producing only costs.

Amazon’s official Q2 2026 results show that AWS grew strongly.

For the quarter ended June 30, 2026:

Metric	Q2 2026
Amazon total net sales	$200.6B
AWS net sales	$42.2B
AWS YoY sales growth	37%
Amazon total operating income	$27.5B
AWS operating income	$16.6B

AWS therefore contributed roughly:

60% of Amazon operating income

while accounting for about:

21% of total net sales

in that quarter.

Amazon also said both its AI business and chips business had exceeded $25 billion annual revenue run rates.

So the company has a strong economic reason to continue pushing AI adoption even while improving cost discipline.

Amazon’s Workforce Is Changing at the Same Time

AI spending is only one side of Amazon’s automation program.

The company has also been reducing corporate roles.

A Reuters report in October 2025 said Amazon was targeting as many as 30,000 corporate job cuts.

Jassy separately told employees that broader adoption of generative AI would likely mean fewer people performing some categories of work and more people performing others.

It is important not to reduce every Amazon layoff to “AI replaced the employee.”

Large-company workforce reductions can involve:

• Reorganization.
• Pandemic-era overhiring.
• Cost pressure.
• Management-layer reduction.
• Business closures.
• Automation.
• AI-driven efficiency.

What is clear is that Amazon itself expects AI to change its future staffing requirements.

Warehouse Automation Moves the Same Logic Into the Physical World

The source then moves from office automation to warehouses and logistics.

Reports based on internal Amazon documents have described an ambitious robotics strategy.

The reported goal is to automate a large share of warehouse operations over the coming years, potentially allowing Amazon to avoid hundreds of thousands of additional hires as shipment volume expands.

One widely reported estimate said automation could allow Amazon to avoid roughly:

160,000 additional U.S. hires by 2027

and more than:

600,000 additional hires by around 2033

relative to a less automated growth path.

Those numbers are based on reported internal projections, not a public Amazon commitment to fire 600,000 current employees.

That distinction matters.

“Avoiding future hires” and “eliminating existing jobs” are economically related but not identical.

Amazon has publicly emphasized that robotics can also create different roles around:

• Maintenance.
• Reliability.
• Robotics engineering.
• Process supervision.
• Technical operations.

The long-term labor effect remains contested.

Economist Daron Acemoglu has been among the prominent critics warning that aggressive automation by a major employer can shift the company from being a large job creator toward eliminating or avoiding large numbers of jobs.

The Era of “More Tokens = More AI” Is Ending

The source’s second major section turns from Amazon to a broader Silicon Valley behavior: tokenmaxxing.

For a period, companies were trying to accelerate AI adoption so aggressively that usage itself became a status signal.

Managers wanted employees to:

• Use more AI.
• Run more agents.
• Automate more work.
• Experiment aggressively.
• Build smaller teams around AI.

In some organizations, that encouragement turned into leaderboards.

And once the metric became visible, employees learned how to optimize the metric.

This is a classic example of Goodhart’s Law:

When a measure becomes a target, it stops being a good measure.

A company wants productive AI adoption.

It measures token usage because token usage is easy to count.

Employees then increase token usage.

The number goes up.

But productive output may not.

Amazon Shut Down KiroRank

Amazon had an informal internal leaderboard known as KiroRank.

It tracked or ranked employees based on activity involving Kiro, Amazon’s AI development tooling.

Business Insider and the Financial Times reported that some employees began performing unnecessary AI work to increase their scores.

Amazon eventually shut down the leaderboard.

Senior vice president Dave Treadwell told employees not to use AI merely for the sake of using AI.

Amazon moved toward measures focused more on actual output, including a metric described as normalized deployments.

The lesson is simple:

token consumption
≠
productivity

A developer who uses 100 million tokens to ship nothing is not automatically more effective than one who uses 5 million tokens to solve the problem.

Meta’s Claudeonomics Leaderboard Created the Same Incentive

Meta reportedly had a similar experiment.

An employee-built internal leaderboard called Claudeonomics aggregated AI usage across more than 85,000 employees and displayed the top 250 users.

Reports described titles such as:

• Token Legend.
• Cache Wizard.
• Session Immortal.

The Information reported that Meta employees were consuming tens of trillions of tokens over rolling 30-day periods.

Later reporting put a 30-day total near:

73.7 trillion tokens

Meta subsequently moved toward tighter usage controls and a centralized AI Gateway for cost visibility and budgets.

These figures are based on internal-reporting coverage rather than Meta’s public financial statements.

The source article also converts 73.7 trillion tokens into a hypothetical $221 million monthly bill.

That number should not be treated as Meta’s actual invoice.

It is essentially:

73.7 trillion tokens
×
$3 per million tokens
≈
$221 million

which assumes every token was billed at one input-token list price.

Real usage may involve different models, negotiated enterprise rates, input/output mixes, caching, internal models, and platform arrangements.

The useful fact is the scale of reported token usage—not the simplistic bill conversion.

Uber Used an Entire Annual AI Coding Budget in Four Months

Uber ran into a similar budgeting problem.

Reporting in June 2026 said the company had consumed its annual budget for agentic coding tools during the first four months of the year.

Uber then introduced a default cap of:

$1,500 per employee
per month
per agentic coding tool

The cap applied separately to tools such as:

• Claude Code.
• Cursor.

Employees could see their usage through an internal dashboard, and exceptions could be approved where additional spend was justified.

That approach is much closer to traditional cloud FinOps.

The question changes from:

How much AI did the employee use?

to:

How much did this workflow cost,
and was the result worth it?

Uber executives have continued to argue that AI can produce meaningful efficiency gains.

The shift is not from “use AI” to “do not use AI.”

It is from unrestricted consumption to managed consumption.

Even OpenAI Says Cost Became a “Huge Issue”

Model providers are dealing with the same economics internally.

At an enterprise event in June 2026, Sam Altman said OpenAI’s highest internal token user was consuming about:

100 billion tokens per month

He contrasted that with roughly six and a half years earlier, when 100,000 tokens per month had seemed extraordinarily high.

Business Insider also cited a New York Times report that one OpenAI employee used about:

210 billion tokens in one week

Altman said cost had gone from something customers barely mentioned at the beginning of 2026 to a:

“huge issue”

later in the year.

The irony is obvious.

AI labs want models to become cheaper so customers can use more AI.

As models become cheaper and agents become more autonomous, total usage can expand faster than unit prices fall.

This is a version of the Jevons effect:

cheaper unit cost
→ more usage
→ potentially higher total spend

Most Enterprises Still Cannot See Their Full AI Bill

Cost governance is difficult because AI usage is scattered.

An enterprise may pay for AI through:

• Direct APIs.
• AWS Bedrock.
• Azure.
• Google Cloud.
• SaaS subscriptions.
• Coding agents.
• Embedded copilots.
• Departmental expense accounts.
• Internal inference.
• Third-party workflow tools.

A Wall Street Journal CFO report cited a survey finding that only:

26% of enterprises

had a comprehensive view of their AI costs.

That means many companies start trying to optimize AI spending before they can even reliably attribute it.

A finance team may know the total vendor bill but not:

• Which team created it.
• Which application created it.
• Which customer workflow created it.
• Which agent loop caused the spike.
• How much cost produced successful output.
• How much was retry waste.

AI Cost Governance Needs More Than a Monthly Invoice

A useful enterprise AI cost system should answer several layers of questions.

Level 1: Who Spent It?

Track by:

• Employee.
• Team.
• Product.
• Repository.
• Agent.
• Environment.

Level 2: What Consumed It?

Separate:

• Input tokens.
• Output tokens.
• Cache writes.
• Cache reads.
• Tool calls.
• Search.
• Code execution.
• Retries.

Level 3: What Did the Spend Produce?

Connect cost to:

• Deployment.
• Ticket resolved.
• Pull request merged.
• Report delivered.
• Customer request completed.
• Revenue event.
• Hours saved.

Level 4: Was the Agent Behaving Normally?

Monitor:

• Repeated identical calls.
• Retry loops.
• Sudden context growth.
• Token spikes.
• Long idle sessions.
• Tool failures.
• Tasks with no progress.

The goal is not simply to reduce tokens.

It is to detect low-value tokens.

A Better Agent Budget Has Multiple Guardrails

One monthly dollar ceiling is useful but incomplete.

A production agent should often have several simultaneous limits.

Example:

Per task:
  max runtime: 30 minutes
  max model calls: 80
  max retries per tool: 3
  max cost: $5

Per user:
  daily budget: $50

Per team:
  monthly budget: $25,000

Global:
  anomaly alert at +100% hourly spend
  emergency kill switch

The exact values depend on the application.

The architecture is the important part.

A runaway system should hit several independent barriers before it can create a seven-figure surprise.

Why Hard Limits Matter for Autonomous Agents

Traditional software usually waits for a new request before doing more work.

An agent may create its own next action.

That changes the risk model.

Suppose an agent is asked:

Find the correct author records and update the database.

It discovers ambiguous matches.

It searches again.

Then it asks the model to compare candidates.

Then it retries an API.

Then it generates a new search query.

Then it expands context.

Then it loops.

If success is poorly defined, the system can remain “busy” for a long time without becoming more correct.

The agent needs a concept of:

stop

for both technical and financial reasons.

Higher Automation Does Not Automatically Mean Higher Efficiency

The source closes by reaching back to a famous pre-AI automation failure: Knight Capital.

The analogy is useful because Knight’s problem had nothing to do with LLMs.

It was a failure of automated software, deployment controls, and loss limits.

On August 1, 2012, Knight Capital deployed new trading software for the New York Stock Exchange’s Retail Liquidity Program.

According to the U.S. Securities and Exchange Commission, a deployment error left old code active on one server.

When the new system went live, that dormant functionality began sending unintended orders into the market.

The system continued for approximately:

45 minutes

The SEC later said Knight accumulated an unintended multibillion-dollar securities portfolio and lost more than:

$460 million

The original Chinese article uses the commonly cited figure of roughly $440 million. The SEC’s later enforcement materials use more than $460 million, so this adaptation uses the regulator’s figure for accuracy.

The Knight Capital Lesson Was About Missing Safety Nets

The SEC’s criticism was not simply that software contained a bug.

Software will contain bugs.

The more important failures included:

• Weak deployment procedures.
• Inadequate testing.
• Missing controls.
• Poor monitoring.
• Lack of effective automated shutdown mechanisms.

Knight’s system executed at machine speed.

That speed was normally an advantage.

During failure, the same speed multiplied the damage.

The basic pattern is almost identical to agent-cost risk:

automation works
→ speed is valuable

automation fails
→ speed magnifies loss

AI Agents Add a New Type of Loss Function

Knight’s system spent money directly through trades.

Most enterprise agents do not have brokerage access.

But they do have a meter.

Every model call can incur cost.

Every tool can create downstream effects.

Some agents may also be authorized to:

• Buy cloud resources.
• Launch jobs.
• Send email.
• Change code.
• Deploy infrastructure.
• Purchase services.
• Move data.

As AI systems receive more authority, their failure modes begin to look less like chatbot mistakes and more like automation-control failures.

That is why AI governance increasingly needs concepts familiar from financial systems and cloud infrastructure:

• Budgets.
• Circuit breakers.
• Rate limits.
• Approval thresholds.
• Audit logs.
• Rollbacks.
• Kill switches.

Automation Amplifies Both Success and Failure

The source ends with the right principle.

Automation promises:

• Faster execution.
• Lower unit cost.
• Fewer repetitive human errors.
• Greater scale.
• 24/7 operation.

Those advantages are real.

But the system does not selectively amplify only correct behavior.

It also amplifies:

• Bad assumptions.
• Broken loops.
• Incorrect permissions.
• Misconfigured tools.
• Poor incentives.
• Missing limits.

The most dangerous automation is not necessarily the system that fails immediately.

It is the system that looks productive while failing quickly, repeatedly, and invisibly.

Amazon’s reported $1.8 million Claude project is not a reason to stop using agents.

It is a reason to stop treating agent consumption as an unmetered experiment.

Practical AI Agent Cost-Control Checklist

Before Deployment

1. Define the business outcome.
2. Define a maximum acceptable cost per successful task.
3. Estimate normal token and tool usage.
4. Set hard per-task limits.
5. Define retry limits.
6. Create a timeout.
7. Require human approval for high-impact actions.

During Execution

1. Attribute spend to a named project and owner.
2. Track input, output, cache, and tool charges separately.
3. Alert on abnormal hourly or daily growth.
4. Detect repeated calls and stalled loops.
5. Record success and failure outcomes.
6. Expose current cost to the agent operator.

After Execution

1. Calculate cost per successful result.
2. Review unusually expensive trajectories.
3. Compare model tiers.
4. Use caching where appropriate.
5. Remove unnecessary context.
6. Route simple tasks to cheaper models.
7. Update limits as behavior changes.

The point is not to minimize the bill at all costs.

It is to make the bill explainable.

FAQ

Did Amazon really spend $1.8 million on a Claude project?

The Financial Times reported that an Amazon project using Claude Sonnet accumulated roughly $1.8 million in costs, about 860% over budget, and that the problem took around five months to detect. The figure comes from internal employee reporting rather than an Amazon public incident report.

Did the Amazon project really use 600 billion tokens?

That number is only a rough arithmetic illustration based on dividing $1.8 million by a $3-per-million input-token price. The project’s real token count, model version, input/output mix, cache usage, and other charges have not been publicly disclosed.

How much does Claude Sonnet cost now?

Anthropic currently lists Claude Sonnet 5 at $2 per million standard input tokens and $10 per million output tokens. Sonnet 4.6 and 4.5 are listed at $3 and $15 respectively, before applicable caching, batch, or cloud-platform differences.

Why can AI agents become so expensive?

Agents can make many model calls for one user request, replay large contexts, invoke tools, and retry failures automatically. If the workflow loops or lacks a stopping condition, spending can continue even when the task is no longer making useful progress.

What was Amazon KiroRank?

KiroRank was a reported informal internal leaderboard related to employee use of Amazon’s Kiro AI tooling. Amazon shut it down after employees reportedly began optimizing for the metric itself, and leadership told staff not to use AI simply for the sake of increasing usage.

How should companies limit AI-agent spending?

Useful controls include per-task dollar budgets, model-call limits, retry caps, timeouts, per-user and per-team quotas, anomaly alerts, usage attribution, and an emergency kill switch. The best metric is usually cost per successful business result rather than raw token volume.

What does Knight Capital have to do with AI agents?

Knight Capital lost more than $460 million in about 45 minutes after an automated trading deployment failed without sufficient safeguards. The incident illustrates the same general principle: automation increases the speed of useful work, but it also increases the speed and scale of failure.

Does lower token pricing solve the enterprise AI cost problem?

Not by itself. Lower unit prices can encourage much higher usage, especially when agents operate autonomously. Enterprises still need visibility, budgets, routing, caching, and outcome-based measurement.

相关工具

• Anthropic Claude Pricing: Official pricing for Claude models, prompt caching, batch processing, and agent sessions.
• Amazon Bedrock: AWS’s managed platform for using Claude and other foundation models with enterprise controls.
• AWS Budgets: AWS tooling for defining budgets and triggering alerts when spending or usage exceeds thresholds.
• AWS Cost Explorer: A service for analyzing and attributing AWS spending over time.
• AWS Cost Anomaly Detection: Automated monitoring designed to identify unusual AWS spending patterns.
• Kiro: Amazon’s AI development environment referenced in reporting about the internal KiroRank usage leaderboard.

Related Links

• Financial Times: Amazon Finds Cases of AI Causing Runaway Spending: The primary report on Amazon’s $1.8 million Claude project and other internal cost overruns.
• Amazon Q2 2026 Results: Official confirmation of AWS’s $42.2B Q2 revenue, $16.6B operating income, and Amazon’s $27.5B total operating income.
• Andy Jassy on Generative AI and Agents: Amazon’s official memo describing more than 1,000 generative-AI services and Jassy’s expectation of billions of future agents.
• Anthropic Claude Pricing: Current official Sonnet pricing and token-billing details.
• SEC: Knight Capital Trading Failure: The regulator’s account of the 2012 automated-trading incident and Knight’s more-than-$460M loss.
• Business Insider: Amazon Shuts Down KiroRank: Reporting on Amazon’s AI-usage leaderboard and the move away from tokenmaxxing.
• Wall Street Journal: The Metric CFOs Struggle to Track—AI Usage: Reporting on enterprise AI-cost visibility and the 26% comprehensive-visibility figure.

Summary

An Amazon project using Claude Sonnet reportedly accumulated a $1.8 million bill, exceeded its budget by roughly 860%, took five months to detect, and still failed to reach deployment. The incident shows how an ordinary software mistake can become unusually expensive when an agent can repeatedly consume metered AI resources without a strong stopping condition.

Amazon is not retreating from AI. AWS is growing rapidly, the company expects roughly $220 billion in 2026 capital expenditure, and Andy Jassy has described a future containing billions of agents. The response to runaway costs is therefore more likely to be stronger cost governance than less automation.

The same shift is visible across Silicon Valley. Amazon killed KiroRank, Meta moved from tokenmaxxing toward budgets, Uber imposed $1,500 monthly limits per employee per coding tool, and Sam Altman says AI cost has become a major concern even inside OpenAI.

The Knight Capital failure provides the enduring lesson: automation does not only scale efficiency. When controls are weak, it scales mistakes at the same speed.

The right enterprise AI metric is not “How many tokens did we use?” It is “What measurable result did those tokens produce, and what stops the system when they stop producing value?”