◇Paywall
2026-05-27 · 6 min read

How to price an API for AI agents (without leaving money on the table)

When the caller is a program, pricing becomes part of the API surface. An autonomous agent reads the price the same way it reads a response body — and decides whether to pay. That is a different problem from setting a monthly plan a human picks once and forgets. This post is a practical guide to pricing an API for AI agents: what unit to charge, what to anchor against, why per-request often fits better than subscriptions, and how to iterate without spending real money to learn.

It assumes you have an API and are considering adding x402 — the open HTTP-native pay-per-call protocol — as a way for autonomous callers to pay you directly. The concept post is here: What is x402?.

Step 1 — Pick the unit of value

Bad pricing usually starts with the wrong unit. The unit should match what the caller is actually paying for:

  • Per call — the simplest, fits anything where each call is a discrete thing the caller wanted.
  • Per result — better when one "call" might do meaningful work that succeeds or fails, and you only want to charge when it succeeds. Implementable as "free 4xx, paid 2xx" at the gate.
  • Per token / per item — for LLM-style APIs or search APIs where work scales with output size. Often expressed as a base price plus a per-token surcharge.
  • Per route, tiered — different routes with different prices. A "cheap" search endpoint and a "premium" enrichment endpoint can sit in the same API.

Pick one per route, not one for the whole API. Agents reason per call; let your pricing reason per call too.

Step 2 — Anchor against three reference points

Pick a price by triangulating against three numbers, in this order:

  1. Your marginal cost. Compute, bandwidth, upstream costs, model fees. The price must be safely above this — including amortised infrastructure, not just per-call compute. If you don't know your marginal cost, you don't yet have a pricing problem to solve; you have an instrumentation problem.
  2. The value to the caller. What does completing this call save them, or what does it enable them to charge their own user? An agent calling a "lookup company by domain" endpoint to enrich a sales lead might save its operator $5; charging $0.001 is foolish, $1 is reasonable, $4 is greedy.
  3. What comparable APIs charge today. Look at the public price lists of analogous APIs in the same category. You do not have to match — you have to know. A 5× premium needs a 5× story.

The order matters. Marginal cost is your floor. Value sets your ceiling. The market tells you where on that range buyers are used to paying.

Step 3 — Per-request, not subscription, for agentic clients

For human developers, a monthly plan reduces friction (one decision, one bill). For autonomous agents, a monthly plan adds friction:

  • The agent does not have an account.
  • It cannot reason about "remaining quota" the way a person does.
  • It cannot wait for an email to receive a key.
  • A single agent calling once shouldn't have to buy a plan to make one request.

Per-request pricing in USDC, exposed at the moment of the call, is the model that fits. The agent reads the signed 402 response, sees the exact price, and decides. There is no quota to manage, no plan to upgrade, no sign-up. It is also the model that supports an unlimited number of unknown callers without your engineering team having to mint keys for them.

This does not mean you must abandon subscriptions for human developers. Many APIs end up running both models simultaneously: subscriptions for known integrations that want predictability, and per-request x402 for agentic traffic. The two paths sit in front of the same API.

Step 4 — Pricing the unknown: start cheap, observe, adjust

You probably do not know what your price should be until you ship and watch what happens. A reasonable process:

  1. Start at the floor + a clear margin. If your marginal cost is $0.002/call, ship at $0.01 — high enough to be sustainable, low enough that you do not lose volume to a fictional cheaper competitor.
  2. Watch what happens for two weeks. Volume, who is calling (agents vs known developers), drop-off after the 402 (caller chose not to pay), repeat callers.
  3. Adjust in one direction at a time. If volume is healthy and you are not capacity-constrained, raise the price — that is the test you actually want to run. If callers consistently drop off at the price tag, lower it. Do not change the unit and the number in the same release; you will not know which moved the needle.

The point is not the first number you pick. The point is having a price you can change without a contract amendment with every customer.

Step 5 — Use test mode before charging anyone

Pricing changes that break payments will burn trust fast. Before any pricing change ships to live callers, run it end-to-end against a sandbox key (X402_ENV=sandbox) — the platform settles payments synthetically, so the entire challenge → pay → verify → allow loop runs without spending real USDC. Assert in CI:

  • The new price appears in the 402 response.
  • A correctly-paid request retrieves the resource.
  • A failed payment returns the right error to the caller.
  • Your existing free / authed routes are unaffected.

When the test passes, swap the sandbox key for a live key. No code change; one environment variable.

Common mistakes (and how to avoid them)

  1. Pricing too low to be sustainable. A "cheap to acquire users" story works for free trials humans see. Agents are not browsing — they are paying. Underpricing burns capacity without buying loyalty.
  2. Pricing too high to be reached. Agents have a budget per task; if your price exceeds the value of that single call, the call does not happen. You will not get feedback — you will get silence.
  3. Inconsistent prices across similar routes. Two routes that do similar work should not differ by 10×. Agents and their operators compare; arbitrary differences look untrustworthy.
  4. Hidden charges. The 402 quotes the price; the call should not surprise the caller with side-effects that charge additionally. Stick to what was quoted.
  5. Changing prices without communicating. Per-request pricing makes silent changes harder to notice but easier to make. Publish a changelog, or version your priced routes.

What this looks like end-to-end

A short example using x402: an agent calls /v1/enrich/company. The route is monetised at $0.10 USDC per call. The agent gets back a signed 402 with the price; it pays; the call returns the company data. The agent has paid once, for exactly one call. No account was created. The next agent on the next task does the same.

For the API operator, the integration is one middleware. Set the price for the route, deploy, and the rest of the work — quoting the price, verifying payments, fail-closed errors during outages — is handled by the SDK and the gate.

Get started

Share:XLinkedInEmail
All postsBrowse the SDKs