Checking · Contacting the Aiyo Runtime Decision Point. ·
Conversion moment

Stripe verifies payment. Aiyo verifies execution eligibility — continuously.

Watch a streamed output halt mid-word the moment the budget exhausts. The server refuses to send the next token. The halt is real.

Halted · Budget exhausted
The server refused to send the next token. Re-authorize to continue from where the stream stopped.
Streamed output
Budget
$1.00
Consumed$0.00
Tokens emitted0
Cost per token
Statusready
What's real, what's simulated

The halt is real. The server enforces the budget and refuses to send the next token. Open DevTools and watch the EventSource: when the budget exhausts, the server emits a halt event and closes the connection. No token event arrives. The client cannot fake this — it would have to fabricate a server message that never came. What you're watching is the Runtime Decision Point (RDP) rejecting the next unit of work because a continuously-evaluated condition became false mid-execution.

The opening authorization is demo-elided. In a production Aiyo flow this would be a real settlement on the merchant's wallet (5–10s for test-net finality). The demo grants the budget directly so the conversion moment isn't buried under a wallet handshake. The architecture is the same; only the opening step is shortened.

Per-token billing is not the v1 API surface today. Aiyo's production RDP is per-intent: one authorization artifact unlocks one execution. This demo shows the same primitive applied at finer granularity — a forward-look at the spend-controls layer in the roadmap, not a feature shipping in v1.