Kimi K3.1 Pro: Parameters, Capabilities, Prices, and Model Comparisons

Kimi K3.1 Pro is Moonshot AI's new flagship for coding, visual and 3D work, and multi-step research. Released on 23 October 2026, it combines a 3-trillion-class parameter scale, a 1,048,576-token context window, and an always-on reasoning mode. Its international API list price is $2 per million input tokens and $10 per million output tokens; the Highspeed version costs $4 / $20. This places the standard version alongside Claude Sonnet 5.5 on uncached input and output price, and at half Claude Opus 5.5's corresponding rates. Sources: official model list, Kimi pricing, and Claude pricing.

The interesting question is what those prices buy for a real workflow. This guide separates model specifications, API controls, published evaluations, and calculated token budgets. The calculations are illustrative; Modelflare has not run a comparative model benchmark for this article. Provider results are attributed to their publisher.

Facts and prices were checked on 23 October 2026, at approximately 18:03 UTC. The public Modelflare catalog at that time contained kimi-k3, but neither K3.1 model ID. This article introduces the official release; it does not announce K3.1 availability on Modelflare.

1. Which K3.1 model are we discussing?

Item	Kimi K3.1 Pro	Kimi K3.1 Pro Highspeed
Official API ID	kimi-k3.1-pro	kimi-k3.1-pro-highspeed
Kimi Code ID	k3.1-pro	k3.1-pro-highspeed
Product positioning	Flagship reasoning and agent work	Same stated intelligence, faster output
Context window	1,048,576 tokens	1,048,576 tokens
Reasoning	Always enabled	Always enabled
Effort settings	low, high, max; default max	Same
Relative output speed	Reference	Approximately 2–3×, according to Kimi
Exact sustained tokens/second	Not established by this article	Not established by this article
API parameter restrictions	Shared within this pair	Same as standard Pro

Sources: model list, parameter reference, and Kimi Code model configuration. The coding subscription and the pay-as-you-go API use different IDs and billing systems. A display name such as “K3.1 Pro” is not an API identifier.

Highspeed changes the latency and price choice. It does not establish a new quality tier. A tool-heavy job may spend most of its time compiling, retrieving documents, or rendering a scene; accelerating model output cannot accelerate those external operations. Measure time to a useful result, not only token generation speed.

2. Parameters and architecture: what is actually disclosed?

The release blog identifies K3.1 Pro as a post-trained K3 model with a larger reinforcement-learning investment. It says full weights will be released by 4 November. A promised weight release is different from a downloadable checkpoint available on the article's check date.

“3T-class” is a scale description, not an exact statement of 3,000,000,000,000 parameters. For architectural context, the previous K3 checkpoint has a detailed official model card:

Architecture field	Published K3 baseline; not a separately verified K3.1 checkpoint specification
Architecture	Mixture of Experts, or MoE
Total parameters	2.8T
Activated parameters	104B
Transformer layers	93
Dense layers	1
Attention composition	69 KDA layers + 24 Gated MLA layers
Attention hidden dimension	7,168
Attention heads	96
Latent MoE dimension	3,584
Expert hidden dimension	3,072
Experts	896
Selected experts per token	16
Shared experts	2
Vocabulary	160K

MoE makes the distinction between total and activated parameters important: the model can store far more capacity than it uses for each token. This does not mean a 104B activated model has the storage requirements of a 104B total model. Weight memory, activation memory, cache, parallelism, and serving overhead are separate deployment costs.

For K3.1 specifically, this article does not assert an exact activated-parameter count, new expert count, layer revision, training-token total, knowledge cutoff, quantization format, final weight license, or minimum GPU configuration. Those require the corresponding release artifacts. The predecessor's architecture explains the family; it should not be silently relabeled as a new model card.

3. What its capabilities mean in practice

Coding and long-running agents

Kimi positions the model for repository fixes and larger engineering tasks, including web and game work. Its quickstart describes use of Unity, Unreal Engine, Godot, and Three.js. These are tool-assisted workflows: the environment supplies files, engines, dependencies, and execution privileges.

Our evaluation recommendation is to give the model an existing project with an actual defect, a bounded change request, and an independently defined acceptance condition. Check whether it locates the right component, preserves unrelated behavior, handles failed commands, and produces a reviewable result. Attractive generated code alone does not answer those questions.

3D creation and spatial reasoning

The same quickstart highlights script-driven modeling with Blender and CAD tools, including interpretation of sketches and reference images. This is different from a general-purpose API that directly returns an image or a video file. The useful deliverable may be a script, parametric geometry, an editable scene, or an asset produced by external software.

