x402 AI Inference: The API Call That Pays for Itself

An API request should be able to arrive with its own money.

x402 is an open payment standard that turns HTTP 402 Payment Required into a machine-readable payment flow. Instead of creating a vendor account, storing its API key, or buying credits, a client asks for a resource, receives payment terms, signs a payment, retries the request, and gets the result.

OpenModels now applies that flow to AI inference. In its public catalog, an agent can call Chat Completions, select among 27 models, and pay in USDC over Base or Solana. As of July 3, 2026, the endpoint starts at 0.1 USDC and places a 10 USDC authorization ceiling on a call. For production and high-volume workloads, OpenModels still recommends its credit balance and API keys.

TL;DR. OpenModels x402 lets an agent buy one model response without first opening an OpenModels account, funding a credit balance, or receiving an API key. The agent discovers /x402/chat-completions, sends a normal request, receives an HTTP 402 with payment requirements, signs a USDC payment, retries the request with the payment signature, and receives the model response. One live endpoint, 27 available models, Base and Solana settlement, a 0.1 USDC starting price, and a 10 USDC maximum authorization per call. Use this path for agents, one-off calls, and cross-organization transactions. Use credits and an API key when volume, consolidated billing, and predictable operations matter more than accountless access.

In This Guide

• What x402 changes for AI inference
• What OpenModels has made live
• How the payment flow works
• Why no API key does not mean no security
• When to use x402 instead of credits
• Limits to design for

What x402 Changes for AI Inference

An API key normally answers two questions at once: who may call this service? and who receives the bill? That works inside a lasting vendor relationship. It is a poor fit for an autonomous agent that discovers a new tool during a run and needs one result now.

An x402 endpoint is an HTTP resource that publishes its price and accepted payment method as part of the request-response exchange. The caller does not need a pre-existing commercial relationship with the seller. Payment for the current request becomes the access condition for the current request.

That is the useful shift. The request is no longer followed by a checkout. The request contains the checkout.

The official x402 payment flow separates four roles:

The model request stays an HTTP request. The payment becomes a standard part of the exchange instead of a separate signup, billing, and credential workflow.

What OpenModels Has Made Live

The public OpenModels catalog exposes the first implementation as a live Chat Completions endpoint. This is a dated product snapshot, not a permanent promise:

The maximum payment is an authorization ceiling, not a flat 10 USDC charge. Actual cost depends on the selected model and the output produced. OpenModels states that the call will not charge more than the displayed maximum.

That distinction matters for model inference. A fixed-price weather endpoint can quote one amount. An LLM call depends on inputs, outputs, model choice, and sometimes tool use. A ceiling lets the agent answer the question that matters before execution: what is the most this call is allowed to cost?

How the Payment Flow Works

At protocol level, the flow is a short loop:

DISCOVER -> REQUEST -> 402 QUOTE -> SIGN -> RETRY -> 200 RESPONSE

1. Discover the endpoint and its boundary

The agent finds the OpenModels endpoint, checks the supported models, sees the starting price and the 10 USDC ceiling, and selects Base or Solana. OpenModels also publishes openmodels.market/SKILL.md so an agent can learn how to discover and call the catalog.

2. Send the model request

The client sends a Chat Completions payload to /x402/chat-completions. There is no OpenModels bearer key and no credit balance attached to the request.

3. Receive 402 Payment Required

The resource server returns payment requirements. In x402 V2, those requirements travel in a PAYMENT-REQUIRED header and identify the amount, asset, network, destination, and payment scheme the client must satisfy.

4. Sign the payment

The client wallet checks the terms against its own policy. It can reject an unknown network, a disallowed model, or a quote above its per-call budget. If the terms pass, the wallet signs a payment payload.

5. Retry with proof

The client resends the same model request with a PAYMENT-SIGNATURE header. The server verifies the payload locally or through a facilitator, then settles it on the selected network.

6. Receive the model result

