Developer documentation
How authorization, charges, and receipts work
Understand the spending limit you approve, the final amount charged, and the payment evidence saved in the receipt.
Page tools
For text, max_tokens sets the largest response the model may return. It does not prepay for that many tokens. The server uses the limit to calculate the highest possible charge, while the final charge uses the model provider's reported usage. Image generation instead selects one disclosed fixed price from the requested model and image_size; aspect_ratio does not change the tier.
Pricing terms
- Estimated maximum: the estimated input cost plus the highest possible output cost, a pricing buffer, the active service fee, the fixed successful-call fee, and the minimum usage charge.
- Authorized maximum: the request-specific spending limit approved by the buyer.
- Provider cost: catalog rates multiplied by actual normalized token usage for text; the fixed
- Service fee: 0% during the launch promotion, recorded as zero integer basis points.
- Fixed successful-call fee:
1000atomic USDC units, or0.001000USDC. - Minimum charge:
1000atomic United States Dollar Coin (USDC) units, or0.001000USDC, for each successful paid model request. - Text settlement: the greater of actual provider cost plus the active service fee and the minimum usage charge, plus the fixed successful-call fee, capped by the signed maximum.
- Image settlement: the selected model/size catalog price plus the fixed successful-call fee, capped by the signed maximum. The current Base mainnet Gemini 3.1 Flash-Lite Image 1K/1:1 total is
0.035000USDC.
image-output accounting floor plus any reported prompt or residual output usage for images.
Image token counts are optional upstream telemetry and do not affect the fixed image price. A zero image token count in a receipt means the provider compatibility layer did not report that field; it does not mean that image generation used no computation.
The server uses integer arithmetic and rounds once when converting to six-decimal USDC. It never settles above the signed maximum.
Receipt evidence
The successful response includes the PAYMENT-RESPONSE, X-Request-ID, X-Receipt-ID, X-Receipt-Token, and X-Catalog-Version headers, plus a receipt link. Retrieve the receipt with GET /v1/receipts/{receipt_id} and the X-Receipt-Token header. Treat the receipt token like a password: store it securely and never log or share it. The server stores only a one-way hash of the token.
The durable receipt contains the public model name, normalized usage, pricing policy, approved maximum, final amount charged, payment network, payment asset, and transaction reference. It never contains the prompt, model answer, wallet key, provider credential, raw signature, complete payment payload, or receipt token.
The x402 transaction proves that payment occurred. The usage section is an Onchain Router record, not a separate provider-signed proof. Text usage is normalized from mandatory provider telemetry; image usage retains optional provider telemetry and uses zero when a field was not reported.