DEV Community

Lucian Lature
Lucian Lature Subscriber

Posted on

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

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.

Why vendor meters fail mid-loop

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:

  • This session — not the whole seat
  • This task — not "AI line item"
  • Now — not the invoice three weeks later

What teams actually do today:

  • Upgrade to Max and hope
  • Spreadsheet leftovers after the fact (ccusage-style)
  • Slack when someone notices the bill

None of those are a live policy. An alert that fires after the spend already happened is still just an alert.

Soft warn vs hard stop (what we ship today)

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:

  1. You see the trip live on the session receipt
  2. Your team gets notified
  3. You have something finance (or your future self) can point at

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.

Cursor sidecar vs Claude Code Stop hook (high level)

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

Estimates can lag vendor invoices. We don't pretend to replace the cloud bill. We aim to make mid-loop visible and policy-shaped.

Half-written files: why we don’t kill mid-edit today

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:

  1. Soft warn while there's still runway
  2. Let the current tool call finish
  3. Refuse or gate the next tool call once the hard cap trips

That's the design target. Shipping "we killed your agent" before we can do (2)–(3) cleanly would create worse outages than surprise spend.

Try early access

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.

Top comments (0)