After successful verification and settlement, the server runs the inference request and returns 200 OK, the model response, and a PAYMENT-RESPONSE header containing settlement details.

The exchange looks like this at the HTTP layer. This is a protocol transcript, not a copy-paste client command; use the live OpenModels detail page for the current URL and request schema.

POST /x402/chat-completions
Content-Type: application/json

{"model":"<model-id>","messages":[{"role":"user","content":"Summarize this incident."}]}

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <payment requirements>

POST /x402/chat-completions
Content-Type: application/json
PAYMENT-SIGNATURE: <signed payment payload>

{"model":"<model-id>","messages":[{"role":"user","content":"Summarize this incident."}]}

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <settlement response>
Content-Type: application/json

{"choices":[...]}

The visible 402 is not a failure in this flow. It is a quote the client can evaluate before money moves or inference runs.

The Payment Becomes a Policy Boundary

An agent should not sign every valid payment request it sees. It should sign only requests that satisfy an explicit payment policy.

allow network in {base, solana}
allow asset == USDC
allow endpoint == /x402/chat-completions
allow model in approved_models
allow max_authorized <= 1.00 USDC
allow daily_agent_spend <= 25.00 USDC

The OpenModels endpoint may advertise a 10 USDC ceiling, while your agent authorizes only 1 USDC. Those statements do not conflict. The endpoint publishes the outer bound; the buyer applies a tighter internal bound.

This turns payment into a useful checkpoint. Before a model call begins, the agent can inspect the seller, resource, model, chain, asset, and maximum cost. Traditional API billing often reveals the final cost after the request. An x402 challenge gives the buyer a machine-readable decision point before execution.

Why No API Key Does Not Mean No Security

API-keyless does not mean credential-free. It means the seller does not issue the credential.

The buyer still needs a wallet with USDC and a secure way to sign. For an autonomous system, wallet signing authority should be treated like production secret access:

• keep private keys outside prompts, traces, and application logs;
• restrict signing to named networks, assets, and endpoints;
• cap each payment and cumulative spend by agent or run;
• reject expired, replayed, or changed payment requirements;
• record the quote, signature decision, settlement result, and model response ID;
• separate development and production wallets.

The seller's API key disappears. The buyer's payment policy becomes more important.

On-chain settlement also leaves public transaction data. Do not put prompts, customer identifiers, or private workflow data in payment metadata. The payment proves value moved; it should not become an accidental application log.

When to Use x402 Instead of Credits

OpenModels supports two access shapes because they solve different jobs:

Use x402 when the ability to transact without prior setup is the point. Examples include an agent discovering a model endpoint during a run, a wallet-funded demo, a user paying for one expensive reasoning call, or one organization buying a result from another without exchanging long-lived credentials.

Use credits and an API key when the relationship is expected to last. OpenModels explicitly recommends that path for production usage, higher volume, and predictable billing. The standard OpenModels API also gives teams a shared balance, key management, usage visibility, and per-key spend limits.

Accountless and production are not synonyms. x402 reduces commercial setup. It does not remove the need for retries, observability, wallet operations, or spending policy.

What This Unlocks for Agents

The immediate benefit is not "crypto payments for AI." That framing is too small. The benefit is runtime purchasing.

A research agent can discover an unfamiliar model, inspect a bounded quote, buy one completion, and continue its run. A support workflow can ask the end user to fund a premium model call without pooling that cost into the platform's main API account. A benchmark agent can sample several models without the operator opening several vendor accounts. A tool marketplace can sell an inference-backed capability to any compatible wallet.

On the seller side, the same protocol underpins paid endpoints and the wider agent-economy model described in What Is an AI Agent Finance Gateway?. On the buyer side, OpenModels turns model supply into a resource an agent can discover, price, and purchase during execution.