For a mechanical-part trial, specify units, dimensions, tolerances, and export format. For a visual asset, specify the camera, materials, polygon budget, and target renderer. A convincing preview and a manufacturable object have different acceptance conditions. These are suggested evaluation tasks, not results measured by Modelflare.

Financial research and spreadsheets

Kimi also emphasizes financial research and modeling. A useful evaluation should inspect provenance and spreadsheet behavior: do figures reconcile to the source period, do formulas remain linked, and does changing an assumption update dependent sheets correctly? Require a source trail and distinguish estimates from reported figures.

The model's ability to assemble a workbook does not establish the correctness of an investment conclusion. For this article, the relevant capability is document analysis, numerical reasoning, and tool-assisted production of an auditable artifact.

Visual context and structured workflows

The K3.1 quickstart documents image and video input, tool calls, and structured output. Its model-specific image restriction matters: use base64 data or an uploaded ms:// file reference; do not assume an arbitrary public image URL works because an older general vision example contains one.

For application design, keep the roles separate: the model interprets evidence and proposes a tool action; the application validates arguments, executes the permitted operation, and returns its result. A JSON document can be syntactically valid while containing an incorrect claim. Schema validation and evidence checking solve different problems.

4. How to read the published evaluation results

The following numbers are Moonshot's reported results, not an independent Modelflare reproduction. The release blog supplies these comparisons:

Evaluation	K3.1 Pro	Reference	Scope
Terminal-Bench 4.0	65.7%	Opus 5.5: 66.4%; GPT-6 Astra: 58.2%	Terminal tasks under the publisher's evaluation setup
Kimi Code Bench 3.0 Long-horizon	61.2%	K3: 55.95%	Internal engineering benchmark
BenchCAD, with tools	92.7	Opus 5.5: 96.2; GPT-6 Astra: 95.9	1,000-file subset; Voxel IoU, not task-success rate

The comparison supports a focused reading: K3.1 is a candidate for demanding agent and spatial workflows. It does not establish that it wins every coding task, is a drop-in replacement for another model, or delivers those results at your application's token budget. Tool access, reasoning effort, retries, and evaluator design all affect the result.

There is also a launch-day source discrepancy. The English release blog's hard factuality evaluation reports 23.4% → 8.3% at claim level; the Chinese API quickstart reports 23.35% → 6.85%. We do not merge these into one headline reduction or choose the more favorable number. Both describe deliberately difficult evaluation samples, not ordinary traffic error rates.

5. Official prices: international USD and domestic CNY

All token prices below are per 1,000,000 tokens. A 1,048,576-token context window and a one-million-token billing unit are different quantities. International and domestic price lists are quoted separately; the CNY figures are not a currency conversion performed by Modelflare.

International API list prices

Model	Uncached input	Output	Cache read	Cache write, 5m	Cache write, 1h
Kimi K3.1 Pro	$2	$10	$0.20	$2	$4
Kimi K3.1 Pro Highspeed	$4	$20	$0.20	$4	$8
Kimi K3	$3	$15	$0.30	$3	$6

Source: international API pricing, including the price table embedded in the live page. These are the provider's published rates before applicable taxes. K3.1's standard input and output rates are one-third below K3. Highspeed doubles those two rates relative to standard Pro, while the cache-read rate remains $0.20.

Domestic API list prices

Model	Uncached input	Output	Cache read	Cache write, 5m	Cache write, 1h
Kimi K3.1 Pro	¥13	¥68	¥1.30	¥13	¥26
Kimi K3.1 Pro Highspeed	¥26	¥136	¥1.30	¥26	¥52
Kimi K3	¥20	¥100	¥2	¥20	¥40

Source: domestic API pricing. Against the domestic K3 list, standard Pro is 35% lower on input and 32% lower on output. Those percentages differ from the international comparison because the two price lists differ.

Cache writes must not be counted twice

Kimi's cache documentation splits input into mutually exclusive uncached, cache-read, and cache-write portions. For Chat Completions, prompt_tokens is the total; the detailed counters identify cached and written tokens. A token counted as a cache write is not also charged as an ordinary uncached token.

For an illustrative request with separate 5-minute and 1-hour write buckets:

cost = (uncached_tokens * input_price
      + cache_read_tokens * read_price
      + cache_write_5m_tokens * write_5m_price
      + cache_write_1h_tokens * write_1h_price
      + billed_output_tokens * output_price) / 1_000_000

Use disjoint usage buckets when applying this formula. The default cache TTL is 5 minutes; the documented longer option is 1 hour. Keep stable instructions and tools at the beginning of a request and changing task content toward the end. A repeated prefix can be economical; merely making a prompt long does not create a saving.

6. Price comparison with other models

