The Subscription Wall Has a Small-Payment Problem

Brian Armstrong put the idea plainly: “you shouldn't need a monthly subscription to read one article - your agent can just fetch it for you, and pay the business for that one article.”

Sounds obvious. Card rails make it awkward.

Consider a 25-cent article sold through a US card payment. Stripe charges 2.9% plus 30 cents per payment. The fixed fee alone is larger than the article’s entire price. If the article sits inside a Substack subscription, Substack keeps 10% of subscription revenue, with Stripe fees on top.

Subscriptions bundle many small purchases into one larger charge because card economics punish tiny transactions. That works for regular readers. It is a strange fit for an AI agent that needs one document, right now, to finish one task.

Lightning changes the shape of the sale. A server can price a single article or API request in sats. The agent can pay for that exact resource and continue its work.

HTTP Already Has a Payment Door

HTTP 402 is the status code for “Payment Required.” The flow it implies is short.

A client asks a server for something. The server replies with a 402 response and payment instructions. The client pays, supplies proof, then receives the requested resource.

Cloudflare is testing one version through Pay Per Crawl. Its closed beta lets a crawler present payment intent and receive an HTTP 200 response, or receive an HTTP 402 response with pricing. Cloudflare acts as the merchant of record.

That is one model for paid machine access. L402 provides a Bitcoin-native path using Lightning.

With L402, the server answers a request with HTTP 402, a token, and a Lightning invoice. The client pays the invoice. Lightning gives the client the payment preimage, which proves that invoice was paid. The client retries the request with the token and preimage. The server verifies them and returns the content or API response.

The server can perform that verification without looking up the payment in a payment database. The proof travels with the request.

Aperture, Lightning Labs’ L402 proxy, supports per-request pricing and surge pricing. That makes the payment unit match the work unit. One request can have one price. A more expensive request can have another. Pricing can also change when demand changes.

Sats4Tokens Shows the Full Loop

Sats4Tokens is a useful working example because the payment ends in a credential an agent can immediately use.

Built at bitcoin++ Berlin 2026, it lets a buyer pay sats with Lightning or Cashu ecash and receive an AI API key capped at exactly the amount purchased. There is no signup and no email. Its README sums up the account model in five words: “the key is the account.”

On Oct. 2, 2026, the project’s README recorded a $1 mainnet purchase for 1161 sat. The payment produced a key, and that key was used for a real model call.

The sequence is compact. Pay. Receive a key with a defined cap. Make the call. No monthly plan needs to be created and remembered for a one-off job. No account profile needs to exist before the agent can act.

That model also makes spending boundaries concrete. The key carries only what was purchased. The agent does not receive an open tab at the bar.

What Loop XXI Is Building

Loop XXI builds an L402 gateway for agents. Its job is to put a Lightning payment boundary in front of an API request, verify payment proof, and release the response.

We are also prototyping pay-per-article access. In that prototype, the price rises while a piece is in demand. An agent requests an article, receives the current price, pays over Lightning, and presents the proof to read it.

The pay-per-article prototype runs on test rails only. It is not live. We are using it to work through the mechanics: how the price is set, what the 402 response contains, how payment proof is checked, and how the article is delivered after verification.

The idea underneath is small. Agents buy discrete inputs. Articles and API calls are already discrete inputs. Lightning lets the payment become equally precise.

A subscription still makes sense when someone wants an ongoing bundle. A per-call payment makes sense when software needs one result. The server names a price in sats, the agent pays it, and the request continues.

That's how a machine should buy one small piece of useful work.