The protocol's own adoption has moved beyond a paper design. When the x402 project introduced V2 on December 11, 2025, it reported that the protocol had processed more than 100 million payments since its May 2025 launch. V2 added standardized headers, automatic service discovery, wider network identifiers, and a foundation for reusable wallet-based access. The x402 V2 announcement also names high-frequency LLM inference as a target for reducing repeated payment overhead.

That does not prove every AI workload should pay on-chain. It proves the request-payment loop has enough real use to be evaluated as infrastructure rather than a demo.

Limits to Design For

x402 removes signup friction, but it introduces a payment path that production systems must handle deliberately.

Latency: the first request, payment signature, verification, settlement, and retry add work around inference. Measure the full paid-call latency, not only model time.

Failure modes: a call can fail because the wallet lacks USDC, the network is unavailable, the quote expired, the payment signature is invalid, settlement failed, or the model request failed after payment verification. Each state needs a separate retry rule.

Variable model cost: the 10 USDC figure is a ceiling. The actual charge depends on model and output. Set a buyer-side maximum below the endpoint ceiling when a run cannot tolerate the full amount.

Wallet operations: key custody, signing policy, funding, and reconciliation become application responsibilities. A seller-issued API key is gone, but secret management is not.

Catalog freshness: OpenModels currently displays one endpoint and 27 models. Treat both as live catalog data. Discover before calling instead of hard-coding the count into an agent.

Production fit: OpenModels recommends credits and API keys for high-volume workloads. Follow that guidance unless accountless payment is a requirement, not merely a novelty.

Frequently Asked Questions

What is x402 for AI inference?

x402 for AI inference is a pay-per-request access method in which an AI API returns HTTP 402 Payment Required, the client signs the stated payment, and the API serves the model response after verification. It lets an agent buy a model call without first creating a vendor account or receiving that vendor's API key.

Does OpenModels x402 require an API key or credits?

No. OpenModels states that its x402 endpoints do not use an OpenModels API key or prepaid OpenModels credits. The caller pays each request in USDC from a compatible wallet. The wallet and its signing policy replace the vendor-issued billing credential for that call.

Which networks does OpenModels support for x402?

The public OpenModels snapshot on July 3, 2026 lists Base and Solana, with USDC on both. Network support can change, so an agent should discover the current payment options before calling and allow only networks its wallet and spending policy explicitly support.

What does "up to 10 USDC" mean on the OpenModels endpoint?

It is the maximum payment the endpoint asks the caller to authorize for one call, not the price of every call. The actual charge depends on model choice and output, and OpenModels says it will not exceed the stated ceiling. Buyers should apply a lower internal cap when appropriate.

When should I use x402 instead of an OpenModels API key?

Use x402 for agent-driven discovery, one-off calls, wallet-funded experiments, or transactions where no prior OpenModels account should exist. Use OpenModels credits and an API key for production volume, consolidated billing, usage visibility, and per-key controls. OpenModels itself recommends the key-and-credit path for production workloads.

Is HTTP 402 an error in an x402 call?

No. In the normal x402 flow, the first 402 Payment Required response is a machine-readable quote. The client reads the payment terms, decides whether they fit policy, signs if allowed, and retries the request with proof. A second 402 can indicate invalid or unmet payment requirements.

The Bottom Line

The useful idea in x402 is simple: a machine should be able to buy one API result with the request that asks for it. No procurement ticket. No account created three minutes before it is abandoned. No long-lived vendor key passed between organizations.

OpenModels makes that idea concrete for AI inference: one live Chat Completions endpoint, 27 models, USDC on Base or Solana, a displayed starting price of 0.1 USDC, and a 10 USDC authorization ceiling as of July 3, 2026. The payment path is best for agents and one-off access. The existing credit-and-key API remains the better operational shape for sustained production traffic.

Explore the live endpoint catalog at openmodels.market/x402. To understand the standard account-based supply path, read OpenModels vs OpenRouter and direct inference providers. For the seller side of agent payments, read what an AI Agent Finance Gateway does with paid endpoints and Known Margin.