Kunzum  /  Blog  /  How to price an API for AI agents

How to price an API for AI agents

Price an API for AI agents by metering work rather than requests, starting from marginal cost and publishing a defensible multiple when no comparable exists. Meter what you can measure at the edge and what callers can predict, then track tester-to-payer conversion and cost-to-revenue drift.

Agentic payments7 min read

How to price an API for AI agents

In short

  • Price agent API calls by the work done, not request count: per compute-second, token, byte, result, or access window plus quota fit different workloads.
  • The x402 market showed about $28,000 in real daily volume at an average payment near $0.20, spread across roughly 131,000 daily transactions.
  • Payments of $1 or more rose from 49% of x402 volume in early 2025 to 95% by early 2026, a signal that sub-dollar pricing is drifting upward.
  • Daily x402 transactions fell from about 731,000 in December 2025 to about 57,000 in February 2026, so transaction counts are not demand; tester-to-payer conversion improved 4x in six months.

This is part of the Kunzum reference on What is x402? The plain-English guide to agentic payments, which carries the figures this post draws on and the date each one was checked.

Price the work, not the request

Per-call pricing is the default because it is the easiest thing to meter. For agent traffic it is usually the wrong unit.

A single call can return a small status field or trigger a ninety-second inference job. Price both the same and your cheap calls subsidise the expensive ones, until an agent finds the expensive endpoint and settles in. Agents do not get bored. They retry.

What you sell scales with work, not with requests:

UnitMetered onFits whenBreaks when
Per callrequest countevery request costs about the samerequest cost varies by an order of magnitude
Per byte or tokenpayload or contextretrieval, corpus access, grounded answersshort requests carry heavy compute
Per compute-secondexecution timeinference, sandboxed code, long jobsyou cannot measure it without adding latency
Per resultsuccessful outputsearch, enrichment, matchinga result is hard to define in a contract
Access window plus quotatime or volumesteady, predictable agent workloadsagents burst and then go quiet

AWS Lambda Pricing meters serverless functions by request count plus gigabyte-seconds of compute, demonstrating per-compute-second metering as a real, durable unit rather than a hypothetical alternative. OpenAI API Pricing prices its API per token of input and output, a live example of the "per byte or token" unit being the standard meter for retrieval- and inference-heavy endpoints.

Two rules survive every pricing page I have read. Meter something you can measure at the edge without a second round trip, and meter something the caller can predict before it calls. An agent that cannot estimate the cost of a call will either avoid you or call you once and cache the result forever. Stripe's documentation for usage-based billing enumerates metering models (per-unit events, per-seat, aggregated usage) that a payment processor will actually record, supporting the rule that you should meter something measurable at the billing boundary.

If you charge per call anyway, price tiers by payload and compute class. Three bands is enough. The x402 Bazaar is where agents discover what you charge, so the number has to be legible before anyone commits.

Set the first number when there is no comparable

Nobody can tell you what your endpoint is worth from the available data. There is no public index of agent-facing API prices, and the settlement data that exists describes a market that is still mostly not agentic.

Take the two figures that bracket most of it. According to TRM Labs, roughly $52.7M settled across 198.9 million x402 settlements since May 2025, but only $25.62M screens as plausible commerce, and just 0.6% to 7.5% of that appears agentic. 99.6% of the value settled in USDC. According to CoinDesk, citing Artemis, real daily x402 volume runs around $28,000 at an average payment around $0.20, spread over roughly 131,000 daily transactions.

So the revealed average is about twenty cents, and the total pool is small. Neither number tells you what your endpoint is worth.

Start from your own marginal cost. Add compute, storage, egress and the cost of the human who fixes it when it breaks. Per the x402 protocol documentation, the protocol charges no fee of its own: payers cover network fees only, so settlement is not the line item to price against. That pushes the whole decision onto compute and engineering time.

Then multiply. If you cannot find a comparable, set the first price at a multiple of marginal cost you can defend in writing, publish it, and treat it as a hypothesis with a review date. Anything more precise is invented.

