For most of the web's history, APIs were monetized the way software has always been monetized: a subscription tier, a seat count, or a bulk quota of calls bought up front and metered down. Those models work when the buyer is a company with a procurement process and a credit card on file. They work less well when the buyer is a piece of software making its own decisions about which calls are worth making, with no procurement process at all. HTTP 402's revival, via x402 and similar protocols, is a bet that the next wave of API buyers looks like the second case far more often than the first.
A tiered API plan is really a bet on average usage, not actual usage — the provider prices a tier assuming most buyers won't fully use their quota, and the buyer accepts some waste in exchange for a predictable bill. Pay-per-call pricing removes that averaging entirely: the price of one call to /api/emails/generate is $0.02, paid when that specific call is made, with nothing paid between calls. That's a strictly worse deal for a buyer who calls constantly at predictable volume — a subscription would be cheaper for them — and a strictly better one for a buyer whose usage is bursty, occasional, or unknown in advance. Both buyer types exist; the mistake is assuming only the first one matters.
Nothing about per-call pricing requires abandoning the tiered model for every caller, either. A provider can likely run both at once — a flat-rate tier for predictable, high-volume human-approved accounts, and a metered, pay-per-call path for callers that show up unannounced, make a handful of calls, and may never come back. The two aren't mutually exclusive; they're priced for different usage shapes.
A pricing page built for a procurement process shows tiers, seats, and an "enterprise, contact us" row. A pricing page that only a human can parse is a bottleneck a machine buyer simply can't get past, no matter how good the underlying API is. A pricing surface built for an agent to read needs something closer to a machine-readable rate card: a price per endpoint, discoverable from the API itself rather than a marketing page. Reading prices directly from the API rather than scraping a pricing page is a small detail that matters disproportionately once the "buyer" reading that page is a script. A machine-readable rate card and a machine-readable description of the API's shape tend to travel together — an OpenAPI spec a client can generate code from solves the second half of the same problem a live pricing endpoint solves for the first, and neither one assumes a developer is reading documentation by hand before writing the integration.
Traditional metered billing often still charges for a failed call, on the theory that the provider did some work regardless. That assumption breaks down once the caller is a machine that retries on failure far more aggressively than a person would — a strict never-charge-for-failure rule stops retries from becoming a cost multiplier, which matters more here than it ever did for subscription billing.
Retried calls raise a second, related question: if a client retries the same request after a timeout without knowing whether the first attempt succeeded, metering has to handle that safely too. Idempotency keys are the usual fix for that — they let a provider recognize a retried request as the same request, rather than quietly billing it twice, which matters more once retries are automatic and frequent rather than a rare human mistake.
None of this replaces subscription pricing everywhere — plenty of API usage is still predictable enough that a flat monthly rate is the better deal for everyone involved, and rethinking SaaS pricing for agents doesn't mean discarding subscriptions outright. What it does mean is that "how much does this cost" needs an answer a machine can read and act on in the same request that's asking, not a sales conversation. What a 402 response teaches about API economics is really this: price discovery and payment can live in the same protocol the call itself uses, instead of a separate billing relationship set up days or weeks earlier.
Whether this becomes the default for API monetization broadly, or stays a pattern specific to agent-facing APIs, probably depends on how fast the buyer side of the market, autonomous software making its own purchasing decisions, grows relative to the human-procurement side. For now, the pattern exists and is usable today, which is more than could be said for HTTP 402 during the three decades it sat reserved and unused. Whichever way the broader market moves, a provider that can't answer "what does this specific call cost, right now" in a format a script can parse is already behind the providers that can.