An AI agent asks a research API to evaluate a market. The provider receives one request, sends 72,000 tokens through several models, invokes nine tools, retries two failed steps, and returns one completed report.
How many units did the customer use?
The answer could be one API call, 72,000 tokens, one task, or one successful outcome. Each number is technically defensible. Each also produces different incentives, margins, disputes, and spending risks.
That is the central design problem in usage-based billing for AI agents: a billing unit does more than measure consumption. It decides who absorbs cost variation, orchestration inefficiency, delivery failure, and uncertainty about value.
Providers should therefore choose the closest unit to customer value that they can still define, meter, verify, and price reliably. Calls are simple but can hide expensive work. Tokens track model cost but expose buyers to implementation variance. Tasks package a useful job but require scope and completion rules. Outcomes align payment with value but create the hardest verification problem.
The Meter Decides Who Carries The Risk
Every usage unit transfers a different risk between the API provider and the agent customer.
Per call: the provider absorbs most cost variation inside the endpoint.
Per token: the customer absorbs variation in prompt length, model behavior, and orchestration.
Per task: the provider absorbs work performed within a defined scope, while the customer accepts rules about what constitutes completion.
Per outcome: the provider absorbs execution and delivery risk, while both sides depend on an agreed method for attributing and validating the result.
This explains why there is no universally correct unit. The best meter depends on which variables the provider controls and which event the customer can understand before authorizing payment.
A weather lookup with stable compute may work well per call. An open-ended inference session may need token or compute metering. A document review service may be easier to sell per task. A support agent may support outcome billing only if “resolved” has a durable, auditable definition.
The wrong unit does not merely create an awkward price. It can make normal system behavior feel like overbilling.
Four Billing Units Compared
Billing unit | Strongest fit | Buyer predictability | Provider cost protection | Main dispute |
|---|---|---|---|---|
Call | bounded, repeatable endpoints | high when price is fixed | low to medium | whether retries and unequal calls count |
Token | direct model access and variable inference | low without a cap | high | whether token growth created useful value |
Task | scoped jobs with completion criteria | medium to high | medium | whether the task was completed as specified |
Outcome | results with independently verifiable success | high if charged only on success | low unless outcomes are priced well | attribution, quality, reversal, and time window |
The table is a starting point, not a pricing verdict. A provider can make each unit safer with input limits, maximum authorizations, tiers, included retries, and clear remedies.
The decisive question is: what event can both the agent and the provider recognize as a completed billable unit?
Per-Call Billing Works When Calls Are Economically Similar
Per-call billing is the easiest model for an agent to evaluate. The service advertises a price for one endpoint request, the agent checks policy, pays or authorizes the amount, and receives the response.
It works well when requests have bounded inputs and similar execution costs. Examples include retrieving one normalized record, validating one address, checking one status, converting a small file, or returning one cached data snapshot.
The model becomes fragile when the same endpoint can trigger radically different work. A request for ten records and a request for ten million records are both one call, but they are not the same product. Neither are a cache hit and a multi-model research run.
Providers can preserve per-call simplicity by defining classes of calls:
standard lookup with fixed input limits;
premium lookup using fresher or more expensive data;
batch request priced by a declared record band;
long-running call with a separate quoted maximum.
Retries need an explicit rule. A network retry with the same idempotency key should normally return the existing result or job state rather than create a second bill. A new request with changed inputs may be a new call. Without that distinction, agent retry logic can multiply revenue and customer frustration at the same time.
Use per-call billing when the endpoint itself is a meaningful product unit—not merely a doorway to unpredictable work.
Per-Token Billing Protects Cost Attribution, Not Customer Value
Tokens are attractive because model providers already expose them as measurable input and output units. They allow an API provider to attribute variable inference cost precisely and preserve margin when prompts, context windows, and generated responses vary.
But a token is an infrastructure unit, not a customer result.
An agent may use more tokens because the task is genuinely harder. It may also use more because the provider changed its system prompt, added verbose intermediate reasoning, selected a different model, missed a cache, or retried a failed generation. If all tokens are billable, the customer pays for decisions it cannot observe or control.
Token billing is most defensible when:
the product is direct or near-direct model access;
input and output token rules are disclosed;
the agent can estimate or cap the context supplied;
model and service tier are known before execution;
provider-side retries are excluded or separately defined;
a maximum charge is enforceable.
A token budget should have operational consequences. When the budget is reached, the service can stop with a valid partial response, return an explicit limit state, or request another authorization. Continuing past the cap and billing afterward defeats the purpose of agent spending policy.
Token billing also needs version awareness. A tokenizer, model, compression method, retrieval strategy, or prompt template can change measured consumption. The receipt should identify enough of the rated configuration to explain the charge without exposing sensitive internal prompts.
Use tokens when variable model consumption is the product. Do not use them merely because they are the easiest internal counter to export.
Per-Task Billing Requires A Machine-Readable Scope Contract
Task billing moves closer to what the agent wants to buy: summarize this document, screen this transaction, generate this report, reconcile this dataset, or execute this tool workflow.
The provider can hide internal model selection, tool calls, and retries behind one price. That gives the agent a more predictable bill and lets the provider optimize execution without changing the customer-facing meter.
The tradeoff is scope risk. “Generate a report” is not a billable unit until the service defines:
accepted input type and maximum size;
included data sources or tools;
maximum execution time;
required output format;
completion and validation conditions;
number of included provider retries;
treatment of customer-requested revisions;
remedy for incomplete or invalid delivery.
A task ID should bind the quote, authorization, execution state, output, and receipt. If the connection fails after completion, the agent can retrieve the same task instead of buying it again. If inputs change materially, the provider can issue a new quote rather than silently expanding the original job.
Task pricing works especially well when internal costs vary but remain statistically manageable within firm input boundaries. The provider prices a distribution rather than every token. Efficient execution improves margin; inefficient execution does not automatically increase the buyer's bill.
Use per-task billing when a useful job can be specified more clearly than its internal consumption can be predicted.
Per-Outcome Billing Needs Proof, Attribution, And A Clock
Outcome billing appears to create ideal alignment: charge when a ticket is resolved, a valid lead is produced, a vulnerability is confirmed, a payment is recovered, or another measurable result occurs.
The difficulty is deciding whether the service caused the outcome.
Suppose an agent recommends a transaction that becomes profitable later. The result may depend on market movement, another service, human approval, timing, or actions outside the provider's control. Even apparently simple outcomes can reverse: a support case reopens, a fraud decision is appealed, a lead is invalidated, or a generated asset fails downstream review.
An outcome contract needs at least four definitions:
Success event: the exact state that creates a charge.
Evidence source: the system or signature accepted as proof.
Attribution rule: how the service's contribution is distinguished from other actors.
Finality window: how long the result can be challenged, reversed, or reclassified.
Outcome billing is strongest when success is narrow and independently observable. A schema-valid conversion, a verified delivery, or a confirmed supported action may be easier to settle than “customer satisfaction” or “business growth.”
Providers must also price unsuccessful work into successful outcomes. If only one in five valid attempts produces a billable result, the successful unit must cover the cost of the other four or the service will not remain viable.
Use outcome billing when success can be verified without turning every payment into a negotiation.
One Agent Workflow Can Contain All Four Units
A customer-facing unit does not need to match every internal meter.
Consider an agent that asks a compliance service to review a document:
The gateway records one API call.
The model consumes input and output tokens.
The orchestration layer performs one review task.
The service returns an approved, rejected, or needs-review outcome.
The provider should retain all four measurements for operations. It may use calls for rate limiting, tokens for cost attribution, tasks for customer billing, and outcomes for quality reporting.
This is the difference between metered usage and rated usage. Metered usage is the event stream the system observes. Rated usage is the subset and aggregation that commercial rules turn into a charge.
If the provider bills per task, internal validation retries can remain token events without becoming additional customer tasks. If it bills per outcome, failed tasks remain operational costs rather than invoices. If it bills per token, the task and outcome records still help explain whether consumption delivered value.
Keeping the event model richer than the price model makes it possible to change pricing later without losing operational truth.
Authorization Must Match The Variability Of The Unit
The payment flow should reflect how certain the final amount is before work begins.
Fixed-price calls and tightly scoped tasks can use a known amount. Variable token workloads need a maximum authorization before execution and a final charge based on rated usage. High-frequency, low-value calls may benefit from aggregation or batched settlement rather than a separate onchain settlement for every event.
Current x402 documentation distinguishes three relevant scheme shapes:
exactfor an advertised fixed price;uptofor a maximum authorization with actual usage determined at settlement;batch-settlementfor repeated micropayment traffic settled in batches.
These mechanisms do not decide whether a token, task, or outcome deserves a charge. They carry the payment rule selected by the application.
An agent should evaluate the amount or maximum against policy before signing. Policies can include a per-call ceiling, per-task budget, daily allowance, approved merchant list, supported asset and network, or required confirmation for high-risk actions. Automatic execution should remain bounded by those controls.
Payment verification also cannot prove service quality. It proves that the payment condition was satisfied. The API still needs delivery evidence, task state, dispute logic, and a remedy when paid work fails.
A Quote Should Explain More Than Price
Machine customers need enough billing context to decide before they buy. A useful quote or payment requirement should identify:
service and version;
billing unit;
unit price or maximum authorization;
currency, asset, and supported network;
input limits and service tier;
expiration time;
task or request identifier;
completion condition;
included retries;
partial-delivery rule;
cancellation, credit, or refund policy;
merchant identity or verification context.
Token-based quotes should state which usage counts and how it is aggregated. Task quotes should describe scope. Outcome quotes should define proof and the challenge window. Per-call quotes should distinguish billable calls from idempotent retries.
The agent's wallet balance is not enough information. A payment can be affordable and still violate task budget, merchant policy, data-handling rules, or expected value.
The Billing Meter Must Reach The Payment Runtime
A complete implementation connects four systems: usage metering, commercial rating, agent authorization, and settlement.
The API first records trustworthy events with unique identifiers. The rating layer applies prices, caps, included usage, and failure rules. The agent runtime evaluates the resulting quote against wallet and policy controls. The payment layer verifies and settles the authorized amount. Finally, the service binds payment state to delivery state.
GOAT Network is relevant at this junction. Its agent-oriented stack combines x402 commerce, AgentKit tooling, and ERC-8004 identity and reputation capabilities within broader Bitcoin-secured infrastructure. AgentKit also presents policies, guardrails, hooks, observability, and onchain action surfaces that are pertinent when a payment authorizes an agent-triggered operation.
That stack does not replace the provider's meter or determine whether a task was successful. It offers one environment for connecting payment and execution after the merchant has defined the billing contract. x402 is a broader protocol, not exclusive to GOAT Network, and developers should verify current schemes, assets, networks, SDK behavior, and production requirements before deploying.
Failure Rules Depend On The Unit
Event | Per call | Per token | Per task | Per outcome |
|---|---|---|---|---|
Duplicate request | return prior response; no new charge | deduplicate token event | return existing task | return existing outcome state |
Provider retry | usually included | exclude or disclose rated tokens | included within task rule | provider absorbs until outcome |
Invalid input | reject before billable call when possible | charge only disclosed validation work | task not accepted | no outcome |
Partial delivery | route-specific rule | charge valid rated usage up to cap | partial credit or defined partial result | usually no success charge |
Late reversal | generally irrelevant | generally irrelevant | reopen only under task warranty | apply challenge-window rule |
The exact policy can differ, but it must be defined before the exception occurs. A generic paid=true field is not enough to determine whether the customer received the unit it purchased.
Usage events also need stable identifiers. If ingestion retries create duplicate meter events, the invoice can be wrong even when the payment system works perfectly. Correction records should preserve the original event, adjustment reason, and resulting charge rather than silently deleting history.
Choose The Unit With A Five-Step Test
Start with the event nearest to value, then move toward raw consumption only when verification or cost risk demands it.
Can success be defined and independently checked? If yes, consider outcome billing.
Can the job be scoped with bounded inputs and completion rules? If yes, task billing may offer better predictability.
Are endpoint calls economically similar? If yes, per-call billing is simpler.
Does internal consumption vary too much for a fixed unit? If yes, use token or another resource meter with an enforceable maximum.
Can the provider explain retries, partial work, and corrections? If no, the model is not ready regardless of unit.
For a first release, choose one primary customer-facing unit and keep the other events as internal telemetry. Launch with strict input limits, one price or cap, idempotent requests, durable receipts, and a small set of explicit failure states. Add complexity only after real usage shows where the original unit misallocates risk.
FAQ
What is usage-based billing for AI agents?
It is a model in which an agent customer is charged according to measurable consumption or delivery events, such as API calls, tokens, completed tasks, or verified outcomes, rather than only through a fixed recurring fee.
Is per-call or per-token billing better for an AI API?
Per-call billing is usually more predictable when requests have similar costs. Per-token billing protects the provider when inference consumption varies, but it requires caps and transparent counting because the buyer may not control all token growth.
How should an API charge for agent retries?
An idempotent retry of the same purchase should normally return the existing result or state without a second charge. Provider-side execution retries should be included, excluded, or capped according to a rule disclosed before payment.
When does task-based billing work best?
It works best when the service can define accepted inputs, included work, output format, completion tests, and failure remedies. The task must be specific enough for software to determine whether it was fulfilled.
Why is outcome-based billing difficult?
Outcomes can depend on several actors and may reverse later. The provider and customer need an agreed success event, evidence source, attribution rule, and finality window before the outcome becomes a reliable billing unit.
Can x402 handle variable usage charges?
x402 supports payment schemes for fixed prices, maximum-authorized usage, and batched micropayment traffic. The application must still meter usage, calculate the rated charge, enforce the cap, and connect settlement to delivery.
Price The Risk Boundary, Not Just The Counter
Calls, tokens, tasks, and outcomes are not four names for the same usage. They move uncertainty to different sides of the transaction.
For usage-based billing AI agents can evaluate safely, the provider should make that allocation visible before payment. Define the unit, cap the exposure, identify the completion event, bind retries to one purchase, and preserve a receipt that connects usage, charge, and delivery.
Once the billing unit matches both economic risk and verifiable value, the payment rail can do its real job: carry a clear commercial decision instead of compensating for an ambiguous one.
