How to set a hard spend limit on an AI coding agent

The short answer: a hard spend limit on a coding agent needs a component that sits between the agent and the model API, tracks real cost per request as it happens, and refuses or pauses the next call once a threshold is hit. A usage dashboard that updates after the fact doesn't do this — by the time you see the number, the agent already spent it. You need something in the request path, not something reading logs an hour later.

I built Probe0 partly because I watched Claude Code get stuck in a retry loop against a broken test for eleven minutes before I noticed. It wasn't a huge bill, maybe four dollars, but it was four dollars for zero output and it happened while I was in another window. Multiply that by a bad week and it stops being a rounding error.

Why a dashboard alone won't save you

Tools like ccusage and Claude Code Usage Monitor are genuinely useful — they parse your local session transcripts and show token counts and cost per session, per day, per project. I use one of them myself to sanity-check totals. But they're read-only by design. They tell you what already happened. Nothing in that category intercepts a request and says no. If your agent enters a loop at 2am while a long task runs unattended, a dashboard will show you an accurate, detailed record of the damage the next morning.

That's fine for reporting. It's not a cap. A cap has to live somewhere the request physically passes through.

What an actual cap mechanism needs

• Sits in the request path — a proxy, gateway, or SDK wrapper the agent's calls actually go through, not a log reader
• Tracks real cost, not just token count — different models on the same provider can be 10-20x apart in price per token
• Has both a per-run and a per-day ceiling — a single runaway task and a slow accumulation across a busy day are different failure modes and need different limits
• Warns before it blocks — a silent hard stop mid-task is its own kind of damage; you want a heads-up, then a pause
• Fails closed, not open — if the tracking layer itself breaks, the safe default is to stop routing, not to silently let everything through uncapped

The gateway route: LiteLLM and friends

If you're already running a self-hosted or team gateway, LiteLLM's proxy has real budget controls — max_budget on keys, teams, and users, with configurable reset periods. It's mature and it works, and if you're managing spend across a team of engineers sharing a provider account, it's the more natural fit than a single-developer tool. Helicone offers similar ground: request logging plus rate limiting rules you can attach to a key. Both are hosted-or-self-hosted gateway models, which means they're built for the case where multiple people and multiple apps share one routing layer.

The tradeoff is setup weight. Standing up a gateway, pointing every tool's base URL at it, and managing budget config as YAML or a dashboard is worth it at team scale. For one developer running Claude Code, Codex, or Cursor on a laptop, it's a lot of infrastructure to enforce a number you could set in one field.

Where Probe0's Spend Guard fits

Probe0 is a proxy that runs locally on your machine — there's no Probe0 server, nothing leaves your laptop except the requests you were already going to send to your model provider. You install one local certificate once, and every coding agent CLI on the machine routes through it automatically: no per-tool config, no separate base URL for each app.

Spend Guard is one of the modules in that proxy. It's a hard cap you set per run or per day. It watches real dollar cost, computed from the actual model and token counts on each call passing through, not an estimate. Cross the threshold and it warns first, then pauses — it doesn't silently eat your next fifty requests before telling you anything went wrong. Every call is also written to a local ledger (model, tokens, real cost, latency, which process made the call), so if a cap does trigger you can see exactly what ran it up, on your own disk, without shipping that data anywhere.

This is the honest tradeoff: Probe0 is macOS-only, single-developer, and in private beta, so if you need a shared budget enforced across a five-person team hitting one provider account, LiteLLM's proxy or Helicone's gateway is the better architectural fit today. Probe0 is built for the developer running agents solo who wants the cap enforced on their own machine without standing up infrastructure for it.

Setting a cap in practice

• Pick a per-run number first — this catches the loop-that-never-ends case, which is the one that actually hurts
• Set the per-day number roughly 3-5x your normal daily spend — tight enough to catch a real problem, loose enough that a heavy legitimate session doesn't trip it
• Treat the warning as a checkpoint, not noise — when it fires, look at what's running before you raise the limit and move on
• Revisit the numbers after a week of real data instead of guessing on day one

The number that matters isn't what you spent last week. It's the ceiling on what a single bad loop can cost you before anyone notices.

Whichever route you take — a team gateway with budget rules, or a local proxy that pauses on your own machine — the underlying requirement is the same: the cap has to be enforced by something in the path of the call, evaluated in real dollars, before the request goes out. Anything downstream of that is just a very accurate obituary for money you already spent.