# How authorization, charges, and receipts work

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
  image-output accounting floor plus any reported prompt or residual output usage for images.
- **Service fee:** 0% during the launch promotion, recorded as zero integer basis points.
- **Fixed successful-call fee:** `1000` atomic USDC units, or `0.001000` USDC.
- **Minimum charge:** `1000` atomic United States Dollar Coin (USDC) units, or `0.001000` USDC, 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.035000` USDC.

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.