Pricing
Priced per token, separately for input and output, per model. No separate charge for streaming, tool calling, or image input beyond the tokens they consume.
Per-model pricing
| Model | Input ($ / 1M tokens) | Output ($ / 1M tokens) |
|---|---|---|
| tai-4.0.6P | $0.20 | $1.00 |
| tai-4.0.6B | $0.35 | $1.75 |
| tai-4.0.7 | $0.75 | $2.00 |
| tai-4.1 | $0.90 | $2.00 |
| tai-4.2 | $1.00 | $2.50 |
Input tokens are everything sent to the model on a given request: the system prompt, every message in the conversation history, and any tool definitions included. Output tokens are what the model generates in response. The two are priced separately because they're not interchangeable in cost: generating tokens is a meaningfully different (and generally more expensive) operation than processing tokens that are already there.
A worked example
A tai-4.1 request with 1,300 input tokens and 230 output tokens:
Input: 1,300 / 1,000,000 × $0.90 = $0.00117
Output: 230 / 1,000,000 × $2.00 = $0.00046
Total ≈ $0.00163
Individual requests are almost always fractions of a cent. Cost adds up over volume, which is exactly what the usage object on every response is for, letting you track it per request rather than only discovering total spend after the fact.
Tracking usage
Every response, streaming or not, includes a usage object with prompt_tokens and completion_tokens for that specific request (see Chat completions and Streaming for exactly where it appears in each mode). Multiplying those against the table above gives the exact cost of that request. Usage is also aggregated automatically per key and visible in the console's Usage page, scoped to the workspace the key belongs to, so day-to-day cost tracking doesn't require computing it yourself from raw token counts on every request.
What affects cost, and what doesn't
Cost scales with tokens actually processed and generated, nothing else. Streaming a response doesn't cost more than getting it back in one blocking call; it's the same generation, delivered differently. Tool definitions passed in the tools field count as input tokens the same as any other part of the request, so a request with a large number of verbosely-described tools costs somewhat more in input tokens than the same request without them, proportional to how much text the tool definitions actually add. An image attached to a request is converted into a number of input tokens by the model itself as part of processing it; there's no separate flat per-image charge on top of that.
Conversation history and repeated cost
Because the API is stateless (see Chat completions), every request in a multi-turn conversation re-sends the full history as input, and that history is billed as input tokens again on every single turn, not just once. A long-running conversation's per-turn input cost grows as the history grows, since each new request includes everything before it. For a conversation that's expected to run very long, trimming or summarizing older turns before including them in a request is a reasonable way to keep this bounded, at the cost of the model no longer having verbatim access to whatever was trimmed.