Unknown instance types resolve to a deliberately high rate and report low confidence. A guardrail that guesses low is worse than none. GPU families are detected by name and default higher still.
Open sourceMITShopDevXv0.2.0Zero dependencies
a spend limit for what your AI agent does outside the chat
AI agents can now run real commands on real cloud accounts. breakerbox reads every command before it runs, works out what it will cost, and stops it if that breaks a limit you set. No proxy, no daemon, no credentials, no account.
Give an agent a terminal and you give it your cloud account. Most of the time that's what you want. The trouble starts when it loops — and every runaway command runs in under a second.
$ 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.
Nothing was billed. The verdict is computed in Claude Code's PreToolUse hook — before the command reaches your account. Median overhead: ~48ms.
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. LLM gateways cap tokens. Cloud budgets are reactive — they tell you hours later, once the money is gone. Nothing was watching the gap in between: the shell command, the cloud SDK call, the terraform apply.
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.
| Shape | Example | Result |
|---|---|---|
| Oversized resource | aws ec2 run-instances --instance-type p4d.24xlarge --count 8 | deny — $6,292 > per-action cap |
| Runaway loop | while true; do aws ec2 run-instances …; done | deny — billable action, unbounded loop |
| Accumulated drift | 30 small launches across one session | deny — once the session cap is reached |
| Burst velocity | 12 billable actions in 60s | deny — that's a loop, not deliberate work |
| Opaque blast radius | terraform apply -auto-approve | ask — cost lives in files, not the command |
| Unattended, opaque | same, in bypassPermissions mode | deny — an "ask" nobody can answer isn't a guardrail |
| Hidden in substitution | ID=$(aws ec2 run-instances …) | deny — substitutions are parsed too |
| Ordinary work | npm test && git commit -am wip | allow — silently |
Covered today: AWS (EC2, RDS, EKS, SageMaker, Redshift, ElastiCache, OpenSearch, MSK, CloudFormation, ASG, NAT/ALB/TGW, IAM/Organizations), GCP (Compute, GKE, Cloud SQL, Dataproc, Cloud Run), Azure (VM, VMSS, AKS, managed DB, ARM/Bicep), IaC (Terraform, OpenTofu, Pulumi, CDK, SAM, Serverless, Helm), plus metered HTTP APIs and rented-GPU CLIs.
Launching an EC2 instance costs $0 at the moment you launch it — the bill arrives over the following hours. A guardrail that only counted immediate cost would never fire on the exact command that caused the incident. So breakerbox projects the hourly rate over a horizon (default 24h) and charges that against your cap up front:
charged = (oneTime + hourly × horizonHours) × quantity × loopIterations
Unknown instance types resolve to a deliberately high rate and report low confidence. A guardrail that guesses low is worse than none. GPU families are detected by name and default higher still.
For terraform apply and CloudFormation stacks, the cost lives in files breakerbox isn't reading — so the live hook reports unknownBlastRadius and asks. Render the plan (terraform show -json) and breakerbox plan prices the real diff: spend preflight, not guesswork.
A pending intent is written before the tool runs and promoted to a charge only after it does. A command you denied — or cancelled at the prompt — never eats your cap.
LLM gateways — LiteLLM, Portkey, Bifrost
Cap what your agent spends on tokens: session budgets, iteration caps, alert → throttle → kill on model spend. They do it well.
breakerbox
Caps what your agent spends on everything else: the cloud SDK call, the shell command, the terraform apply. The layer nothing else was watching.
init writes breakerbox.config.json, creates .breakerbox/, and registers two hooks in .claude/settings.json. That's the whole setup — no proxy, no daemon, no credentials.
$ npm i -g @shopdevx/breakerboxZero runtime dependencies, no build step.$ breakerbox initWrites config, ledger dir, and the two Claude Code hooks.$ breakerbox doctorFeeds a synthetic 8×p4d.24xlarge launch through the real hook and asserts it comes back denied.$ breakerbox check "<cmd>"Dry-run the policy engine and explain the verdict.$ breakerbox statusSpend against every cap, with meters.doctor doesn't just check that files exist — it tests the chain, not the file listing. Node ≥ 18.17. 67 tests, 0 failures.
Because you stop watching. So, plainly:
eval "$(… | base64 -d)", a cost-incurring action inside a script it invokes, or an SDK call inside python deploy.py are invisible to it. It defends against runaway agents, not an adversary deliberately evading it.2026-08). No region adjustment, reserved instances, savings plans, spot, or data transfer. They exist to make caps trip at roughly the right time — not to reconcile your invoice.Bash is inspected today. MCP tool calls and other tools pass through. This is the biggest known coverage gap, and it's on the roadmap.failMode defaults to open. If breakerbox itself errors, the command proceeds and the error is logged. A bug in a safety tool must not brick your agent. Set "failMode": "closed" to invert that.allow, because that would bypass Claude Code's own permission checks. It only ever speaks up to deny or ask.The strongest setup pairs breakerbox with least privilege. During phases that don't need cloud access, strip raw Bash from Claude's tool list with --allowedTools — no cloud command can be issued at all, so the guard never has to evaluate one, and can't fail open on one. Use breakerbox for the phases where the agent legitimately needs a terminal.
And every command it does evaluate is written to a local decisions.jsonl — the verdict and which fail-mode was live. So when a bill looks wrong, you can tell a priced-under-cap call from a crash-into-fail-open from a hook that was never wired. The three look identical from the outside; only the log separates them.