Kimi K3.1 Pro in depth: long coding tasks, 3D work and real operating costs

The interesting question about Kimi K3.1 Pro is whether it can keep a long task moving: understand a project, edit code, use tools and recover when the result fails. An attractive first screen covers only a fraction of that work. After the tenth revision, do the original features still work, and does the deliverable pass acceptance checks?

The models covered here are Kimi K3.1 Pro and Kimi K3.1 Pro Highspeed. Sources were checked on October 23, 2026. Numerical results come from official material. Folkbench did not call these models or rerun their benchmarks for this article, and is not assigning an independent score.

Identify the model first

Identity and positioning come from the model list, the exact context size from billing documentation, and interface capabilities from the quickstart. The technical blog describes post-training on K3 and supplies the weight-release plan. A version number alone does not establish a new underlying architecture; a release plan does not establish that local deployment is already available.

Two benchmarks, two different questions

These numbers are the comparison published in the Kimi technical blog. The competitor columns also come from that page, rather than a Folkbench experiment with a common environment.

The footnotes specify max effort by default. Kimi's Terminal-Bench run uses Claude Code; competitor results are collected from releases or leaderboards. BenchCAD tests open models on a 1,000-case subset, also using Claude Code for the tool-assisted setting. Those conditions belong alongside the scores.

Coding: a close score still needs project-level acceptance

65.7% and 66.4% differ by 0.7 percentage points. They are close in this published table. Without matched budgets, repeat counts and uncertainty estimates, that is insufficient to claim equal capability. A higher score than another model on one evaluation likewise does not establish superiority across coding tasks.

Error recovery matters in real projects. A request may require an interface change, updates to callers and preserved compatibility, all without breaking existing behavior. The amount of code generated on the first attempt says little about those obligations. The model must understand what a failing check means instead of removing an assertion, weakening a condition or dropping a feature to get a pass.

Before migration, replay a previously solved task with clear acceptance criteria. Fix the repository revision and requirements, let each candidate work independently, then examine test results, change scope and manual repair. That record supports a decision better than a polished demonstration. This is a proposed acceptance exercise, not an experiment performed for this article.

3D: geometric overlap is only part of a deliverable

The BenchCAD metric here is Voxel IoU. A value of 92.7% is neither a 92.7% task-success rate nor an artistic quality rating. Geometry, materials, lighting, animation, editability and manufacturing tolerances require different checks.

For a Three.js scene, inspect working interactions, device performance and resource loading. For an editable part, inspect dimensions, behavior after parameter changes and exported files. A convincing rendering from one angle can hide missing surfaces, intersecting geometry or unusable topology.

Our editorial assessment from these official results is that K3.1 Pro merits consideration for long coding tasks and programmatic modeling. Whether it replaces an existing solution should depend on the target project's deliverables.

Million-token context answers a capacity question

The number of files that fit into 1,048,576 tokens depends on content and tokenization. It is not a fixed word count or line count. Capacity also does not guarantee that a model finds the right evidence, retains every constraint or follows the original objective after many tool calls.

Sending an entire repository can bring generated files, obsolete documentation and conflicting instructions along with useful code. Specify the current revision, relevant files, behavior that must remain unchanged and the acceptance entry point. Useful context matters more than indiscriminately increasing it.

There is also a recurring cost. The official thinking-model documentation requires historical assistant reasoning to be retained; it continues to occupy context and participate in billing. A short visible answer can therefore accompany a much larger token bill.

API settings can change the experience

The reasoning-effort guide says K3.1 Pro always reasons and defaults to max. Selecting low reduces effort; it does not turn thinking off. Align effort before comparing latency, or an apparent speed difference may reflect different budgets.

Check three things when migrating:

1. Use top-level reasoning_effort instead of carrying over K2's thinking configuration.
2. Preserve complete assistant messages in tool loops, including reasoning_content and tool_calls. Keeping only the final prose discards required history.
3. Follow the quickstart for vision: use base64 or ms:// file references rather than assuming arbitrary public image URLs are accepted.

A relay adds questions of its own: does it preserve fields, truncate responses, remap the model name or omit usage details? A successful text response does not establish that the surrounding agent's tool loop works correctly.

Cost starts with the whole task

The official pricing page and its Markdown version did not return a complete, verifiable K3.1 Pro price row during this check. We therefore publish no dollar rates and do not substitute K3 or relay prices. This does not prove that official prices are unpublished; it describes what this article could verify.

The billing structure is documented: API usage is metered separately from Kimi membership and Kimi Code; cache writes vary by TTL, while cache hits and uncached input have separate billing categories. The quickstart describes pricing without context-length tiers. The cache guide documents reuse and retention behavior.

Separate cache misses, writes, reads and generated output when assessing a long-context task. Tool services, execution environments and failed retries may add spending. Follow the bill's actual categories so the same tokens are not counted twice.

A useful procurement measure is total spending on the batch divided by accepted tasks. Failed attempts stay in the numerator; if all tasks fail, there is no successful-task price to report. This is a suggested comparison method, not a measured Folkbench result.

The model list describes Highspeed as retaining the same capability at roughly 2–3× speed. That is a supplier claim, not an end-to-end workflow measurement. If generation takes half the total time, reducing that half to one third brings total time from 1 to about 0.67: roughly 1.5× overall speed. This hypothetical calculation illustrates a bottleneck, not observed Kimi latency.

Where to start evaluating it

The first three match its positioning, but positioning does not guarantee quality. In research, fluent prose and many citations cannot replace checking whether a source supports each claim, dates and units agree, and spreadsheet formulas can be recomputed. For simple classification, a flagship running at default max may not be economical.

Folkbench's assessment

The official material gives K3.1 Pro a credible reason to enter a serious evaluation: its coding and programmatic-modeling results sit near strong comparators. Practical value depends on converting those capabilities into accepted deliverables with your inputs, tools and budget.

This article lacks independent call records, repeated trials, failure distributions and verified unit prices, so it offers neither a composite score nor a best-value claim. Some benchmark passages in the quickstart still contain placeholders and differ in version from the technical blog. The two comparisons above use the blog consistently rather than combining versions.

For code workflows, continue with the [Folkbench software-engineering evaluation guide](/en/blog/ai-api-relay-software-engineering-evaluation-guide). Related model coverage includes [Claude Opus 5.5](/en/blog/claude-opus-5-5-review-pricing) and [GPT-6.1 Sol](/en/blog/gpt-6-1-sol-review-pricing). Sol is not the GPT-6 Astra in the table; their identities and scores are not interchangeable.