# Pricing an API when the customer is an agent.

Look at the public x402 numbers from late April 2026: the protocol had cleared roughly 165 million transactions and around $50 million in cumulative volume — an average call worth under thirty-one cents. That is not a human pricing pattern. No human signs up for an API, reads the docs, and then transacts a third of a cent at a time, 165 million times. A machine does.

The buyers behind those calls did not fill in a signup form. They did not pick a plan, agree to a monthly minimum, or get a per-seat license. They have a wallet, they read a price off an HTTP response, they pay, and they move on — and if your price is a cent too high or a clause too confusing, they call the API next to yours instead. The customer is an autonomous agent, and almost every assumption baked into the way APIs have been priced for twenty years assumes a customer that is not.

This post is about repricing for that buyer. Our [field notes on the x402 economy](/blog/x402-economy/) covered the rail itself — the HTTP-402 micropayment mechanics, the settlement profile, the gas economics; this post takes the rail as given and asks the harder question on top of it: when the thing reading your pricing page is software, what has to change about metering, legibility, anti-abuse, and discovery.

## The shift — no card, no procurement cycle

Name what changed, because every downstream consequence falls out of it.

The traditional API customer is a human inside a company. They have a credit card, or a procurement department, or both. They evaluate on a timescale of days to weeks. They sign up — an account, accepted terms, a key. They commit, monthly or annually, because committing is how humans and finance departments prefer to buy: predictable line items, one renewal to track. The whole shape of API pricing — a free tier to earn the signup, seats to price the team, annual plans to lock the commitment — is a toolkit for converting and retaining _that_ buyer.

The agent buyer has none of those properties. It has a wallet, not a card. It has no procurement cycle — it evaluates and buys in the same millisecond. It does not "sign up," because over a rail like x402 there is no account to create: it makes a request, gets an [HTTP 402 with payment requirements](/blog/x402-economy/), signs a stablecoin transfer, and proceeds. It does not commit, because committing is a human risk-management instinct it does not have — it re-decides, from scratch, on every call. And there is no team behind it to count seats for; there is one wallet and a stream of calls.

This is not a new tier to add to your pricing page. It is a customer the pricing page was not built to serve.

## Why human pricing models break, one by one

Run each instrument in the standard toolkit against the agent buyer. They do not bend; they break.

| Pricing instrument              | Built for                                  | What the agent does to it                                                                         |
| ------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| Monthly / annual seat plan      | A team of humans, priced per head          | No team, no heads, no commitment — there is nothing to count and nothing to lock.                 |
| Signup-gated free tier          | Earning a human's account creation         | No signup to gate. A free tier with no account is just free, and free gets drained.               |
| Tiered plans (Pro / Enterprise) | A human picking a bucket, once             | The agent reads the per-call price and ignores the buckets. Tiers are a UI for a human.           |
| Annual commitment / minimum     | Revenue predictability, locking a buyer in | The agent will not pre-commit. It spends what this call costs and re-evaluates the next.          |
| Volume discount on contract     | A negotiated, forecasted relationship      | No negotiation, no forecast. Volume pricing must be machine-readable and automatic, not in a PDF. |

The free tier fails the most expensively, and we come back to it below. The pattern across the whole table is one thing: every human pricing instrument manages a _slow, committed, identity-bearing_ buyer, and the agent is a _fast, uncommitted, account-less_ one. You cannot tier your way to serving it. You have to meter.

## The rail makes the price a machine-read field

Per-call pricing for a machine buyer is only practical because the rail exists, and x402 is the one carrying the volume above: the agent requests a resource, the server answers `402` with payment requirements, the agent signs a stablecoin transfer authorization and retries, the response comes back — no account, no balance to top up. The [x402 notes](/blog/x402-economy/) cover the mechanics; the point here is what the rail demands of your pricing in return.

It makes the price a structured field. An x402 `402` response carries a `PaymentRequired` object: a `resource` block describing what is sold, and an `accepts` array of payment requirements, each with a `scheme`, a `network`, an `amount` in atomic token units, the `asset`, and a `payTo` address. There is no pricing page in that exchange. There is a JSON field called `amount`, and the agent parses it.

That single fact reorders your priorities. For a human, the price competes on a page alongside brand, design, social proof, and a free trial. For an agent, the price competes as a number against another number. The framing, the anchoring, the "most popular" badge on the middle tier — all invisible to the parser. What is left is the number and whether the agent can predict it.

## Metering — price the real cost driver

