Hard Budget Caps: How AACFlow Prevents Runaway LLM Spend

The point is simple: an agent cannot spend money the platform has not pre-authorised. The check happens before a single token leaves your account.

Pre-Execution Holds Catch the Loop Before It Compounds

Estimating LLM cost ahead of time is not glamorous. You look at the model, the input length, the expected output length, and the historical drift for that block. You round up. You write the result into creditReservation with an expiry.

When the block finishes, the executor settles the reservation against the actual usage and writes the delta back to walletLedger. The reservation either releases (under-spend) or rolls into a billable line (over-spend, within tolerance).

What breaks the loop is the next block. If an agent has just spent 80 percent of the workflow cap on one iteration, the second iteration's reservation request will be rejected immediately. The executor parks the execution into pausedExecutions with a BUDGET_EXCEEDED reason and emits an event. The agent does not get a quiet retry — it gets a stop.

Why Kopecks, Why BigInt

Floating-point arithmetic has no place in a billing path. We've all seen the 0.1 + 0.2 = 0.30000000000000004 joke. In a system that meters thousands of LLM calls per second across hundreds of workspaces, the cumulative error becomes a reconciliation nightmare.

Kopecks are integers. BigInt lets us store reservations up to whatever ceiling enterprise customers ask for without ever truncating. The currency itself is a metadata field — convert at the boundary, never inside the ledger. Every Postgres row in walletLedger is exactly reproducible from the audit log.

Three Failure Modes the Cap Catches

Real production has taught us which loops actually happen:

• Runaway agent — the model decides it needs to "re-check" its work and triggers itself again. Without a cap, the loop ends when the credit card declines. With a cap, it ends when the reservation fails — milliseconds later.
• Provider price change — OpenAI nudges pricing overnight. Estimated cost drifts. The cap catches the drift on the second execution and pauses the workflow until the operator either tops up or approves the new rate.
• Prompt bloat — context windows grow because a developer accidentally appended a 200KB log. The estimator sees the new input size, the reservation balloons, and the next call is held pending review.

In every case, the failure is visible, bounded, and recoverable. That is the bar a billing system has to clear before you can let agents run without a human in the loop.

Pauses, Not Kills

When the cap trips, the execution is not deleted. It is paused — state, partial outputs, and DAG cursor all preserved in pausedExecutions. An operator gets a notification (Telegram, Slack, dashboard), reviews the spend trail in auditLog, and either tops up the workspace wallet or kills the execution explicitly.

This is the same primitive we use for human-in-the-loop approvals. Same table, same resume path, different trigger. Budgets are just another reason to ask a human.

What This Buys You

Hard caps are the difference between running agents and operating them. Without them you are gambling that no model, no prompt, no upstream change will ever misbehave. With them you have a ledger, a hold, a pause, an audit trail, and a person on the hook for the resume click.

Plug a workspace into AACFlow, set a workflow cap, and walk away from your laptop. The platform will not let an agent ruin your weekend.