A budget you cannot exceed.
The cap is taken before the call runs. A runaway agent is refused, not reconciled afterwards.
A budget you cannot exceed.
The cap
$SWORK is live.
CA: En7YyzDvb5zU36BWUuycVgaxbxhe95rbuBK9NgEApump
The tool does not need it. The engine, the portal and every endpoint are open
and unmetered, and holding $SWORK unlocks nothing that is currently locked.
Most infrastructure asks you to trust that the limit works.
Connect a wallet. Mint a key capped at $1. Run calls until it stops.
That is the whole demo, it takes about a minute, and it costs nothing no
email, no password, no deposit, no waitlist. The signature is over a sentence
and cannot move funds.
Twenty-one calls in the screenshot. Twelve refused. Nothing over the cap.
You do not have to believe me. Go press it against the wall.
Four real ones, and what caught each:
Every call returned 500. The rate object held BigInts and JSON cannot serialise
them — the integer money that makes the engine exact is the thing JSON cannot
carry. Caught by the hostile sweep, not by tsc or the build.
The session cookie was Secure on http. The browser accepted it and never sent
it back, so sign-in returned 200 and the dashboard stayed locked with nothing
saying why. The sweep passed the whole time because Node's fetch copies cookie
headers by hand and ignores the Secure attribute.
The page and the API read different stores. The accounts map was declared at
module scope, so each bundle got its own: the API minted keys into one and the
dashboard rendered from another. The portal showed "keys 0 · $0.00" seconds
after two keys and twenty calls. Both halves working. Completely disagreeing.
The demo on the front page proved nothing. The cap was set high enough that the
"fire 12 at once" button admitted all twelve — a button whose entire purpose is
showing a refusal, producing none. Caught by clicking it and reading the number.
The hold is the worst case. Afterwards it settles to what was actually used,
and the difference is released.
Settlement can only ever reduce the charge. It cannot take more.
So an upstream that reports more usage than the ceiling you declared gets
clamped to the hold. That is a bug on their side or an attack on yours, and
either way your key is not on the hook for it.
The cap was the promise. Nothing downstream of it can raise it — including us.
There is no endpoint that raises a cap.
A token can cost a millionth of a cent. Cents are not small enough to hold the
price and floats are not exact enough to hold the total, so everything here is
a whole number of micro-cents, start to finish.
swork-fast, 4,000 in, ceiling 2,000 out:
4,000 × 2 = 8,000 µ¢
2,000 × 8 = 16,000 µ¢
reserved 24,000 µ¢ = $0.24
That output figure is the ceiling you declared, not an estimate of what the
call will probably use.
Reserving the likely cost and hoping is the same bug as checking the balance.
The call that overruns is precisely the one you needed to stop.
The hard part is not the limit. It is two calls arriving at the same moment.
`if (spent < cap) run()` is the obvious implementation and it is broken: both
read the same balance, both pass, both run.
Cap 1,000 µ¢. Two calls of 600 µ¢. Both admitted. Spent 1,200. Over by 200, and
the money is already gone.
So nothing here reads a balance. Every call reserves its worst case up front,
atomically, and a refused call never starts.
Eight calls fired at once against a key with room for exactly one:
1 admitted. 7 refused. committed + held = 24,000 µ¢ against a cap of 24,000.
A key capped at $1.00. Each call reserves 24,000 µ¢ its worst case, not an
estimate.
Four calls admitted. 96,000 µ¢ committed.
The fifth was refused:
this call could cost 24000 µ¢ and only 4000 µ¢ remains under the cap of 100000
µ¢ it was not started
It was not started. Not reconciled afterwards, not flagged in a report next
Tuesday. The work never ran, so there is nothing to dispute.
Metered compute tells you what you spent. It does not stop you spending it.
An agent in a retry loop finds its budget the way a car finds a wall. The
invoice arrives afterwards itemised, accurate, and far too late.
A stopwork is the part inside a watch that makes over-winding impossible. Not a
warning. Not a log line. The mainspring cannot take another turn.
That is the whole design.