If tiers are out and the unit is the call, the first real decision is what a call costs — and the lazy answer, a flat price per request, is usually wrong.

The principle is old: meter the thing that drives your cost. If every request costs you about the same to serve — a simple lookup, a fixed query — a flat per-call price is honest; do not manufacture complexity the cost structure lacks. But many APIs do not have flat costs. An LLM proxy scales with tokens generated; a data API with rows or bytes returned; a compute endpoint with the work the request triggered. Price those flat and you have built an adverse-selection machine: cheap calls subsidize expensive ones, and a comparison-shopping agent routes its cheap calls to you and its expensive calls away, leaving you the unprofitable half.

| Metering unit           | Fits when your cost scales with             | Watch out for                                                   |
| ----------------------- | ------------------------------------------- | --------------------------------------------------------------- |
| Per call (flat)         | Nothing much — every request costs the same | Adverse selection if costs are actually variable                |
| Per token               | Generated or processed text — LLM endpoints | Token count is unknown before the call; quote a rate, not a sum |
| Per unit returned       | Volume of data the request yields           | A cheap-looking call returning a huge result; cap it            |
| Per unit of useful work | A discrete completed outcome                | Defining "useful" crisply enough not to be arguable after       |

The hard case is variable cost: the agent wants the price _before_ it commits, and a per-token charge is not knowable until after. x402 has a scheme for exactly this — `upto` authorizes a transfer of up to a stated maximum and settles the actual amount, possibly less, possibly zero, once consumption is known; the spec lists its use cases as pay-per-token generation, per-byte transfer, and dynamic compute. That lets you meter the real cost driver and still hand the agent a hard ceiling it can reason about before it signs. Meter the cost driver; quote the rate and the cap; let the rail settle the truth.

## The agent's point of view — legibility beats cleverness

Design pricing for an agent and you have to model how it buys, because it does not buy like a person.

An agent picks the cheapest API that does the job. It is not loyal — loyalty is a human heuristic for managing the cost of evaluation, and evaluation is nearly free for software. It is not impressed by your brand, not anchored by your "Enterprise" tier into feeling good about "Pro." It reads a price, checks the endpoint meets its requirements, compares against alternatives, and routes. Every call is a fresh procurement decision with switching cost near zero.

Two things follow, both the opposite of how human pricing is tuned.

**Legibility beats cleverness.** A human pricing page can be clever — bundles, anchors, decoy tiers — because clever works on humans. An agent's "reading" is a parser extracting a number. A model the agent cannot cleanly parse is not subtle; it is illegible, and an illegible price loses to a legible one because the agent can _act_ on the legible one. Cleverness aimed at a machine is invisible; the friction it adds is not.

**Predictability is a feature.** An agent — or the engineer who built it — has to bound its spend; the [agent-spend-rails](/blog/agent-spend-rails/) discipline of declared, enforced ceilings applies in full. A stable price the agent can quote before the call lets it plan: it knows the cost, it knows the budget fits, it proceeds. A price that swings, or that is unknowable until after the call without an `upto`-style ceiling, forces the agent to over-reserve budget or skip you. Between two APIs of equal capability, the one whose price an agent can predict wins the routing decision.

The summary an agent would write of your pricing, if it could: _is it cheap, is it legible, is it predictable._ Nothing else on a human pricing page survives the translation.

## Anti-abuse — the free tier is an attack surface

Pricing for agents is not only about willing buyers. The properties that make an agent a frictionless customer make an abusive one a frictionless attacker, and the free tier is where that lands hardest.

Restate the problem sharply. A free tier works for humans because account creation is friction and friction caps abuse. A per-call rail removes the account. A free tier fronted by nothing but an IP-based limit is trivially farmed — agents rotate addresses, and the limit was never bound to anything scarce. The honest options are narrow:

- **Drop the free tier; price the floor very low.** If the smallest real call costs a fraction of a cent, a sub-cent price _is_ the trial — the agent can afford to evaluate you, and there is no faucet to farm.
- **Gate it on something an agent cannot mint for free.** Proof-of-personhood is the interesting development: World's AgentKit lets a service offer a fixed number of free requests _per unique human_ rather than per wallet or per IP, so an agent can still trial the service but one operator cannot multiply the allowance by spinning up agents. Even this has a limit — a payment proves nothing about how many humans are behind a swarm; one person can run thousands, each paying its own way. Anti-abuse for agents must bind to something scarcer than a wallet.
- **Keep a free tier only behind real identity.** If a free tier matters to your funnel, gate it on a verifiable, portable agent identity — the kind [ERC-8004](/blog/erc-8004-agent-identity/) standardizes, which an agent accumulates a reputation against — not an account it discards in a second.

