What happened
Lightning Labs’ GitHub repository describes pi-402 as a self-contained extension for Pi. It registers a paid model provider and wraps model requests in a payment-aware fetch flow. When the seller’s Aperture proxy replies with HTTP 402, the extension applies a budget policy, pays the invoice through its embedded Wavelength wallet, caches the resulting credential, and retries the request. Streaming is supported, and the agent loop does not need to manage the payment exchange itself. The model credential stays with the seller-side proxy, which injects it into the upstream request; the buyer holds sats rather than an API key.
The repository describes two payment options at the proxy boundary: L402 and the Payment HTTP Authentication Scheme, identified as draft-httpauth-payment-00, an IETF draft co-authored by Stripe and Tempo. In automatic mode, the buyer takes a Payment offer when the seller makes one and otherwise falls back to L402; an environment variable can select L402 explicitly. The extension is the buyer half of the arrangement. The seller is an Aperture proxy in front of an OpenAI-compatible model endpoint, with metering enabled. A token bundle is purchased, then drawn down according to what the model reports serving, with a fresh challenge when the bundle runs out. The seller chooses what it serves.
Installation uses Pi’s package manager: pi install npm:@lightninglabs/pi-402. The repository says the package includes the wallet’s WASM bundle, so installation needs no separate build or daemon. It requires Node.js 22.19 or newer and is verified against Pi 1.5.2. A fresh installation targets a local regtest setup. Users can select another network with PI402_NETWORK; mainnet additionally requires PI402_WALLET_PASSWORD. The README lists Kimi K3, Kimi K3.1 Pro, GLM-4.7, GLM-5.2 and DeepSeek V4 Flash as registered model names, while emphasizing that the seller determines which model is actually served.
The extension exposes wallet commands for checking funds and receipts, funding through a Lightning invoice, and obtaining an on-chain deposit address. The repository says the wallet is an Ark wallet and that funding through /fund uses an inbound swap. Whatever is funded becomes the maximum the agent can spend from that wallet, while configured limits further constrain requests. The default per-request ceiling is 1,000 sats; the daily cap is 100,000 sats. The request ceiling is checked against the quoted total outflow, so it must exceed the seller’s bundle price or the payment policy declines it.
What the archive adds
We have not covered this before; it opens a new thread. New Runtime’s earlier coverage of pay-per-token inference concerned E2E Networks’ Blaze, an inference API, rather than a Pi extension that pays a seller through a wallet: the earlier Field Note. This is a new implementation event, not a new fact about Blaze.
Trend signal
This release supports the idea that protocols can form an interoperability layer between agents and services: the extension handles both L402 and a Payment HTTP Authentication Scheme offer without changing Pi itself. That remains an early signal, not proof of broad interoperability; the payment path requires a compatible seller and the repository describes a draft scheme. Agent protocols become the interoperability layer.
Connections to other events
New Runtime’s earlier coverage described Machine Payments Protocol as a way to put payment into an HTTP request, allowing an agent to pay for an API and retry after a 402 response. pi-402 meets that same broader problem from the buyer side: a Pi extension and wallet handle payment for inference, while the seller provides an Aperture proxy. The repository’s support for a Payment HTTP Authentication draft alongside L402 is a concrete, though still experimental, implementation detail.
Why it matters
Agent payments can remove a practical dependency on giving an autonomous process a reusable API credential. In this design, the buyer spends sats from a wallet, the seller keeps the model key, and the buyer’s funded balance and policy limits bound its exposure. That is a useful security and billing boundary to test when building agents that call metered services.
The important qualification is that the extension does not make inference itself generally available or eliminate operator work. A team needs a compatible seller, a proxy configured for metering, and a wallet on the desired network. It also needs to understand the wallet’s recovery and secret-storage model. The repository says the seed is written under ~/.pi402/wallet/seed.txt on first session; on mainnet, plaintext seed handling is restricted unless the user explicitly opts in. Those details make this a hands-on integration for teams exploring agent commerce, not a drop-in replacement for a hosted model API.
What happens next
- Compatible sellers will determine whether pi-402 becomes practical beyond demonstrations (3 months, 55%). Watch for: publicly reachable Aperture deployments that publish supported models and bundle prices.
Limits and uncertainty
The repository documents the extension and its intended buyer flow, but it does not establish adoption, production reliability, or the number of working sellers. It lists zero stars on the page captured here, which is not a measure of technical quality or future uptake. The seller chooses the actual model and token-bundle price, so listed model names do not guarantee availability or a particular service level. The repository says a hosted seller is not yet available as part of the project. It also states that payment sessions are unsupported because the wallet cannot yet supply a return-invoice minter. The repository’s mainnet instructions and safeguards do not independently establish the security of the wallet, proxy, swap operator, or payment flow.
Skill to build now
If you are evaluating agent-paid inference, run the repository’s regtest or signet demonstration before connecting real funds. Configure a small per-request ceiling below your intended experiment budget, inspect the receipt ledger, and verify that the proxy meters the served tokens as expected. Treat seed recovery and seller trust as separate review tasks before attempting mainnet.
Reader takeaway
pi-402 shows how a coding agent can pay a compatible inference seller without carrying the seller’s API key. The buyer-side integration is real and documented, but it is not a hosted service: builders still need a metered Aperture seller, must configure budgets, and should treat the wallet and mainnet path as experimental until independently tested.