Kimi K2.5 to K3.1 Pro: 8 API Models, One Enterprise Task, and What Actually Got Done

I needed to pick a Kimi model for a work project that involves code review, contract field extraction, and requirements validation. The problem was simple: Moonshot AI has released K2.5, K2.6, K2.7 Code, K2.8 Preview, K3, and now K3.1 Pro, each with a high-speed variant.

The directory on my API gateway listed eight IDs. I had no idea which one would actually return a usable, parseable result on the first try.

On November 10, 2026, I sent the same three-part enterprise task to all eight models through a single API endpoint. Three returned complete JSON: kimi-k2.7-code-highspeed in 8.48 seconds, kimi-k2.7-code in 36.53 seconds, and kimi-k2.5 in 32.26 seconds. The current flagship kimi-k3.1-pro hit my 180-second timeout.

This article is for developers who need to make a similar choice and want to know what happened before they commit their own integration time. If you are looking for a million-token stress test, multimodal evaluation, or local deployment guide, this is not that article. I used text-only input, one run per model, and a 5,000-token output limit.

Quick decision table

The lifecycle column matters. Kimi's official platform lists K2.5 as retired and K2.6 / K2.7 Code as closed to new users, with full retirement scheduled by the end of December 2026. Seeing an older ID in an API directory does not extend its official lifecycle.

Why K3.1 Pro is not just "K3 with a bump"

Moonshot AI released K3.1 Pro on October 23, 2026, as a post-trained upgrade to K3. The team increased reinforcement-learning scale across coding, 3D creation, financial research, and multi-step agent tasks. Total parameters are still 2.8 trillion; the meaningful change is training, not a larger foundation model.

There is also a deliberate security trade-off in the open-weight release. Moonshot removed some cybersecurity data from mid-training and RL stages. On the internal xdev-bench-hard, the unfiltered checkpoint scored 90.5%, while the released model scored 81.0%. That is a documented capability reduction, not a defect.

The official Hugging Face repository moonshotai/Kimi-K3.1-Pro now lists the weights and the Kimi K3.1 Pro License. Earlier articles saying "license pending" are outdated. I checked the model card but did not download or deploy the weights.

Kimi version timeline

Specifications I verified but did not fully exercise

I did not test the million-token context, image or video input, or local deployment. A spec table is not evidence that those workloads worked here.

Official benchmarks vs. my delivery scores

Moonshot's published numbers give context, but they do not predict whether a specific API route will return a complete answer within your timeout and token limits.

Moonshot also reports that claim-level hallucinations in an internal stress test dropped from 23.4% in K3 to 8.3% in K3.1 Pro. The company explicitly says this is a difficult-sample result, not an everyday error-rate estimate.

For a third-party launch-day view, The Decoder cited Artificial Analysis: K3.1 Pro scored 55 on the Intelligence Index, 11 points above K3 and fourth at that date. That is a snapshot, not a permanent rank.

Pricing I checked on the official platform

These are RMB per million tokens on Kimi's official Chinese open platform, checked November 10, 2026. They are not aggregated-platform prices and are not my test bill.

K3.1 Pro's list prices are roughly one-third below K3's, but total cost still depends on reasoning output, cache behavior, retries, and tool calls. K3.1 Pro and K3 Batch API usage is listed at 60% of standard pricing.

Kimi Code membership is separate. Plus starts at ¥99/month, Pro at ¥199/month, Max at ¥699/month, and Ultra at ¥1,399/month. Annual billing lowers the effective monthly rate. Go has no Kimi Code allowance; Plus is the entry point, and Pro is required for Highspeed and the highest 1M context tier. Membership and open-platform API billing do not mix.

How I ran the test

I used a non-streaming Chat Completions request with max_tokens=5000, no temperature setting, one run per model, and a 180-second timeout. The task had three parts:

• Code defect analysis: A JavaScript discount function that incorrectly overwrites the discount rate based on array order instead of selecting the highest qualifying tier.
• Contract field extraction: Pull the document type, date, total amount, parties, payment terms, and warranty from a synthetic procurement contract.
• Requirements validation: Identify conflicts and open questions in a conflicting overnight batch-import specification.