Read the signal that the price is wrong

Two signals, and they point in opposite directions.

Too low: your cost per unit climbs faster than your revenue per unit as volume grows. A single counterparty starts to dominate your traffic. Agents retry aggressively on errors, because retries are cheap for them and expensive for you. The Chainalysis write-up shows payments of $1 or more rising from 49% of volume in early 2025 to 95% by early 2026, which is a market drifting upward and away from sub-dollar pricing.

Too high: 402 responses stop converting to settlements. Agents fall back to cached answers or to a free competitor. Repeat calls from the same agent stay flat while the count of one-off probes keeps rising.

Ignore transaction counts as a demand signal. BlockEden.xyz reports daily x402 transactions falling from about 731,000 in December 2025 to about 57,000 in February 2026, a decline of over 92%. Chainalysis notes that PING, a pay-to-mint experiment, lifted transactions by over 10,000% in a single week. Both are real numbers about incentive programmes, not demand. The figure worth watching is tester-to-payer conversion, which Chainalysis reports improved 4x in six months.

Measure the crawler before you price it

You cannot price a caller whose behaviour you have not seen. That applies to crawlers before it applies to agents.

Cloudflare publishes the ratio of how often a crawler visits to how often it refers traffic back. For the week of 19 to 26 June 2025, the measured crawl-to-refer ratios were nearly 71,000 to 1 for Anthropic, 1,600 to 1 for OpenAI, 202.4 to 1 for Perplexity, 40 to 1 for Microsoft and 9.4 to 1 for Google. Those are 2025 figures, and any page quoting them has to say so.

That gap is the quantity you are trying to price. AI Crawl Control gives publishers a way to sort crawlers by purpose instead of blocking them wholesale, which is the prerequisite for charging them differently. Pay Per Crawl turns that into revenue, with Cloudflare acting as merchant of record over HTTP 402, in private beta. The Monetization Gateway, published 1 July 2026, extends the same idea to any protected asset.

Scale matters here. According to W3Techs, Cloudflare sits in front of 25.8% of all websites as of the September 2026 survey, and its chief strategy officer has said the network sends over a billion HTTP 402 responses a day, a remark quoted by CoinDesk in May 2026. Most of those are refusals with no price attached. A refusal is a price of infinity, and it is the price most publishers currently charge.

Before you quote a number, instrument the caller. Log who arrives, what they take, how often they return, and whether they ever send a referral. Then set the unit, set the multiple, pick a review date. What AI recommends instead is a useful cross-check on whether your price changes your visibility in answer engines, and how the corpus was measured explains why the figures above are worth arguing with.

A price you cannot check is a guess with better formatting.

The method is short. Meter work, not requests. Anchor on marginal cost, because the market average is too thin to anchor on. Watch conversion and repeat payment, never transaction totals. And find out which crawlers are already taking your content before you decide what to charge the agents that follow them.

Questions

Why is per-call pricing usually the wrong unit for agent traffic?

A single call can return a small status field or trigger a ninety-second inference job. If you price both the same, cheap calls subsidise the expensive ones until an agent finds the expensive endpoint and settles in. Agents do not get bored, and they retry.

How do I set a first price when there is no comparable for my endpoint?

Start from your marginal cost. Add compute, storage, egress and the cost of the human who fixes it when it breaks. If you cannot find a comparable, set the first price at a multiple of marginal cost you can defend in writing, publish it, and treat it as a hypothesis with a review date.

What signals show my agent endpoint price is wrong?

Too low looks like cost per unit climbing faster than revenue per unit as volume grows, one counterparty dominating traffic, and agents retrying aggressively on errors. Too high looks like 402 responses not converting to settlements, agents falling back to cached answers or a free competitor, and repeat calls from the same agent staying flat while one-off probes rise.

Published 2026-09-20. Written by Narender Charan, who runs Kunzum.