Beyond chat

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

Owner

Product

Version

beta-2026.07

Verified

2026-07-13

Chat completions and image generation are the mainnet launch products, not the market's final shape. The auction prices tokens, prepaid credits or x402 pays for them, and the receipt records them; anything that reduces to tokens can ride the same rail. Several additional product families are implemented behind launch gates, and the agent tool loop composes ordinary chat calls.

Images · live on mainnet

POST /v1/images/generations runs the same flow as chat: auction, credit reserve or x402 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 · not enabled on V1 mainnet

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 support one-call prepaid credits; direct x402 remains available for per-request payment.

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 on mainnet today: chat completions with tool calling and vision input, stream resume, per-key rate limiting with x-ratelimit-* headers, and HTTP idempotency keys so a retried POST cannot be double-served. Feature-gated at launch: embeddings, orders, and public credit deposits. On the API roadmap, specced but not shipped: 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.