This is an official list-price comparison in USD, not a comparison of Modelflare group discounts, coding subscriptions, or measured quality. Standard online inference is used; taxes, paid tools, regional premiums, and batch discounts are excluded.

Model	Input / 1M	Output / 1M	Cache read / 1M	Price qualification
Kimi K3.1 Pro	$2	$10	$0.20	Standard
Kimi K3.1 Pro Highspeed	$4	$20	$0.20	Faster output tier
Kimi K3	$3	$15	$0.30	Previous flagship
Claude Sonnet 5.5	$2	$10	$0.10	Standard global routing
Claude Opus 5.5	$4	$20	$0.20	Standard global routing
GLM-5.3	$1.40	$4.40	$0.26	Z.AI international API
DeepSeek-V4.1-Flash-1017	$0.30	$1.20	$0.006	Peak hours
DeepSeek-V4.1-Flash-1017	$0.15	$0.60	$0.003	Off-peak hours

Sources: Kimi, Anthropic, Z.AI, and DeepSeek. The current official DeepSeek ID is deepseek-flash; the version behind it is shown in the table. Its peak hours are 01:00–04:00 and 06:00–10:00 UTC on weekdays excluding Chinese public holidays; other hours use off-peak rates.

K3.1 Pro and Sonnet 5.5 have equal standard input/output rates, but Sonnet's listed cache reads cost half as much. Highspeed and Opus 5.5 match on the three columns shown; their cache-write prices differ. GLM-5.3 and DeepSeek Flash offer lower ordinary input/output prices. These observations identify budget candidates, not a universal quality ranking.

Anthropic lists 5-minute cache writes at $2.50 for Sonnet and $5 for Opus, versus Kimi's $2 and $4 for Pro and Highspeed. Its 1-hour writes are $4 and $8 respectively. Z.AI lists cached-input storage as temporarily free. Match the caching policy as well as the headline token price when comparing repeated workflows.

7. A reproducible token-budget example

Assume 100,000 input tokens and 10,000 billed output tokens. Output includes any billable reasoning; it is not a promise of 10,000 visible answer tokens. The cold case has no cache reads and uses standard input pricing, or an equal-priced Kimi 5-minute write. The warm case contains 90,000 cache-read tokens and 10,000 ordinary input tokens, with no new writes. Both exclude external tool costs and retries.

Model / tier	Cold request	Warm request
Kimi K3.1 Pro	$0.300	$0.138
Kimi K3.1 Pro Highspeed	$0.600	$0.258
Kimi K3	$0.450	$0.207
Claude Sonnet 5.5	$0.300	$0.129
Claude Opus 5.5	$0.600	$0.258
GLM-5.3	$0.184	$0.0814
DeepSeek Flash, peak	$0.042	$0.01554
DeepSeek Flash, off-peak	$0.021	$0.00777

Modelflare calculation, not a benchmark. The chart uses the cold column above; it does not include latency or completion quality.

For standard Pro, the cold calculation is 0.1 × 2 + 0.01 × 10 = $0.30. The warm calculation is 0.09 × 0.20 + 0.01 × 2 + 0.01 × 10 = $0.138. At the domestic prices, the same two requests are ¥1.98 and ¥0.927. Multiplying these fixed workloads by 1,000 gives $300/$138 or ¥1,980/¥927, provided the assumptions remain true for every request.

The warm cost omits the earlier request that created the cache. For a whole-session budget, add that initial write, any TTL changes after expiry, and every subsequent request. Keep cost per accepted task alongside token cost: a cheap request that requires several retries and manual repair may not be a cheap completed workflow.

8. API controls and integration details

Context and generation limits

Parameter or behavior	K3.1 Pro / Highspeed
Context window	1,048,576 tokens
max_completion_tokens default	131,072
Maximum configurable max_completion_tokens	1,048,576, constrained by remaining context
When input plus requested output exceeds context	API reduces the generation allowance to remaining space
Input alone	Must be smaller than the context window
Truncation signal	finish_reason: "length"
temperature	Fixed at 1.0
top_p	Fixed at 0.95
n	Fixed at 1
presence_penalty, frequency_penalty	Fixed at 0
reasoning_effort	low, high, max; default max
tool_choice	auto, none, required
thinking	Do not carry the K2-specific switch into K3.1 requests

Sources: Chat Completions reference, parameter reference, and reasoning guide. Fixed parameters should normally be omitted. Sending a different value can fail; changing a generic client's default temperature is an integration concern, not a model-quality problem.

With 900,000 input tokens, only 148,576 tokens remain inside the advertised window before accounting for any further context consumption. Setting the output parameter to one million does not make those capacities additive. Applications should handle a length-limited answer explicitly instead of accepting a truncated JSON object or unfinished patch.

