Why loops are suddenly everywhere
Two things changed at once: models got good enough to keep making forward progress across dozens of steps, and harnesses got good enough to feed them a verifiable goal — a test suite, a script, a gate that says pass or fail. That combination turns an assistant into a worker that runs unattended, which is a very different operational object.
The stop condition nobody designs
Loop designs are full of thought about what to do next and almost empty on what to do when
the next thing costs money or quota. A 402 or a 429 at 3am is not a
transient error to retry through; it is a hard stop that will still be there in the morning,
with the loop having burned its remaining iterations discovering that.
Answer one: pay for it
Two protocols now exist for an agent to settle a charge without a human or a card —
x402 over HTTP 402, and MPP. Both are real, and both are explained here without
being implemented: see /x402 and /mpp for the handshake
and for the honest reason this deployment takes neither.
Answer two: remove the wall
The reason this repository exists. A metered publish call is a stop condition inside every loop that uses it; a self-hosted one is a fixed cost on infrastructure you already own. The loop's budget question stops being per call and becomes "is my account still under the free tier", which is a question you can answer before you go to bed.
That trade is not free either
Self-hosting moves the failure from a payment wall to a quota wall, and quotas are shared. This deployment learned that the loud way: several rounds of testing hit a daily request limit that turned out to be account-wide and mostly consumed by an unrelated worker on the same account. The lesson generalises — know which limit is per-service and which is per-account before you rely on either.
Design the stop condition on purpose
- Decide in advance which failures are retryable.
402,403and429usually are not — treat them as terminal and record why. - Make the loop write down what it was blocked on, somewhere a human reads in the morning. A blocked loop that leaves no note is indistinguishable from a crashed one.
- Give the loop a budget it can check, not a curfew. Wall-clock limits stop good work as readily as bad.
- Keep the verification gate cheap. If checking the work costs as much as doing it, the loop spends its life re-testing instead of progressing.
What this deployment does about it
Publishing has no per-call charge, anonymous publishing needs no key at all, and the rate limits that do exist are documented rather than discovered. Whether the loop pays or is spared from paying, the requirement is the same: the wall must be legible before the loop runs into it.
Should my loop be allowed to spend money?
Only against a budget it cannot exceed and a ledger you can read afterwards. The protocols make the payment possible; the policy is still yours to write.
Does this deployment accept x402 or MPP?
No. There is no per-call cost to recover on infrastructure you already pay a flat rate for, so a payment rail would collect zero. The protocols are documented anyway because the question comes up.
What limits will a loop actually hit here?
Rate limits on anonymous publishing, and whatever your own platform account allows. The first is in this codebase; the second is the one that bites, and it is shared across everything on that account.
Is a loop safe to leave running against a live site?
Against this API, publishing is additive and deleting is explicit, so the blast radius is sites the key owns. Give an unattended loop its own key so revoking it is one call.