Field note 01 · Economic control
Rate limits slow traffic. Reservations bound loss.
A rate limiter asks how many requests may start. An economic reservation asks whether this operation can still fit inside the money a run is allowed to lose.
8 minute read · Updated August 28, 2026
Requests are not economically interchangeable. One call might cost a fraction of a cent. Another can open a large output window, trigger tools, spawn children, and retry across several layers.
The stale balance problem
Suppose a run has $5 left. Twenty workers read that balance at the same time and each starts a request expected to cost $1. A perfectly functioning rate limiter can admit all twenty if its request quota allows it. The run can now expose $20 against a $5 boundary.
$5
authority left
20
workers
$1
each request
$20
possible exposure
Change the sequence
The wallet owner must serialize authority before external work begins. The important word is atomic. A dashboard counter updated after calls complete is useful evidence, but it is not a spending boundary under concurrency.
- 01Estimate the worst-case cost from the model, output bound, and operation type.
- 02Atomically reserve that amount before contacting the provider.
- 03Reject the operation if settled spend plus open reservations exceeds the run budget.
- 04Settle against measured provider usage and release unused authority.
- 05Reconcile abandoned reservations after a bounded expiry.
Use the whole control stack
Reservations do not make the other controls obsolete. Each layer answers a different operational question.
Traffic
Rate limits shape request volume and protect capacity.
Account
Provider caps bound exposure across a wider project or account.
Run
Atomic reservations enforce the authority assigned to one outcome.
Behavior
Retry, depth, fan-out, duration, and output limits catch non-price failures.
Response
Scoped containment stops the failing run while healthy work continues.
Evidence from contention and production
The internal contention harness starts 32 simultaneous requests against a $0.05 run cap. Two reservations fit and thirty are denied. A separate healthy run remains available.
32
simultaneous attempts
2
reservations admitted
30
requests denied
The production canary then admitted one healthy request, blocked a deliberate retry, froze only the affected wallet, and allowed an unrelated control run to settle. The test reserved 10 microdollars in total and completed with the incident recovered and closed.
The real result is a calculable boundary.
Not an alert after spend rises. Not a shared account cap. A decision, made before the next expensive action, about the exact authority remaining for one run.
Sign context
Keep run, tenant, retry, and parent identity trustworthy.
Reserve first
Place worst-case exposure inside the wallet before execution.
Prove recovery
Retain the denial, containment, healthy control, and restoration evidence.
Give one real workflow a hard boundary.
Start in shadow mode, prove the response path, then promote the reviewed policy with a canary.