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

> Source: <https://dev.to/lucianlature/alerts-arent-controls-soft-warn-hard-stop-for-cursor-and-claude-code-loops-2afc>
> Published: 2026-07-28 14:21:21+00:00

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.