Two more anti-abuse questions change shape for a machine buyer.

**Rate limits are a pricing parameter, not just an ops setting.** For a paying agent, the limit is part of the product — it bounds throughput, and the agent needs it to plan. Publish it in machine-readable form alongside the price. An undisclosed limit the agent discovers by hitting a wall mid-task is, from its side, an unpredictable price.

**Failed-call and refund semantics have to be defined.** A human shrugs off an occasional failed request. An agent paying per call needs a rule: if the call is paid for and the response is an error or empty, what happens? x402's base "exact" payment is a push transfer, irreversible once executed, so any refund is your business logic, not the protocol's. Decide it and make it legible — charge nothing on a server error, or charge and expose a refund path. An undefined failure policy is, again, an unpredictable price; the buyer-side controls in the [spend-rails notes](/blog/agent-spend-rails/) exist because so many endpoints leave it undefined.

## The checklist for a price an agent can buy

Pull the requirements into a gate to clear before you put a price in front of a machine buyer:

- [ ] The unit is granular — the smallest sensible billable unit, priced on its own, no minimums and no buckets to size into.
- [ ] The unit is the real cost driver — flat per-call only if costs are genuinely flat; otherwise per token, per returned unit, or per unit of useful work.
- [ ] The price is legible — a number, a unit, a currency, with no clever bundling or decoy tier behind the `amount` field.
- [ ] The price is predictable — fixed per unit, or a published rate plus a hard `upto`-style ceiling. Never knowable only after the call.
- [ ] The price is quotable before the call, without a paid side-effecting request — ideally a cached, signed quote the agent can read ahead.
- [ ] Rate limits and refund/failed-call semantics are defined and machine-readable, and they agree with the price.
- [ ] The free tier is either gone (floor priced near zero) or gated on proof-of-personhood or a verifiable identity — never on a free account.

None of this is a discount. It is the same revenue in a form a machine can transact against. An agent will pay a fair price all day; what it will not do is parse a page built for a human and feel persuaded.

## Discovery — how an agent finds a priced API

A price designed for an agent is worthless if no agent reaches the endpoint. Human distribution — search, content, word of mouth — is distribution for human discovery. The agent finds APIs differently, and discovery is now part of pricing, because an agent's first question on finding you is _what does it cost_.

Two x402-ecosystem developments are worth knowing. The protocol has a discovery extension, `bazaar`, that lets a resource server declare its endpoint specification in machine-readable form — method or tool name, input parameters, output shape — so a facilitator can catalog and index it; discovery becomes a structured read, not a human browsing docs. And in April 2026 Coinbase launched **Agentic.Market**, a public directory of x402-enabled services built so both human developers and autonomous agents can discover, compare, and integrate priced services, organized into categories like data, search, reasoning, and infrastructure.

The consequence for how you price: an agent discovering you through a directory or a `bazaar` index compares you, side by side, against every substitute in the category, on price and capability, with no brand and no salesperson in the loop. That is the most ruthless price-comparison environment an API has been sold into. It rewards exactly the pricing this post argued for and punishes cleverness, because a listing renders your price as a number next to a competitor's.

## The shift underneath all of it

Every line of that checklist is one consequence of a single change, and the change is worth naming directly: pricing has stopped being a persuasion surface and become a data interface. A human pricing page is an argument — tiers, anchors, a free trial, a brand. A price an agent reads is an API response: a number in a `402`, compared against a competitor's number, every call, with switching cost near zero. The firms that win the agent buyer will design the price like what it now is.

## Reading list

- The [x402 economy field notes](/blog/x402-economy/) — the rail this post sits on; the per-call payment mechanics, settlement profile, and gas economics, so this post did not re-explain them.
- The [x402 specification and developer documentation](https://docs.x402.org/) — the `PaymentRequired` schema your price is delivered in, and the `upto` scheme for metering variable cost with a ceiling.
- The [Agentic.Market launch](https://www.coinbase.com/developer-platform/discover/launches/agentic-market) — a public directory of x402-priced services, and a concrete look at the comparison environment a machine buyer shops in.
- World's [AgentKit announcement](https://world.org/blog/announcements/now-available-agentkit-proof-of-human-for-the-agentic-web) — proof-of-human as a way to offer a free tier per unique person rather than per wallet.

Price for the buyer you have. It reads the number, does the math, and has already found your competitor.