Usage-based monetization,on two loops.
The machine loop signs a cap, meters real usage, and refunds the difference on-chain — verifiable, no trust required. The human loop bills recurring Pix against accrued usage, and a fixed subscription is simply that same loop with the usage held constant.
Example settlement, illustrative numbers. Every real call signs its own cap and refunds against its own metered usage.
Flat pricing on variable-cost jobs is wrong for someone, every time.
Usage-based APIs — LLM calls, document processing, compute — can't price a job fairly up front. Real cost varies enormously call to call, so a flat price either overcharges the easy jobs or eats the loss on the hard ones, and a disputed shortfall becomes a support ticket, not a protocol.
- Price every call flat, padded to cover the worst-case job
- Underprice a hard job and eat the loss quietly
- Overcharge every easy job just to cover the average
- Reconcile a disputed charge by hand against server logs
- The agent signs a spending cap sized to the actual job, before it runs
- Real usage — pages, tokens, compute time — is metered against the cap as the job runs
- The unused difference refunds on-chain the moment the job finishes
- The receipt reseals with the metered number, not the estimate
Signed cap in, on-chain refund out.
Fair prices are easy; fair caps are hard. The agent pre-authorizes a signed ceiling, you charge what was measured, and the difference goes back on chain. Nobody has to trust your meter because the refund is verifiable.
The loop, in orderSign the cap. Meter the call. Refund the rest.
The calling agent signs a spending cap before the job runs — a hard ceiling, not an estimate. The API meters real usage against that cap as it executes, and codespar_pay settles on the metered amount, refunding the unused difference on-chain the moment the job finishes.
const session = await codespar.sessions.create(); // the cap is signed before the call runs — the API // can't charge past it, no matter how the job goes const job = await session.execute("codespar_meter", { cap: 0.80, currency: "USDC", metric: "pages_processed", provider: "extracta", }); const result = await extracta.extract({ file: contractPdf, capToken: job.capToken, }); // real usage is reported back through the same cap token await session.execute("codespar_meter", { capToken: job.capToken, usage: { pages: 40, computeSeconds: 61 }, }); // settles on the metered amount, refunds the rest on-chain const receipt = await session.execute("codespar_pay", { capToken: job.capToken, });
What this call chain does
- Signs a hard spending ceiling before the job runs — the API can never charge past it
- Meters real usage as the provider does the work, reported back through the same cap token
- codespar_pay settles on what was actually metered, not the original cap
- Refunds the unused difference on-chain, the moment the job finishes
Any measurable unit works as the metric.
Pages processed, tokens consumed, compute seconds — Meter doesn't care what you're measuring, only that the cap holds and the difference refunds.
Left: the real business case, live in Metered API access. Right: illustrative — the same mechanism, a different metric.
Two loops in the spec. One is live today.
The machine loop above is built end to end, merged, and running in beta behind a flag. The human loop — recurring Pix billing on accrued usage, where a fixed subscription is just that same loop with usage held constant — is next.
- Agent signs a cap before the call runs
- Usage is metered against that signed ceiling
- The unused difference is refunded on-chain, automatically
- The receipt is re-sealed with the real, metered number
- Accrued usage settling on a recurring Pix mandate
- A fixed subscription is the same loop, just with usage held constant — not a separate product
- Billing humans instead of agents, in BRL
Meter has no price of its own.
Metering is free and unlimited. It doesn't bill anything by itself. It feeds the fee on whatever settles through Gate, the same 1% (no floor, R$2.00 cap) as every other paywalled call.
BetaBeta, behind a flag.
GA General availability follows the final Sepolia and mainnet verification runs.
See metered access inside a real business case
Metered API access
Pre-authorizes a per-call cap, meters the actual usage against the quote, and refunds the unused balance before the receipt is sealed.
See the business case →Meter, answered
The machine loop — signed cap, metered usage, on-chain refund, re-sealed receipt — is live in beta, behind a flag. The human loop, recurring Pix billing on accrued usage, is next.
The difference is refunded on-chain and the receipt is re-sealed with the real number.
No. The cap is a signed ceiling the agent pre-authorized. It's the limit, not an estimate.
No. It's free and unlimited. Revenue comes from the Gate fee on whatever settles, not from metering itself.
Accrued usage settling on a recurring Pix mandate, billing humans instead of agents. It's on the near-term roadmap.
After the final Sepolia and mainnet verification runs complete.
The API or service doing the work. It calls codespar_meter with the actual measured usage once the job finishes, and that's the number settlement uses.
No. The moment usage is reported, codespar_pay settles on the metered amount and refunds the unused difference on-chain automatically — no invoice, no dispute.
Price what you can only know after it runs.
Signed cap, real usage, on-chain refund, re-sealed receipt.
meter: Beta, behind a flag.