How to Price an API for AI Agents

An agent does not need a seat as its billing unit. It needs a price for the bounded action it is about to take—and a maximum it can authorize before that action runs.

Seat pricing works when a named person gets ongoing access to software, support, and capacity. Agent demand can be less regular: one valuable request today, many small requests tomorrow, and none next month. For that buyer, the useful commercial unit is usually the result, input, output, or workflow being purchased—not the identity making the request.

Subscriptions can still suit customers that want reserved capacity, consolidated billing, or predictable monthly spend. The point is not to eliminate them. It is to stop treating the seat as the default unit for autonomous work.

Start with one billable action. Then define the price rule, quote, and execution limit that let the buyer evaluate it before work begins. Pricing and authorization are one design problem: the unit says what is bought, and the bound says what may be approved.

An explainable machine quote

1. 01Cost floorInfrastructure, upstream inputs, failures, payment, and support
2. 02Billable actionThe result or unit the buyer can understand before the request
3. 03Price ruleFixed, metered, output-based, or a base plus variable usage
4. 04Buyer guardrailsMaximum charge, expiry, accepted method, and usage limits
5. 05Transaction recordPrice version, measured usage, final charge, and outcome

Price the action, not the agent

The first pricing decision is not the amount. It is the unit.

A useful billable action has a boundary the seller can meter and the buyer can recognize. Depending on the product, that might be one verified record, one minute of compute, or one completed workflow.

“One API call” is sometimes enough. But two calls to the same endpoint can consume different amounts of compute or return different volumes of data. The resulting value can also differ. If the call is not a stable economic unit, price the input, output, or result that is.

Do not confuse identity with the charging unit. An API key can identify a lasting customer relationship while each request is priced by usage. A per-request payment can serve a buyer that has no account. The pricing model should describe what is bought without forcing every buyer through the same onboarding path.

Choose the rule that matches the work

Four useful starting rules are fixed per action, metered input, metered output, and a base amount plus variable usage. Choose the simplest rule that makes the maximum charge calculable before execution and the final charge reproducible afterward.

Fixed per action

Charge one amount when “one” means roughly the same amount of work every time. The buyer gets a price it can compare and authorize; the seller takes on the cost variance, so the action needs hard input and output limits.

Metered input

Charge for a quantity known before execution, such as records submitted, bytes uploaded, or seconds of reserved processing. The buyer can calculate the maximum before committing, while the seller can meter the resource the service actually consumes.

Metered output

Charge for a quantity known only after execution, such as generated tokens, enriched rows, or delivered media. This rule needs a buyer-approved maximum and a reliable meter. The seller returns the measured quantity and final charge with the result.

Base plus variable usage

Charge a fixed amount for starting the work, then add rates for the quantities that drive cost or value. This is useful when every request has a meaningful setup cost but the result can expand. Use the fewest dimensions that explain the charge.

Your cost floor is not your price

Before choosing an amount, calculate the cost floor for the largest request you intend to accept. Count variable infrastructure and data transfer, paid upstream APIs, models, or datasets, and the expected cost of retries, timeouts, and failed work. Then add payment, conversion, and settlement costs, plus an operating reserve for support, refunds, and reconciliation.

The cost floor answers “what must this request recover?” It does not answer “what is the result worth?”

A cheap request can produce a decision that would be expensive to replace. A costly request can still produce a commodity result. Ask how much work the buyer avoids and how scarce or timely the result is. Also account for the seller's risk and how directly the output advances the buyer's objective.

This creates a useful starting range. The cost floor informs the lower bound. The value of the result, available alternatives, competition, and buyer willingness to pay shape the upper bound. Start inside that range, then review real request shapes and buyer behavior instead of defending the first number forever.

Turn the rule into a bounded quote

When an agent makes a new purchase, it needs a machine-readable offer before paid work begins—unless an account-level agreement has already supplied the authorization and budget.

The offer identifies the protected resource and price version, then names the billable action. It states the fixed amount or complete pricing formula, including every metered quantity and unit rate. It also specifies the currency or asset, accepted payment method, maximum possible charge, expiry, and the quote identifier that will appear in the transaction record.

The maximum connects pricing to authorization. For a fixed-price action, the quoted amount is the cap. For variable work, the offer includes the base amount where applicable, the unit rates, and a maximum the buyer can approve. The seller rejects requests outside the quoted bounds, records actual usage, and settles no more than that maximum.

The x402 up-to scheme is one protocol pattern for this. The buyer authorizes up to a maximum, the seller determines the actual charge from resource consumption, and settlement cannot exceed the authorized amount. The authorization is single-use and time-bound.

The scheme is only one way to carry the authorization. It does not choose the billable unit or rate; the seller still owns that commercial decision.

A cap is not enough on its own. Set maximum input and output sizes, a deadline, no-charge and partial-charge rules, and idempotency behavior. Return an error that tells the agent whether to retry, request a new quote, or stop. Dashboard alerts and billing thresholds can help an operator notice accumulating spend, but they do not enforce these request-level limits.

Version prices instead of rewriting history

A price change should create a new version. It should not alter the terms attached to an earlier quote or completed transaction.

Stripe recommends creating a new Price when an amount changes, switching new purchases to it, and making the old Price inactive. The same principle is useful for agent requests: preserve the accepted price rule, even after a replacement becomes current.

Give every quote an expiry. A short validity window limits exposure to changing upstream costs, exchange rates, or capacity. It also creates an unambiguous retry rule: honor an accepted quote while it remains valid, and issue a new quote after it expires.

Do not silently reprice a retry. If the first request executed or created a charge, the idempotency record should return that outcome. If no work started and the quote expired, return a new commercial offer that the buyer can accept or reject.

A first-endpoint pricing worksheet

Use one real endpoint. Avoid designing a universal pricing system before one action survives the exercise.

1. Name the result. Complete the sentence: “The buyer pays for one ___.” If the blank says “API call,” confirm that calls have a comparable cost and outcome.
2. List the variables. Write down every input, output, and external dependency that can materially change cost or value.
3. Calculate the floor. Estimate the largest allowed request, including failed work, payment, and operating overhead.
4. Choose one rule. Use fixed, metered input, metered output, or base plus usage. Remove any dimension that does not help explain the charge.
5. Set the bounds. Define input limits, output limits, maximum charge, expiry, and no-charge or partial-charge conditions.
6. Write the quote. Make the resource, price version, formula, units, currency, accepted method, cap, and expiry explicit.
7. Try to break it. Price the smallest request, the expected request, the largest allowed request, a failure before work, a failure after partial work, and a retry after a lost response.

The worksheet is complete when the buyer can authorize the maximum, the seller can protect the cost floor, and finance can reproduce the final charge from the recorded quote and usage.

The agent purchase flow shows where quote, commitment, execution, charge, and settlement fit together. An Agent Paid. Now What? follows the commercial record from that quote through payout and later corrections.

The agent that buys from you may never read your pricing page. It will evaluate the quote. Make that quote precise enough to authorize before work and explain after the request is over.