A documented request body

For the official domestic Chat Completions endpoint, POST https://api.moonshot.cn/v1/chat/completions, a bounded streaming request can use the following JSON. Authentication belongs in the client's secret configuration. This example was syntax-checked locally and was not sent to a model.

{
  "model": "kimi-k3.1-pro",
  "messages": [
    {
      "role": "user",
      "content": "Explain how to check a spreadsheet for inconsistent formulas."
    }
  ],
  "reasoning_effort": "high",
  "max_completion_tokens": 16384,
  "stream": true,
  "stream_options": { "include_usage": true }
}

The effort field is intentionally explicit, rather than relying on the model's default. This JSON is for Chat Completions; it is not a Responses or Messages request body. Kimi also documents Responses and Messages, each with its own input and event contract.

Reasoning, tools, and structured answers

Preserve the full assistant message across turns, including reasoning_content and tool_calls; return each tool result using its corresponding tool_call_id. The thinking guide explains the preserved-reasoning contract. Reducing a previous turn to visible content can discard state the next step needs.

Separate reasoning deltas from answer deltas in a streaming UI. Parse the final answer field for application data, and use the final usage record for accounting. A reasoning token stream does not itself establish that a tool ran or that a job completed.

For extraction, Kimi documents response_format with json_schema and strict: true. Validate required fields and business rules after parsing. For tool calls, constrain permissions and handle failures in the application. For a length-truncated response, a retry may need a revised output budget or a smaller task; blind retries can repeat the same failure.

9. Kimi Code membership is a separate product

The Kimi Code configuration page says standard Pro is available from Plus, with 1M context from Pro; Highspeed requires Pro. Legacy plan names are listed separately there. Use k3.1-pro or k3.1-pro-highspeed in that product, not the longer pay-as-you-go API IDs.

Start a fresh session when changing from an older model, and keep the model and effort stable when possible. The provider warns that switching can disturb cached context and behavior. Membership capacity is not a fixed number of API dollars, and a monthly subscription should not be placed in the same column as a per-million-token rate.

10. Choosing a candidate for your workload

Editorial workflow diagram. It illustrates evaluation criteria and is not a screenshot or a Kimi-generated result.

Your priority	Candidate approach	What to measure
Large repository or multi-stage coding work	Evaluate standard Pro first	Accepted change, recovery from failures, total tokens
Interactive work where output wait dominates	Compare Pro with Highspeed	End-to-end latency and extra cost per accepted result
Repeated long prompts	Compare cache policy across Kimi and Claude	Cold start, read/write buckets, hit rate, TTL expiry
Large-volume economical inference	Include GLM-5.3 and DeepSeek Flash	Quality on your data, failure rate, peak/off-peak economics
CAD, scenes, or game assets	Evaluate K3.1 with the actual target tools	Geometry, editability, export compatibility, render result
Research and spreadsheets	Use source-linked tasks and independent checks	Evidence accuracy, formula linkage, numerical reconciliation

These are evaluation recommendations derived from the contracts and prices above. They are not hands-on product endorsements. Fix the input set, tool access, effort settings, stopping rules, and acceptance criteria before measuring models; otherwise a lower bill may reflect a different task rather than greater efficiency.

11. Modelflare availability and next steps

The read-only Modelflare pricing response checked at 18:03 UTC on 23 October listed kimi-k3 in kimi-award and kimi-stable. It did not list kimi-k3.1-pro or kimi-k3.1-pro-highspeed. No K3.1 routing, group price, successful request, or deployment capability is claimed here. Renaming the existing K3 ID in a client is not proof that the new model is available.

For current access, consult models and pricing. For integration background, see the OpenAI-compatible API guide, Responses versus Chat Completions, and API cost tracking.

12. Sources, method, and update record

Primary references are linked beside the claims and tables they support. The factual sources are Moonshot's release and API documentation, its K3 model card, the other vendors' price lists, and Modelflare's public catalog. Prices were checked against both Kimi regional pages; the dynamic price-table data was read from the actual page rather than inferred from a search snippet.

The original contribution is the disjoint-token cost worksheet, two worked scenarios, and workflow acceptance matrix. Artwork follows Modelflare's engineering cover system and contains no fabricated product UI or benchmark result. No live model call was made. Exact K3.1 checkpoint internals, independent speed measurements, and the conflicting factuality figures remain explicitly unresolved.

23 October 2026: First edition, covering the official K3.1 Pro and Highspeed launch, current regional prices, source-qualified parameters, comparison budgets, and Modelflare availability at the recorded check time.