Most API billing begins before an API call: a person opens an account, enters a payment method, waits for approval, and receives a reusable credential. That is manageable for a long-running company account. It is awkward for short-lived software that needs one answer right now.
OpenZK starts with a funded note. Once the note is in place, a request can carry the payment proof needed to authorize a limited amount of work. For the current product, that work is a metered inference call. The client obtains a lease, streams the response, and settles actual usage against its private balance.
Why the unit matters
“Pay per request” is a more useful unit than “buy an account” when demand is uneven. Consider a development assistant that calls a model only after a human asks for a costly operation. A monthly subscription hides the marginal cost; an invoice arrives too late to help the caller decide. A per-request flow makes the cost boundary part of the action.
The note remains prepaid. The holder first decides how much ETH to place in the vault, then spends in smaller pieces. That creates a practical cap on exposure for an application or agent. It also lets a developer present a current balance and a request history without running a conventional customer billing account.
The request path today
The current browser toolkit supports one concrete path:
- Choose a supported model. Its cost tier sets the session's requested spending limit.
- Generate a proof from the browser-held note and acquire inference access.
- Send the prompt to OpenRouter using the leased access and stream the response.
- Release the lease and ask the SDK to settle usage.
- Refresh the note snapshot and display the resulting receipt when cost data is available.
This is a payment workflow for OpenRouter inference. The toolkit is not a universal payment header that can be attached to any arbitrary endpoint today. Making that distinction keeps integrations concrete and avoids promising coverage the client does not expose.
What an application should show
The caller needs more than an animated spinner. Before sending, show the selected model and available note state. While the proof and lease are being prepared, show those as distinct stages. Stream response text as it arrives. Afterward, show settlement and any remaining uncertainty about the final local cost.
These stages are represented by useBurn: proving, leasing, streaming, settling, settled, and failed. A failed call should show the catalog's readable message near the action that failed. A response that streamed successfully should still retain its own settlement status.
The useful abstraction is small and honest: one funded note, a bounded request, a visible result, and a balance that can be checked again. Explore the React hooks for the implementation surface.