Kimi K3.1 Pro in the Trenches: 9 Minutes to Fix a Stubborn Bug That Beat Other Models, Backed by 270K Lines of Code

Hello everyone, I am Meng Jian.

Over the past 3 months, I've worked alone with multiple AIs to write 270,000 lines of code.

Completed nearly 3,000 commits.

My annual spending on subscriptions for various AI tools is around 17,000 yuan.

In this one-person company commercial delivery system, I choose models based on two accounts.

One is token billing cost.

The other is the delivery rate for real engineering troubleshooting.

From October 23 to 24, Moonshot AI officially released Kimi K3.1 Pro.

Coincidentally, my self-developed content distribution tool "Ziliu" has been carrying an old bug.

Several models couldn't fix it before.

This time I directly threw the task to K3.1 Pro for a real test.

From pressing Enter to reproduction, modification, and verification, the whole process took about 9 minutes.

To be honest, I didn't expect that I didn't write a single line of code throughout.

In this post, I'll thoroughly break down its benchmark scores, API cost breakdown, and the complete engineering workflow of fixing a bug and building a frontend landing page.

First look at benchmarks and math

K3.1 Pro uses a mixture-of-experts architecture with a total parameter scale of 2.8 trillion.

Officially it's called a 3-trillion-parameter model.

It activates about 104 billion parameters each time.

Context window supports 1 million tokens, so very long codebases and documents can be read in at once.

Officially committed to open-sourcing the complete model weights before November 4, 2026.

On the AA leaderboard of third-party evaluation agency Artificial Analysis, K3.1 Pro scored 55.

Ranked fourth globally.

The the-decoder report on October 24 mentioned that only three models are ahead of it.

Those are Claude Opus 5.5 (58), Claude Sonnet 5.5 (56), and Muse Wonder Full (56) which hasn't opened its API yet.

Looking at domestic models, Xiaomi MiMo, Tongyi Qianwen, DeepSeek, and GLM are all around 45.

K3.1 Pro directly pulls a full 10-point gap.

Compared to previous generation K3's 44, it rose 11 points.

For the first time, a domestic model is this close to Claude.

The AA leaderboard looks at composite score.

As an independent developer, I care more about programming and command-line practice.

Pick three core benchmark data points.

One is SWE Marathon v1.1 which tests long continuous coding; it scored 51.7%.

Directly ranked first.

This result beats Claude Opus 5.5's 46.3% and also exceeds GPT-6 Astra's 42.5%.

For Agents' Last Exam which tests AI doing work autonomously, it also ranks at the top.

For Terminal-Bench 4.0 which tests real restricted terminal tasks, it got 65.7%.

Previous generation K3 only had 13%.

This score is only 0.7 percentage points lower than Claude Opus 5.5.

But it's 7.5 percentage points higher than GPT-6 Astra.

Now calculate the token bill that independent developers care most about.

OpenRouter and official pricing show that K3.1 Pro's API price is about one-third lower than the previous generation.

Domestic standard version input is 13 yuan per million tokens, cache hit is 1.3 yuan.

Output is 68 yuan per million tokens.

Domestic high-speed version input is 26 yuan, output 136 yuan.

Overseas USD version: standard version input $2, cache hit $0.2, output $10.

High-speed version input $4, output $20.

Think about it, leading in benchmarks doesn't mean it's all-powerful in every scenario.

Between theoretical benchmarks and real business codebases, there's always an engineering boundary.

Back to the earlier question, does it actually work in real projects?

Below is the direct real test.

My self-developed product "Ziliu" has accumulated 192 commits within a year.

Inbox has adopted over 1,300 comments and private messages.

After writing a draft, it can one-click distribute to various platforms.

Among them, the X long article chain has always had a flaw.

An article with 11 images, when auto-inserting, always loses one.

It only ever inserts 10.

And a string of garbled placeholder text remains in the body.

Every time I have to open the draft, manually add the image, and delete the text.

What's the difficulty here?

X's editor has its own mechanism for recording cursor position.

If the program forcibly moves the cursor from outside, the editor may not recognize it.

The result is the program thinks it selected the placeholder text, but actually selects something else.

More troublesome is that this problem only triggers in a real logged-in X page.

The automated tests I normally write can't detect it.

This kind of task requires more than just writing code.

It needs to be able to read code, run itself to reproduce, and verify itself.

This time I used the official command-line programming tool Kimi Code.

Start it with one command in the project directory, directly calling K3.1 Pro.

kimi -m kimi-code/k3.1-pro --yolo

The --yolo flag allows it to read/write files and run commands without stopping to wait for my confirmation.

Only in my own project, and when changes can be tracked by git, do I enable this.

My prompt wasn't complicated, just four strict rules.

First, the phenomenon: explain that 11 images only insert 10, leaving a placeholder, with the log's exact wording.

Second, a reproduction command: give a command that can run directly.

Third, modification scope: only modify the specified file, no other files.

Fourth, a red line: only save draft, never publish.

After changing, it must run verification by itself, then tell me the reason and result in Chinese.

9 minutes of zero human intervention in troubleshooting

The first step after K3.1 Pro took over is what impressed me most.

It first read the 3 related files.

