A Company Burned ~$500M on Claude in One Month. One Setting Would Have Caught It.

The $500M Month

In a story that made the rounds in 2026, a company reportedly spent around $500 million on Claude in a single month, not because of one giant job, but because it handed employees licenses and failed to put a usage limit on them.

Sit with that. The failure wasn't a model that was too expensive. It wasn't a bad architecture. It was a missing budget. Every individual action looked reasonable. There was just no ceiling, and nobody was watching the total until the total had four commas in it.

This is the defining cost-control problem of the agent era, and almost nobody has a real answer for it. You can buy the most capable models in the world by the token, and the tooling to stop buying them, automatically, at a threshold you set, basically doesn't ship in the box.

Why This Keeps Happening

AI agent spend has three properties that make it uniquely good at surprising you:

1. The cost is invisible at the moment it's incurred. When an agent runs a shell command, edits a file, or makes a model call, there's no price tag on the action. The bill is assembled later, somewhere else, by your provider. By the time you see it, the spend already happened.

2. Agents multiply round-trips. A human writes one prompt. An agent in a while loop writes ten thousand. A xargs … | claude fan-out writes ten thousand in parallel. Each one is a paid round-trip. An accidental loop doesn't cost you a typo. It costs you a budget.

3. Per-seat access compounds. Give one engineer an un-metered license and you have one variable bill. Give two hundred engineers un-metered licenses and you have two hundred variable bills, each capable of spiking independently, with no aggregate cap. That is precisely the shape of the $500M month.

The provider's own dashboard doesn't save you here. Usage dashboards and email alerts are after-the-fact. They tell you what you already spent. By the time the "you've hit 80% of your budget" email arrives, the loop has been running for an hour.

To actually prevent the runaway bill, you need a limit that lives where the spend originates: at the tool call, and that can say no on its own.

Two Halves of Spend Control

SigmaShake (ssg) governs AI agents at the tool-call layer, deterministically, in microseconds, with no LLM in the loop. Spend limits are built on top of that gate in two complementary halves.

Half one: catch the runaway patterns (stateless rules)

Some spend disasters are recognizable by their shape, before a single dollar is spent. The rules-spend-limits ruleset flags them:

Pattern	What it catches
Bulk seat / license provisioning	Handing out --seats / --licenses in bulk without confirming a per-seat cap: the exact $500M failure mode.
Un-metered API-key creation	Minting keys (especially in a loop) with no spend cap attached: the #1 cause of surprise bills.
Unbounded agent loops	A while true that calls a model every iteration. One paid round-trip per loop, forever.
Wide LLM fan-out	xargs / parallel / a high -P piping into an agent CLI: concurrency with no ceiling.
Premium model in batch work	Reaching for the most expensive model inside a loop, where a smaller model is often 10–20× cheaper.

These are ASK / LOG by default. They make a risky action a deliberate, reviewed one without blocking your normal workflow.

ssg hub pull rules-spend-limits

Half two: enforce the dollars (built into SSG)

Patterns aren't enough. "How much have I spent today?" is a stateful question, and deliberately, it's something a .rules pattern can't answer (the rule grammar is a stateless match on the current tool call; it has no memory of what came before). So the dollar limit lives in the engine itself.

SigmaShake keeps a local cost ledger: every governed tool call is attributed a directional USD estimate, bucketed by agent (claude-code, codex, …). The spend gate reads that ledger and enforces your caps right at the eval gate, after the normal rule pass:

                ┌───────────────────────────────────────────┐
  tool call ──▶ │ 1. rules: is this a runaway-spend *shape*?  │  ASK / LOG
                └───────────────────────────────────────────┘
                              │
                              ▼
                ┌───────────────────────────────────────────┐
                │ 2. budget gate: are we over the $ cap *now*? │  BLOCK / ASK
                └───────────────────────────────────────────┘

You set caps per window: per session, per day, per 7 days, per month, globally and per agent. And you pick how hard the gate pushes back:

Mode	Behavior
Off	No tracking, no limits. (The default. Nothing changes until you opt in.)
Monitor	Track spend and show it. Never blocks anything. The safe "see what would happen" mode.
Warn	At a cap, an action that would've been allowed is downgraded to ask. You confirm.
Enforce	At a cap, the action is blocked. Past the warn threshold, it's an ask.

Because enforcement reads the same ledger the dashboard draws its gauges from, what you see is what gets enforced: there's no second source of truth to drift.

Simple Enough for the Person Who Pays the Bill

The whole point is to be usable by whoever owns the budget, not just whoever writes the code. So the Spending Limits page has two views off the same data:

• Simple view. Plain-language modes ("Just track" / "Warn me" / "Hard stop"), one-click dollar presets (Light · Standard · Heavy · No limit), and two gauges: today and this month. No jargon, no rule syntax. Pick a number, you're done.
• Technical view. A per-agent cap table across every window, the warn threshold, and the raw policy the daemon enforces: for when you want a tight $10/day leash on codex specifically but a generous monthly pool for claude-code.

Prefer the terminal?

ssg cost budget          # spend vs. your limits, per agent, this period
ssg cost summary --by=client --since=30d

The Lesson, Generalized

The company in that story didn't get unlucky. They ran a system with no ceiling and were surprised when it had no ceiling. The fix isn't "watch the dashboard more carefully": humans are exactly the wrong component to put in a loop that runs at machine speed. The fix is a limit that enforces itself, at the layer where the spend is born, before the money is gone.

Set it once. Let the gate hold the line.

ssg hub pull rules-spend-limits
# then open the dashboard → Spending Limits, or: ssg cost budget

Spend figures are a directional, on-device estimate computed at the tool-call layer: ideal for catching runaway patterns and enforcing local caps. Reconcile against your provider's billing for exact invoiced amounts.