Spend Guardrails for AI Coding Agents
Claude Code, Cursor agents, Codex loops, and autonomous coding agents can rack up $40 in 20 minutes provisioning cloud resources, calling paid APIs, and installing metered SDKs. sipi.bot caps per-loop spend and kills runaway coding agents before they burn your budget.
aws ec2 run-instances, gcloud compute instances create, fly scale count), paid API calls during debugging (OpenAI, Anthropic, data vendors), metered SDK installs that bill on use, infrastructure that scales up during a debug session and never scales down. None of these have a native "should I really run this?" check.
Native MCP integration
sipi.bot ships an MCP server that Claude Code, Cursor, and Hermes load as a tool directly. The agent evaluates every proposed spend through the MCP tool before executing the command:
pip install sipi-bot
python -m spendfirewall.mcp_serverOnce loaded, the agent can call evaluate_spend before any shell command that would move money:
# inside Claude Code / Cursor
evaluate_spend(amount=25, merchant="aws.amazon.com", category="compute")
→ {"decision": "APPROVED", "reason": "Within all spend policies."}
# agent proceeds to run: aws ec2 run-instances ...
evaluate_spend(amount=2500, merchant="unknown-gpu.ru", category="compute")
→ {"decision": "BLOCKED", "reason": "Merchant not on allowlist"}
# agent does NOT run the commandThe failure modes sipi.bot catches
1. The unattended provisioning loop
A coding agent retries a failed aws ec2 run-instances command. Each retry provisions another instance. By the time you notice, you have 15 instances running and a $400 bill. A velocity rule (max 5 provisioning calls per hour) kills the loop on the 6th attempt.
2. The aggressive scale-up during debug
An agent debugging a performance issue scales up infrastructure to test — fly scale count 20, aws autoscaling set-desired-capacity 50 — and forgets to scale back down. A per-transaction cap blocks any single scale-up over a threshold; a daily total caps aggregate provisioning spend.
3. The novel metered SDK
The agent installs a metered SDK to test a feature. The SDK bills on use. A 20-minute test session racks up $40 before anyone notices. A category limit caps "metered-sdk" spend at a small daily amount.
4. The prompt-injected spend
If your coding agent ingests untrusted content (a GitHub issue, a PR body, a web page), a prompt injection can instruct it to route spend to an attacker-controlled vendor. A merchant allowlist blocks this — only vendors you've approved go through.
The rules that matter for coding agents
| Rule | What it catches | Example |
|---|---|---|
| Velocity | Retry loops, runaway provisioning | Max 5 cloud-provisioning calls per hour |
| Per-transaction cap | Catastrophic single call | Block any single spend over $100 |
| Daily total | Aggregate debug-session spend | Max $200/day across all agent spend |
| Category limit | Metered SDKs, data APIs | Cap "metered-sdk" at $20/day |
| Merchant allowlist | Prompt-injected vendor routing | AWS, GCP, Fly, Vercel only |
| Time window | Unattended overnight sessions | Flag all spend outside 9–18 |
What this is not
sipi.bot is not an LLM-cost-optimization tool. It will not tell you which model is cheapest or cache your prompts. It is a spend firewall — it stops your coding agent from spending money you didn't authorize, full stop. For LLM cost optimization, compose it with LiteLLM; for LLM observability, compose it with Helicone or Langfuse.