Today we’re announcing pi402, a way to pay for AI inference with bitcoin from inside your coding agent. Using the popular Pi harness, agents pay instantly on Lightning, and there are no accounts to create, no API keys to manage, and no card numbers to enter. Sellers price inference, buyers pay for exactly what they use, and no human involvement is necessary.

---

What happens when a reversible payment meets an irreversible computation? The computation wins, it always wins. Inference is fundamentally a power-hungry service, each call draws power from the grid, and turns the joules into heat alongside an LLM response. Once the response has been generated, no message from a card network can reverse that operation, the cost has already been spent. Put up against an irreversible computation, a reversible payment can never win, it just becomes someone else's problem.

In the setting of LLM inference providers, that someone is whoever "sold" the tokens. In late August, Dax, the CEO of OpenCode, posted a screenshot from OpenCode's Stripe dashboard showing $323 million in blocked fraud over just a few days. This hidden cost is then passed on to consumers as additional fees, and eats into the bottom line of inference providers.

As a purchaser or subscriber of LLMs, you've met the other side of those defenses: required accounts before your first token, annoying and invasive fraud checks, your country isn't in the supported set, a minimum top-up when you wanted to spend just a few cents to try out a model, the API key tied back to a human who can be charged later, etc. All of these barriers are the seller’s attempts at making a reversible payment behave like an irreversible one, because their payment network of choice gives them no choice.

In other words, if you sell inference using credit cards, you aren't actually a merchant, you're a lender. You're forced to allocate scarce GPU time now, for an amount not known in advance, only to find out somewhere between 60 and 120 days later whether you were paid for it. The common barriers of a sign-up wall and a fraud check are attempts to underwrite the loan. Any fraud you'll inevitably fail to catch is the default rate.

Credit cards are fundamentally the wrong rail for inference. The only way to escape this mismatch is to pick a payment rail that matches the goods being sold. That rail is Lightning: a payment settles within seconds, and settles finally, in an irreversible manner. Since it's built on the bitcoin blockchain, there's no chargeback mechanism, as there's nothing to reverse. Either a preimage exists (used to unlock a payment) or it doesn't. With Lightning, the payment is just as irreversible as the joules.

Lightning brings two additional key properties to this setting. First, payments aren't tied to any particular identity. Credit card fraud works because a payment is a claim on an individual's identity, which can be borrowed or stolen; no equivalent applies here.

Second, amounts can be small (nearly arbitrarily so). The unit of account is the millisatoshi, one thousandth of a satoshi (roughly $0.0000008, or 0.00008 cents, at a BTC/USD rate of about $80,500). With such a granular unit of account, you aren't forced to sell access in blocks of a million tokens. In fact, you can charge for a single token! Selling inference by the token with pi402 enables buyers+sellers to sidestep problematic credit card networks, reducing transaction costs while reaching a more global audience.

The Payment as the Credential

With instant final settlement, payments for inference are solved. This just leaves the question of authorization: how does the server decide if a request has been paid for or not?

L402 answers that question by making the proof of payment and the proof of authorization the very same thing. An unauthenticated call triggers a 402 response by the server, returning an incomplete API key (a bearer credential), and a Lightning invoice. The API key (a macaroon in the case of L402) cryptographically commits to a payment identifier (the payment hash) of the invoice. Once the invoice is paid, a preimage is revealed, which then completes the API key. This conditional payment system is able to atomically produce a valid authentication credential as a side effect of completing a payment. Atomic payments that swap bitcoin for an API key take the place of usual sign ups. No user name, no email, no account, just payments.

Since we last wrote about L402, a new protocol built on HTTP 402 has emerged: MPP, the Machine Payments Protocol from Stripe and Tempo, whose HTTP scheme is the Payment HTTP Authentication Scheme (draft-httpauth-payment-00), an IETF draft that seeks to standardize a nearly identical shape. With our latest release of Aperture (v0.6.0), we implemented MPP alongside L402, as it has native support for a payment-channel-oriented session concept. Aperture is now able to advertise both payment protocols, with the buyer selecting the variant that it natively understands.

By supporting both MPP and L402, we're able to tap into an emerging common standard backed by an existing payments giant, while also supporting the protocol most likely to be implemented by a bitcoin client.

Metering: The Missing Link

L402 could always sell a request, as that's built into the protocol flow. However, inference is much more than just a single request.