It didn't rush to modify code; instead it ran my reproduction command exactly as given.

The log immediately caught the culprit.

The program had intended to select the placeholder text, but actually selected a paragraph heading.

Many AIs' first reaction to a bug is to guess the problem and directly fix it.

K3.1 Pro's order is correct.

Reproduce first, then act.

That's how an experienced engineer works.

After locating the root cause, its fix was clean.

It no longer forcibly moves the cursor from outside.

Instead, it simulates a mouse click on the placeholder text, letting the X editor sense the cursor position itself.

The original code's validation guard of "if the selected text isn't correct, don't delete" was fully preserved.

After modifying the code, it immediately ran the build and reproduction commands.

It also checked git status to confirm only the allowed file was changed.

A few minutes later, it gave a three-part summary: root cause, fix, and verification result.

Images 11/11, remaining placeholders 0, never hit publish.

I then ran my own verification.

Opened the X draft and checked paragraph by paragraph against the original.

All 11 images in place, not a single garbled placeholder left.

This hard nut that several models couldn't crack was solved in 9 minutes.

Bug fixing tests engineering logic, but I care more about its frontend aesthetics and delivery loop.

I asked it to make a landing page hero section for the Ziliu desktop version, plus one screen with three selling points.

My constraints were clear.

It should have design sense, not the ubiquitous purple gradient template.

Chinese typography should be refined, with responsive adaptation for both desktop and mobile.

Strictly no fake data like user counts or ratings.

I also attached two frontend design skills, taste and impeccable.

Its workflow was solid.

First it set the visual direction, wrote a one-page product description, then started coding.

After writing, it launched the browser itself and took screenshots at desktop and mobile dimensions for checking.

In the first self-check, it spotted 3 issues.

Including the mobile panel falling out of the orange area, the description not clearly stating the product, and the second screen's interface being too small.

It fixed the code and re-checked until all checks passed.

The design concept it gave was "Chinese movable-type proofing table".

Using graphite black, paper white, and signal orange instead of templated AI gradients.

Directly turning "one original draft distributed to different platforms" into the main visual.

The hero headline was "Write once, each takes its own form."

The right panel can directly switch to Xiaohongshu, Zhihu, or Douyin with clicks.

The same original draft renders in real-time into the corresponding platform's layout.

The second screen's three selling points come with interface mockups, not cheap cards.

When switching to phone size, the layout automatically becomes single column.

Which pitfalls you need to know in advance

In real testing, K3.1 Pro's engineering capability is indeed impressive.

But as the main tool for a one-person company, I must mention some objective shortcomings.

First, it still lags on super-long difficult tasks.

On the AA leaderboard, Claude Opus 5.5 is 3 points higher.

In the officially published long-range programming evaluation, its score rose from K3's 55.95% to 61.2%.

But it still lags behind GPT-6 Astra, with a larger gap in scientific command-line tasks.

Officially it also admitted that after removing cyber attack/defense data, pass@3 on safety tests is 81.0%.

Cybersecurity capability indeed still lags behind closed-source frontier models.

Second, reasoning speed is somewhat slow.

Fixing that X editor bug took 9 minutes.

Making the landing page plus multiple self-checks ran over half an hour, with one connection break in between.

If you're sensitive to response speed, I suggest switching to the Highspeed version released simultaneously.

Official data says output can be 2-3 times faster, but API cost doubles.

Third, subscription quota burns extremely fast.

This is what I want to complain about most.

Fixing bugs and building pages requires several rounds of testing and screenshots, consuming a huge amount of tokens.

This time, just as I was about to test, Kimi Code warned that this week's quota was exhausted, either wait for refresh or buy more.

On October 26, the official account @月之暗面Kimi also issued an apology.

Admitting that members encountered rate limiting and unnecessary quota consumption during usage, and reset the quotas.

If you're an independent developer extremely focused on delivery output, my conclusion is clear.

If you have a complex engineering bug that's been dragging on, or need high-quality frontend interfaces, I highly recommend it.

But for ultra-large-scale cross-module long-term refactoring, or if you demand extremely high response speed, I suggest waiting a bit.

Finally, here's the troubleshooting prompt template for you, copy it into your project and use it directly.

1. Fault phenomenon: [describe specifically how many images are missing / what error appeared, paste the terminal log verbatim]
2. Reproduction command: [provide a test or build command that can be executed directly in the current directory]
3. Modification scope: [explicitly list the allowed file paths, strictly forbidden to touch other files]
4. Acceptance red line: [explicitly forbid operations like publishing/deleting database, require running the reproduction command again after changes, and output root cause, fix, and verification result in Chinese]

In the next phase, I'll test more models in my overseas product matrix.

What's the most troublesome engineering task you've recently had AI handle?

Feel free to discuss in the comments.

---

👋 I'm Meng Jian, former Tencent T11, former ByteDance tech leader, now full-time AI coding.

🔥 More AI coding practical content:

• GitHub: @mengjian-github
• Column: AI编程实战
• Full list for this issue: reply "编程实测" in the comments, I'll send you the access method.

Useful? Like + Save is the biggest support 🙏

This article was organized by the author with AI assistance, and content has been tested and reviewed by the author.