Kimi Tokens: Counting, Context Windows, and Model Choice

The short answer

“Kimi token” can refer to the tokens in a request, a model’s context window, or—sometimes, by confusion—a secret API key. They are not interchangeable. Moonshot documents a token-estimation API, but the request schema and returned count field are not established here. For model choice, kimi-k3 and kimi-k3.1-pro are documented options with 1,048,576-token context windows. Choose based on the documented API behavior and input features you need; confirm the model is available for your account and route in Moonshot’s live model list. (platform.kimi.ai)

Tokens, context length, and API keys

• Token count is the count associated with a request. Moonshot’s documentation describes estimating input tokens before sending a request. The captured documentation does not establish the estimator’s exact API endpoint, payload, or response field, so this guide does not provide a copy-and-run estimator call. (platform.kimi.ai)
• Context length is a model specification—not a price, an API key, or a promise that the entire window is available for your prompt alone. Moonshot’s Kimi K3 repository lists Vocabulary Size 160K and Context Length 1048576 as separate specifications. Its vocabulary figure is not the context limit.
• API key is a credential for authenticating requests. Keep it secret; it does not describe token usage or model capacity.

For image and video requests, do not assume that counting text alone estimates total input usage. Moonshot’s vision guidance says those inputs use dynamic token calculation and directs users to estimate token consumption before sending the request. (platform.kimi.ai)

How to count Kimi tokens

Moonshot provides an official documentation page titled Estimate Tokens for estimating input before a request. Use that page for the estimator instructions. The information available for this guide confirms the estimator’s purpose, but not the exact request URL, payload fields, or returned count field. Those details matter: guessing an endpoint or response property would make an example unreliable. (platform.kimi.ai)

As a rough planning rule, a context-window figure tells you the model’s stated capacity; it does not tell you how many tokens a particular text, image, or video request will use. Use the estimator guidance for the actual input, especially for multimodal requests.

Which Kimi model fits your API workload?

There is no verified universal winner between these options. The documented differences can help narrow a shortlist:

• kimi-k3: Consider it if its documented multi-turn behavior fits your integration. Moonshot’s K3 repository says thinking is always enabled and instructs callers to pass the complete assistant message back in later turns, including reasoning_content and tool_calls when present. The repository lists a 1,048,576-token context length. It describes K3 as agentic, with coding, knowledge-work, and reasoning use cases. These are provider descriptions, not proof of performance on your workload.
• kimi-k3.1-pro: Consider it if you need the features highlighted in its API quickstart: reasoning-effort settings, streaming, vision input, and tool calling, alongside a stated 1-million-token context window. Moonshot’s vision guidance also lists K3.1 Pro and K3 as supporting video understanding. (platform.kimi.ai)

The live model-list documentation says the catalog can return model IDs, context lengths, and capability flags, and recommends checking availability and required capabilities before creating a completion. Use it to confirm the exact ID is currently available on your intended route; the documentation excerpt does not establish what a particular account’s live catalog will return. (platform.kimi.ai)

Token billing and cost estimates

Token count, context capacity, and billing are different measurements. Current per-model rates and cache charges for a specific route were not verified for this guide, so no dollar-per-million-token prices are quoted. Do not treat third-party rates as universal Moonshot API prices.

Once you have the current rates for the exact model and route, estimate cost by applying each rate only to the corresponding provider-defined usage category:

estimated cost = sum(tokens in each billable category ÷ that category's billing unit × its rate)
               + separately documented fees

Keep ordinary input, cached input, cache writes, and output separate when the provider defines them as separate categories. Do not count the same tokens twice unless the applicable billing rules explicitly require it. The formula is a calculation method, not a statement of Moonshot’s current cache rules or rates.

Before connecting a production API

Moonshot’s quickstart describes creating an API key, choosing a model, configuring a base URL, and making requests with an HTTP client or SDK. Its K3.1 Pro quickstart identifies the model features and context window noted above. (platform.kimi.ai)

One production detail remains unresolved here: the captured material does not establish a complete, matching international-route example that includes the estimator endpoint and payload, the completion endpoint and payload, and the response’s token-usage fields and billing interpretation. The estimator documentation is the right place to get its request and result schema; the API quickstart and chat-completions documentation are the relevant places to confirm the matching completion setup. Do not infer usage-field names or reasoning-token billing from a model’s context specification.

Before deployment, verify that the key and base URL belong to the same API product, the model appears in the live catalog, and the returned usage fields match the pricing categories for that route. For kimi-k3, preserve the complete assistant message in multi-turn conversations as its repository instructs.

Bottom line: Use Moonshot’s estimator documentation for request token counts, the selected model’s documentation for context and features, and the live model catalog to confirm availability. For cost, use current prices and usage categories for the exact route. An executable estimator-plus-completion example is not included because the required matching schemas and token-usage fields were not established.

Sources

Estimate Tokens — Kimi API Platform

List Models — Kimi API Platform

Quickstart — Kimi API Platform

Kimi K3.1 Pro — Kimi API Platform

Configure Kimi Vision Models

Chat Completions API — Kimi API Platform

MoonshotAI Kimi K3 — GitHub