A chat completion request can cost the seller a few dozen tokens, or a few thousand. The seller only learns how many after the request has been fully processed and served. Pricing each request naively means either overcharging most users or undercharging the heavy ones. Naturally, you want to charge for the thing that varies: the input and output length, which in our setting means charging per token, at a rate quoted in millisatoshis. With an accounting model of 1 msat per input token and 2 msat per output token, you end up charging roughly $0.80/$1.61 per million tokens at that same exchange rate. With Lightning, the unit of sale can now be roughly the same size as the unit of work.

A set of new APIs within Aperture permit real-time accounting for inference, on a per-request basis. A new embedded meterd price server interacts with Aperture at four key moments:

1. To return a quote for the bundle (based on the model, etc) when the 402 is minted.
2. Deducting the utilized token allotment from the bundle at inference time.
3. Verifying that the credential has enough balance to cover a given request.
4. Subtracting the final settled cost of the request once the response finishes

With this release of Aperture, the price server ships as meterd, which accepts a JSON file of input/output rates for each model. This cut is intentionally minimal, to allow users to implement their own custom logic on top of the system. A production deployment is meant to replace the basic placeholders via the same hook in the critical path of normal L402 proxying.

Lightmeter is our reference implementation of the business logic an inference provider would need to run the system end to end. It knows what each model costs, can read an upstream provider's catalog, and knows the BTC/USD spot rate. It then converts the published price in dollars per million tokens to millisatoshis per token. The daemon can optionally add some margin for the seller, handing all of that back to Aperture to broker the request. Everything is stored in a SQLite database, with an append-only accounting layer that makes reconciliation easy.

A Wallet in Every Harness

For the past year, agentic payments have been all the rage. However, no one is quite sure yet exactly what agents want to pay for. It's our view that the best fit for agentic payments today is self-fulfilling: agents want to pay for tokens to keep themselves running. The agent of choice for many developers around the world is Pi: it's small, hackable, and can be extended via its plugin system.

The pi402 extension plugs directly into Pi's model provider system, using L402 to transparently provide access to L402-gated paid inference APIs. A custom provider handles the request path end to end, applying custom policies to enforce a per-request ceiling, and daily budget. Fresh bitcoin/Lightning 402 payments are handled by an embedded Wavelength wallet, with the custom provider assembling the final credential from the revealed pre-image. All of this is hidden from the end user, and also the agent, who just sees a harness turn as normal. The extension includes a new footer that shows the wallet balance and every payment as it happens. Below we show this flow e2e, being used to pay for Kimi K3.1 Pro inference.

In the hierarchy of needs for agentic payments, inference sits at the bottom: agents can't function without inference, which is the very fuel that drives all interactions. With L402/MPP, billing can be controlled directly by the harness which drives the agent. Rate limits and budgets can be set and enforced client-side, bearer credentials such as macaroons used to delegate set budgets to distinct agents. The payment and the API key become one, with the buyer atomically swapping their bitcoin for access.

Seamless Payments via Wavelength

Before Wavelength, accessing the low cost, instant bitcoin payments of the Lightning network meant: managing channels, inbound liquidity, and a novel peer to peer daemon that needs constant uptime. At Lightning Labs, we released Wavelength to make sending and receiving on Lightning as easy as hitting a few API calls.

Wavelength is perfect for agents, as they can start receiving bitcoin over the Lightning network without any upfront set up. pi402 embeds a full Wavelength wallet into Pi via a custom wasm extension. The new /fund command prints an invoice that'll deposit funds directly into a wallet managed by the harness. A new agent can be funded within seconds. For slower on-chain deposits, a /deposit command returns an on-chain address that once sent to, will be automatically swept into the Wavelength wallet of the harness.

On the seller side, Aperture can now be hooked up directly to a Wavelength wallet making the process of selling goods and services to agents over the Lightning Network as seamless as spinning up a new web server. Sellers have all inbound liquidity managed automatically by their Wavelength wallet.

Try It

We call this suite pi402: buy or sell inference with bitcoin over the Lightning Network. As a buyer, run pi install npm:@lightninglabs/pi-402, fund the wallet with /fund, and point it at a seller. As a seller, put Aperture v0.6.0 in front of your API, run lightmeter for pricing, and start selling. The seller side drops in front of any existing inference API with no changes to the API itself.

Inference is the fuel every agent runs on, and it now has a payment rail that matches it: final in seconds, priced in inference tokens, and open to anyone with bitcoin. Everything above is open source. Try it out and see what your agent can do with pi402. 🦾