Usage and costs

Every request is metered and costed individually, against the workspace that owns the API key used.

How a request is charged

1. The request completes.
2. Token counts are recorded — input, output, and cached input where applicable.
3. Cost is calculated from the model’s rates at that moment, and stored alongside the usage record.
4. The amount is debited from the workspace wallet.

Because the rate is captured per request, a later price change never retroactively alters what you were charged.

Failed requests are not charged. A request rejected for insufficient balance, rate limiting or queue capacity never reaches the model and costs nothing.

What counts as a token

• Input — everything you send: system prompt, full message history, tool definitions and tool results. A long conversation re-sends its history on every turn, so input cost grows with the conversation.
• Output — everything generated, including reasoning tokens on models that think before answering. Raising reasoning_effort raises cost.
• Cached input — where a model supports prompt caching, repeated prefixes are charged at a lower rate. Cached tokens are a discounted subset of input tokens, not an extra line item.

Image generation is charged per image, and audio per minute of input, rather than per token.

Seeing what you have spent

Usage breaks spend down across:

• Overview — calls, tokens, total cost and success rate.
• Requests — individual requests with per-request cost.
• By model — which models account for your spend.
• Cost analysis — distribution and trend over time.
• Performance — latency and time-to-first-token.

Per-request rows include the API key name, so you can attribute spend to a particular application by naming keys after the thing that uses them.

Chargeback across teams

The usage API supports grouping by API key and by project, beyond what the UI currently displays. If you need per-team or per-customer cost attribution, one key per consumer plus that grouping is the cleanest approach available today.

Controlling spend

• Cap max_tokens to what you actually need. It bounds the most variable part of the bill, and also improves how quickly your requests are admitted under load — see Rate limits and queueing.
• Trim history. Summarise or truncate long conversations rather than re-sending everything each turn.
• Match the model to the job. Rates differ by more than an order of magnitude across the catalog; a small model is often sufficient for extraction, classification and routing.
• Watch reasoning effort. On reasoning models it is a direct multiplier on output tokens.
• Exploit caching. Keep the stable part of your prompt at the front and unchanged, so it can be served as cached input.

See Billing for how to fund the wallet and what invoices you receive.