If you run Cursor or Claude Code hard, you already know the shape of the bill: The session feels cheap while you're in the loop.
The meter (or the invoice) shows up later.
By then the damage is done — or you're rate-limited mid-task with no useful receipt for finance.
Cloud FinOps solved a version of this years ago: budgets that only notify aren't a control plane. Agentic coding has the same gap. Autoscale had traffic as a natural ceiling. An agent spends on intent. There's no gentle slope — just a wall.
I built LoopBudget for that surface: soft warn, hard stop, and a session receipt for Cursor and Claude Code.
This post is the honest version of what "hard stop" means in early access, how the sidecars/hooks fit, and what we're deliberately not claiming yet.
Vendor UIs optimize for account-level or period-level usage. That's fine for finance at month-end. It's the wrong resolution for a coding agent.
While the loop is running you care about: What teams actually do today:
ccusage
-style)None of those are a live policy. An alert that fires after the spend already happened is still just an alert.
LoopBudget attaches to the session trail and evaluates spend against a policy:
| Mode | What happens |
|---|---|
| Soft warn | |
| Cross the soft cap → warn on the receipt + alert members. Session keeps going. | |
| Hard stop | |
Cross the hard cap → stop decision, alerts, session marked stopped in LoopBudget. |
Path A honesty: in early access, hard stop is a policy decision + receipt + alert. It is not a guaranteed vendor SIGKILL. Cursor and Claude Code don't expose a perfect "kill this agent now" primitive to third parties the way people wish they did.
So when we say soft warn / hard stop, we mean:
Blocking the next tool call after a turn completes — a real ceiling — is the next step. Soft warn exists so you can wind down before you need that.
Two connectors, same policy engine.
Cursor — a sidecar watches session transcripts, estimates tokens from the trail, and ingests into LoopBudget. Decisions show in the dashboard. Cursor itself is not force-stopped by us today.
Claude Code — a Stop-hook path sends deltas after a turn. Same ingest → same soft/hard evaluation → same receipt. Claude Code is not killed mid-loop unless you later add a blocking hook that checks LoopBudget first.
Public CLI (static binaries, no Node on the GA path):
[github.com/LoopBudget/cli](https://github.com/LoopBudget/cli)
Estimates can lag vendor invoices. We don't pretend to replace the cloud bill. We aim to make mid-loop visible and policy-shaped.
Someone on Product Hunt asked the right question:
Does the hard stop kill the run mid-edit, or wait for the current tool call so you don’t get a half-written file?
Today we don't yank the vendor mid-tool-call. That means LoopBudget isn't the thing leaving a half-written file via a hard kill — because we aren't cutting the edit mid-flight.
The safer control plane looks like:
That's the design target. Shipping "we killed your agent" before we can do (2)–(3) cleanly would create worse outages than surprise spend.
LoopBudget is invite-only early access:
If you're an eng lead (or power IC) watching AI tooling become a real cost line, I'd love feedback on where soft vs hard should trip for your team — and whether "wait for current tool call, block the next" matches how you already think about agent risk.
Alerts aren't controls. Soft warn / hard stop is the missing primitive for coding-agent loops.