Alerts aren’t controls: soft warn / hard stop for Cursor and Claude Code loops

A developer built LoopBudget, a tool that provides soft-warn and hard-stop controls for Cursor and Claude Code sessions, addressing the gap where alerts alone fail to prevent runaway AI agent costs. The tool attaches to session trails, evaluates spend against policies, and issues receipts, though hard stop currently blocks the next tool call rather than force-killing mid-edit.

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 https://loopbudget.com 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.