Scoring weights: code analysis 30%, document extraction 25%, requirements review 25%, format and call reliability 20%. A zero means no assessable delivery under these conditions, not zero general capability.

The calls went through an OpenAI-compatible aggregated API with Base URL https://api.crazyrouter.com/v1. The Crazyrouter model directory is useful for checking which IDs are currently listed; if you want to run a same-prompt comparison before integrating into your own pipeline, the comparison environment is a convenient place to start.

The eight results

Seven models returned HTTP 200. Only three produced complete JSON. That is the lesson I would carry into an integration checklist: a green status code does not mean your downstream parser has something to work with.

What the three complete answers looked like

kimi-k2.7-code-highspeed found the array-order bug and supplied four regression categories: unordered tiers, exact thresholds, no eligible tier, and invalid rules. It kept the contract total of ¥186,500 separate from the ¥55,950 advance and ¥130,550 balance. It also caught the duplicate-record conflict and flagged the roughly one-hour processing window between 23:00 and midnight. All of this in 8.48 seconds.

kimi-k2.7-code took longer at 36.53 seconds but went deeper on requirements. It identified the idempotency problem between rerunning failed records and preventing duplicate payments, then listed eight open questions. I would keep it for a second-pass review.

kimi-k2.5 was accurate on code and contract but identified only one conflict and three open questions. It used 4,930 output tokens, close to the 5,000 limit. For this task, a longer response did not produce deeper analysis.

What went wrong for the other five

kimi-k2.8-preview returned reviewable code and contract content, then stopped partway through requirements. Its 3.6 score reflects useful partial work with an incomplete final object. I would split the task and retest rather than discard the correct parts.

kimi-k3, kimi-k3.1-pro-highspeed, and kimi-k2.6 all reached the 5,000-token output limit with empty content. kimi-k3.1-pro simply timed out. These are not "model quality" verdicts. They are delivery results under one specific request shape. Changing the prompt length, splitting the task, or adjusting the output budget could shift the outcomes.

What matters for integration is that you check content, finish_reason, and JSON parsing before you treat HTTP 200 as success.

Choosing between Kimi and alternatives

If your main workloads are long-context programming agents, 3D modeling, financial documents, or multi-step agents, K3.1 Pro belongs in the candidate list. Its Terminal-Bench and OfficeQA Pro v2 scores are above DeepSeek V4.1 Flash, but DeepSWE is slightly lower. There is no universal winner.

If you are already using Claude Opus 5.5, K3.1 Pro's appeal is more about open weights, the one-million-token context, and official API pricing. BenchCAD still favors Opus 5.5.

If you only care about this specific three-task delivery profile, kimi-k2.7-code-highspeed was the fastest complete result. But K2.7 Code is in a migration period, so a new long-term project should verify route availability before committing.

Common questions

Does the zero for K3.1 Pro mean the flagship is broken? No. It means this single request did not produce assessable content within 180 seconds. Official specs, public benchmarks, and one API run answer different questions.

Can K3.1 Pro disable reasoning? No. The official API docs say reasoning is always enabled. You can lower the effort level; you cannot turn it off.

Are Kimi Code membership and open-platform API the same bill? No. Kimi Code shares a subscription allowance with Kimi membership. The open platform charges per token. They do not mix.

Can I use the model IDs from this test directly in Kimi Code? Not blindly. Kimi Code lists k3.1-pro, k3.1-pro-highspeed, k3, k3-256k, kimi-for-coding, and kimi-for-coding-highspeed. Client IDs and aggregated-API route IDs are separate namespaces.

Which one would I try first in production? For this exact task profile, kimi-k2.7-code-highspeed. For a new long-term project, I would verify the route lifecycle and rerun short tasks against K3.1 Pro before writing anything into production config.

Sources

• Kimi K3.1 Pro technical blog: release background, benchmarks, and security decisions.
• Kimi model list, changelog, and API pricing: lifecycle and price checks.
• Kimi K3.1 Pro on Hugging Face: weights, model card, and license.
• Kimi Code model configuration and membership rules: client IDs and plan requirements.
• The Decoder's launch-day report: the external Artificial Analysis observation.

Disclosure

I wrote and edited this article myself. AI tools assisted with language checks and formatting, while the test design, API runs, result review, and final conclusions were completed and verified by me.