Open sourceMITShopDevX

breakerbox

a spend limit for what your AI agent does outside the chat

AI agents can now run real commands on real accounts. breakerbox reads every command before it runs, works out what it will cost, and stops it if that breaks a limit you set.

The problem

Your AI bill is metered. Your cloud bill is not.

When you give an agent a terminal, you give it your cloud account. Most of the time that's exactly what you want — it can deploy, test, and clean up on its own.

The trouble starts when it loops. An agent that misreads a task can start servers, then start more, then start more again — and every one of those is a command that runs in under a second. In the best-known case, an operator woke up to roughly $6,500 of cloud charges from an agent that spun up machines by itself overnight.

Here's the part people miss: none of that money was spent on AI. It was spent on servers. Tools that watch your AI spending never saw a thing, because not one of those commands was an AI request.

A fuse box doesn't stop you using electricity. It cuts the power when something draws far more than it should. breakerbox does that for money.

WITHOUT BREAKERBOX WITH BREAKERBOX AI agent starts 8 GPU servers Your cloud account $6,292.34 billed before anyone noticed AI agent breakerbox prices it first Your cloud account $0.00 stopped before it ran
The only difference is one box. breakerbox adds a checkpoint between the agent and your account. The agent still works exactly as before — until a command would cost more than you allowed.

What you actually see

It explains itself, in dollars

Nothing happens silently. When breakerbox stops something, it says what the command would have cost, which limit it broke, and what the agent should do instead. 

$ breakerbox check "aws ec2 run-instances --instance-type p4d.24xlarge --count 8"

DENY  estimated $6292.34

Billable actions
  EC2 p4d.24xlarge x8  $6292.34
  aws.ec2.run-instances · $32.7726/hr · qty 8 · high confidence

Why
  - Single action estimated at $6292.34, over the per-action cap of $20.00.
  - Session spend would reach $6292.34, over the session cap of $50.00.
  - Today's spend would reach $6292.34, over the daily cap of $200.00.

What it catches

Four ways an agent burns money, and what happens to each

Runaway spend rarely looks like one huge command. More often it's a small command repeated until it isn't small any more. breakerbox watches for all four shapes.

What the agent does Example Result
Asks for something far too big aws ec2 run-instances --instance-type p4d.24xlarge --count 8 Deny
$6,292 is over the per-action limit
Gets stuck in a loop while true; do aws ec2 run-instances ...; done Deny
a paid action with no end condition
Drifts — many small charges 30 modest servers over one working session Deny
once the session total is reached
Fires too fast to be deliberate 12 paid commands inside 60 seconds Deny
that's a loop, not a person working
Runs something unmeasurable terraform apply -auto-approve Ask
the cost lives in files, not the command
Same, with nobody watching the above, in auto-approve mode Deny
a question nobody can answer isn't a guard
Ordinary work npm test && git commit -am wip Allow
silently — you never notice it's there

How it's put together

Four small parts, sitting in one gap

Claude Code has a built-in checkpoint called a hook — a place where an outside program gets to inspect a command and veto it before it runs. breakerbox lives in that gap. That's why there's no proxy to run, no service to sign up for, and no credentials to hand over.

Claude Code your AI agent the command it wants to run BREAKERBOX Parser reads the command, counts loops Estimator prices what it will cost Policy compares it to your limits Ledger remembers what you already spent a plain file on your disk ALLOW runs as normal, silently ASK you get the final say DENY never runs, agent told why
Everything stays on your machine. The ledger is an ordinary file in your project folder. Note the arrow direction between Policy and Ledger — the policy check reads your past spend to decide, which is how a series of small commands eventually adds up to a stop.

The journey of one command

Decide before it runs. Charge only after it ran.

This split is the most important design decision in the tool, and it's easy to get wrong.

A blocked command costs nothing — so it must not count against your budget. If it did, a handful of commands you stopped would use up your limit, and an agent that never spent a cent would find itself locked out. So breakerbox writes down what it's about to spend, and only converts that into a real charge once the command has actually run.

Agent writes a command breakerbox intercepts it Work out the cost, then compare against everything spent so far Within every limit? NO YES Blocked, with a reason Nothing charged — your budget is untouched The command runs breakerbox is told it ran Now the spend counts the next command sees the new total
The dashed line closing the loop is what makes limits work over time. Each committed charge raises the running total, so the tenth modest command can be refused even though the first nine were fine.

The counterintuitive bit

Starting a server costs nothing. That's the whole problem.

At the exact moment you start a cloud server, you have been charged $0. The bill arrives gradually, over the hours it stays running.

So a guardrail that only asked "what does this cost right now?" would wave through the very command that causes the damage. breakerbox instead asks "what will this cost if it runs for a day?" — and charges that against your limit immediately.

$0.00 at this exact moment what a naive check would see $6,292.34 what breakerbox charges up front launch +6h +12h +18h +24h cost so far
The 24-hour window is adjustable. Shorten it if your agent reliably cleans up after itself; lengthen it if forgotten servers are your actual failure mode.

Who this is for

Anyone who gave an agent real credentials

Solo developers

You're running an agent against your own cloud account, and there is nobody else to catch a bad night's work before the invoice does.

Small teams

You have real cloud spend but no finance function watching it. Your first warning today is a billing alert, hours late.

Auto-approve users

You run agents in a mode where they don't stop to ask. This is where breakerbox matters most — it's the only thing still saying no.

Teaching and demos

You're handing an agent to someone learning. A hard ceiling turns an expensive mistake into a message on screen.

Using it

Two commands to install, five to live with

Installing it registers the checkpoint and writes a settings file with starting limits of $20 per command, $50 per session, and $200 per day. Change them to whatever a bad day is worth to you. 

$ npm i -g @shopdevx/breakerbox
$ breakerbox init
breakerbox check "…"Ask what would happen to a command, without running it
breakerbox statusSee how much of each limit you've used
breakerbox logReview what's been spent, and on what
breakerbox reset --sessionClear the running total and carry on
breakerbox doctorConfirm it's really protecting you — it tries a real block

doctor is worth running once. It doesn't just check that files are in place — it sends a fake request for eight GPU servers through the real checkpoint and confirms it comes back refused. If something is misconfigured, you find out then rather than during an incident.

Being straight with you

What breakerbox cannot see

A safety tool that oversells itself is worse than none, because you stop paying attention. Here is exactly where the protection ends.

  • It's a spend guard, not a security cage. It reads the command it's shown. A cost buried inside a script it launches, or deliberately disguised, goes through. It's built to stop runaway agents, not a determined attacker.
  • Prices are close, not exact. They're standard list prices, without regional differences or the discounts on your account. They exist to make limits trip at roughly the right moment, not to match your invoice.
  • It watches terminal commands only. Other kinds of tool calls pass through untouched today.
  • If breakerbox itself breaks, your command still runs. A bug in a safety tool shouldn't stop you working. You can flip this to the opposite behaviour in one setting if you'd rather it fail shut.
  • It counts what you started, not what you shut down. If you terminate a server an hour later, breakerbox doesn't know. The 24-hour figure is a decision aid, not accounting.