Billing

Charging is by actually used tokens, separately for input and output, at the model's rate. The balance is in your Guard account and in the bot.

The table above is built from the gateway billing catalog, so the numbers are never retyped into the documentation text and never drift from what the charge is computed on. The key keeps one balance for every family.

The part of the input Kimi recognized from its own cache is charged at the separate Cache read rate. For k3 and k3-256k it is ten times below the input rate; for kimi-for-coding and kimi-for-coding-highspeed it is five times below. Nothing is paid twice: cached tokens are subtracted from the ordinary input. How many there were is visible in the response — usage.prompt_tokens_details.cached_tokens. Kimi does not bill cache writes separately.

Before calling the model, Guard reserves estimated input cost plus the maximum output cost. For Kimi without max_tokens, the output part is computed at Kimi's default: 131,072 tokens for k3 and k3-256k, 32,768 for kimi-for-coding-highspeed, 32,000 for kimi-for-coding; if the balance cannot cover that reserve with room for 8 more regular requests, 32,000. A future cache hit is not assumed. Unused reserve is released.

On Messages, Chat Completions and Responses, Guard temporarily holds the largest possible cost of the request before the model is called. The input part is estimated from above: the UTF-8 bytes of the request itself — the system text, the messages and the tool descriptions. That is deliberately more than the real token count, but it never under-holds on code, JSON or non-Latin text. The output part follows max_tokens, or max_output_tokens on the Responses surface; when no limit is set, 128,000 is used for Grok and 32,000 for Composer; if the key balance or its limits cannot cover the Grok reserve at 128,000 with room for 8 more regular requests, 32,000.

The server prompt and the client request form one billable input. All of those tokens use the selected model’s full input or cache-read rate. usage and count_tokens return full input_tokens, including an applied server prompt; its text is neither needed for the calculation nor exposed. Full conditions.

Web search adds $0.01 per metered billed search request. Web fetch has a $0 fixed fee. Retrieved content is accounted as input tokens at the full input or cache-read rate.

Each key can have its own USD cap for a rolling hour and/or 24 hours: @guardapi → My API keys → choose a key → Manage API key → limits. Set 0 or use the clear action to remove limits.

Base Standard short-context rates for all seven models are listed on the Models page. Billing always keeps the model id requested by the client, even when an allowed server prompt chooses another model for execution only.

Formula: uncached input × input rate + cached input × cache rate + all output × output rate + confirmed searches × $0.10. Divide all token-rate terms by 1,000,000.

Search is billed per confirmed operation. The number of links or result rows does not multiply the charge; if the model does not invoke search, no search charge is added.

The multiplier is 1 for every GLM key, including PRIVATE. discount_percent is 0 at the current full rate.

A conservative amount is reserved before the request; final debit uses actual tokens and confirmed search. The reserve and final cost can therefore differ.

Formula: uncached input × input rate + cached input × cache-read rate + all output × output rate + number of search requests × $0.014. Divide all token rates by 1,000,000.

Web search: $0.014 for each search request, starting with the first. The cost of one search is held before the answer, and the final charge uses the actual number of searches. Retrieved text is billed as ordinary input tokens. The max_uses limit is accepted but not kept, so every search that runs is billed.

Formula: uncached input × input rate + cached input × cache-read rate + all output × output rate + number of search requests × $0.0025. Divide all token rates by 1,000,000.

Web search: $0.0025 for each search request, starting with the first. The cost of five searches is held before the answer, and the final charge uses the actual number of searches. The max_uses limit is accepted but not kept, so every search that runs is billed.