A new payment primitive matters when it changes what a developer can build. OpenZK's current implementation combines a prepaid browser note with proof-backed, metered OpenRouter inference. That combination is especially interesting when work arrives in small, unpredictable bursts.
1. A research assistant with uneven demand
One investigation may need two model calls; another may need forty. Funding a note gives the assistant a bounded budget that can cover those bursts. Each request pays for the work it actually uses, while the application can show the remaining private balance after settlement.
The assistant still needs rules for which prompts to send and how much to spend. A private payment does not decide whether a model call is appropriate. It gives the calling software a way to pay for the call once that decision is made.
2. A developer tool used occasionally
A code editor might offer an expensive analysis only when a developer asks for it. Requiring every occasional user to open another provider account creates friction out of proportion to the task. A prepaid note can support a small number of deliberate requests, with a clear path to withdraw what remains.
This works best when the interface shows the action's payment state plainly: ready to request, proving, streaming, and settling. It should never imply that an estimated or delayed local receipt is a final onchain amount.
3. A browser application with limited sessions
A team may want users to access inference without issuing a durable provider API key to every browser. OpenZK's current flow grants short-lived inference access for a bounded session. The browser requests it after producing a valid payment proof, and the lease is retired after use.
The application still has to protect local note state. Public browsers are not secret-free environments, and the underlying SDK's storage and recovery procedures remain part of the product design.
4. A software agent with a fixed allowance
An agent can be useful without being allowed to spend indefinitely. A funded note sets an overall prepaid balance; an inference lease applies a per-session limit. Together, those bounds are easier to reason about than an unrestricted credential charged to a central account.
The present React toolkit is browser-oriented. An unattended server agent would need an integration that supports its runtime and key handling; the package's proving worker requires a real browser. We describe this scenario as a design direction, rather than a supported headless deployment.
5. A product testing a new pricing model
Some products do not know yet whether users want subscriptions, bundles, or occasional paid calls. A per-request payment path allows a small, explicit experiment: fund a note, make a request, see the result, and withdraw the remainder. The product still has to make pricing understandable and choose a sensible session limit.
These examples share a pattern: a payer wants to authorize a specific piece of work without creating another durable billing relationship. The current product demonstrates that pattern with AI inference. Read how the note works and what its privacy guarantee covers.