For customersLive V1

Beyond chat

Images, embeddings, and tool loops through the same market and the same payment rail.

Chat completions are the market's first product, not its shape. The auction prices tokens, x402 pays for them, and the receipt records them; anything that reduces to tokens can ride the same rail. Two more product families already do, and a third capability, the agent tool loop, composes them.

Images

POST /v1/images/generations runs the same flow as chat: auction, 402, signed payment, receipt. Billing is simple by design: one image bills as a fixed block of output tokens at the cleared output price, so image work needs no new billing formula. Payment is per request only; no session budget draws images.

One honest wrinkle: upstream image pricing is a fixed list price, so there is no marginal-cost spread for an auction to discover, and quoter sidecars do not bid on per-image work today. When the book has no standing quote for an image class, the router quotes straight through at a pinned list-price tariff. A real standing quote, if a provider streams one, still takes the request through the auction first.

Embeddings

POST /v1/embeddingsgeneralizes the auction cleanly: input tokens are the whole cost, so the worst case the 402 quotes is the estimate itself, and billing meters the provider's reported prompt tokens at the cleared input price. A large share of real API spend is embeddings, which is exactly where per-request price discovery on input tokens pays. Like images, embeddings are per-request payment only.

The agent tool loop

The SDK runs bounded tool loops on top of ask: pass tools: true for the shared registry (local tools plus stocks, crypto, FX, and weather data tools), supply your own executors that win by name, and set maxToolRounds. Each round is its own paid auction with its own request id and receipt, and past the round cap the SDK stops paying rather than looping forever. Open-web tools (search, fetch, wikipedia) are opt-in via web: true, because they inject untrusted text into your loop. There is also a create_web_page tool that returns complete self-contained HTML pages on the result. Combine the loop with a session and the rounds share one budget at cached rates, or with spend caps and a budgeted key to bound the whole run.

Live versus roadmap

Live today: chat completions with tool calling and vision input, images, embeddings, stream resume, per-key rate limiting with x-ratelimit-* headers, and HTTP idempotency keys so a retried POST cannot be double-served. On the API roadmap, specced but not shipped: batch jobs at discounted clearing (latency-insensitive work clearing against cheaper quotes), an optional moderations endpoint, realtime and audio classes once a provider quotes them, logprobs passthrough as a catalog capability, and an OpenAI-compatible shim that does the x402 dance server-side against a prefunded wallet for tooling that cannot sign.

deliberately not on the roadmapAssistants-style server-side threads (sessions already cover the economic half; conversation state belongs to clients), fine-tuning (the providers' business, not the market's), and a files API (no durable customer blobs on a router that settles money).