Kimi K3.1 Pro · Community source · Personal experience
In the pi.dev harness, the author had Kimi K3.1 Pro generate a high-fidelity 3D “pelican riding a bicycle” scene; a single prompt was insufficient, and only after several rounds of “enhance it further” did the author obtain the result shown. The case provides a usable signal about multi-turn Agent workflows, but the iteration counts, budgets, and completion criteria on the two sides were not aligned, so it cannot be called a controlled win for Kimi over Claude Opus 5.5.
In the pi.dev harness, the author had Kimi K3.1 Pro generate a high-fidelity 3D “pelican riding a bicycle” scene; a single prompt was insufficient, and only after several rounds of “enhance it further” did the author obtain the result shown. The case provides a usable signal about multi-turn Agent workflows, but the iteration counts, budgets, and completion criteria on the two sides were not aligned, so it cannot be called a controlled win for Kimi over Claude Opus 5.5.
Tasks this can help assess: Kimi K3.1 Pro's performance in generating 3D scenes, making successive modifications, and iterating on visual artifacts in pi.dev.
Tasks this should not be generalized to: General 3D capability rankings, one-shot prompt success rates, cost or speed comparisons, or a fair win-or-loss judgment against Claude Opus 5.5.
Model version covered: Kimi K3.1 Pro; the author used a single-generation Claude Opus 5.5 case from its launch as the comparison.
Test environment or client: pi.dev harness; the specific Agent version, tool permissions, model endpoint, and runtime environment were not specified.
Reasoning levels and parameters: Not specified.
The author published a Reddit video and explained:
The task was to create a high-fidelity 3D scene of a pelican riding a bicycle.
Kimi K3.1 Pro completed the task in the pi.dev harness.
Sending the task prompt once was not enough, so the author then sent “enhance it further” multiple times to request further improvements.
The author compared this multi-turn result with a result obtained from a single prompt when Claude Opus 5.5 was released.
The original post did not disclose the complete prompt, the messages from each round, tool definitions, run logs, a code repository, model parameters, iteration count, token usage, elapsed time, cost, or acceptance checklist. The video player displayed approximately 45 seconds on the page; the page provided no downloadable structured output or independent quality score.
| Observation | What the original post confirms | Evidence boundary |
|---|---|---|
| Task | A high-fidelity 3D pelican riding a bicycle scene | No complete specification or acceptance criteria were disclosed |
| Kimi workflow | The pi.dev harness was used, with multiple enhancement rounds after the single prompt | The specific number of rounds, tool calls, and changes in each round were not specified |
| Initial prompt | “Create a high fidelity scene of pelican riding a bicycle” | This is one publicly visible task description, not the complete run prompt |
| Follow-up prompts | “enhance it further” was used multiple times | The context and output for each enhancement were not disclosed |
| Comparison | The author linked to a single-generation Claude Opus 5.5 case | The comparison case's run conditions were not reconstructed in this post |
| Visible artifact | A 3D scene demonstration in the Reddit video | No code, screenshot sequence, or independent quality score was provided |
The author's own words clearly state that one “Create a high fidelity scene of pelican riding a bicycle” prompt was insufficient and that multiple “enhance it further” prompts were needed. This article therefore records it as a “case after multiple enhancement rounds” and does not rewrite the displayed result as Kimi's one-shot prompt capability.
The visible text of the main post included the author's excitement at seeing a model that was about to become open-weight achieve good quality in 3D development; the use of Kimi K3.1 Pro and the pi.dev harness; the statement that a single prompt to create a high-fidelity pelican-riding-a-bicycle scene was insufficient, followed by multiple “enhance it further” prompts; and a link to the single-generation result the author obtained when Claude Opus 5.5 was released: https://www.reddit.com/r/ClaudeCode/comments/1wnhlrn/opus_55_create_a_high_fidelity_scene_of_pelican/.
The visible replies under the main post were:
u/Important-Damage-173 thought Kimi was not always bad and mentioned that its performance exceeded Google's best model; the user also speculated that Kimi might not yet be able to generate video.
u/xenquish thought running a local model at low cost was exciting.
The author, u/blaind0, replied that this Kimi model has a 3T scale and is therefore mainly used through APIs; the author hoped more providers would bring lower costs.
u/wiggle_room1337 commented sarcastically, “Excellent? More like barely not bad.”
These replies did not add the number of test rounds, cost, scores, the full prompt, or run logs. The author's reply about “3T, mainly through APIs” describes how the model is used; it cannot serve as cost data for this task.
This is a publicly demonstrated personal field report, with an evidence level of personal experience.
The narrowest conclusion it supports is that, in the pi.dev harness, Kimi K3.1 Pro needed multiple “enhance it further” rounds to reach the high-fidelity 3D pelican scene shown by the author.
Kimi and Opus 5.5 had different iteration budgets: the former received multiple additional enhancement prompts, while the latter was described by the author as using a single prompt. Therefore, this cannot be called a controlled win, a one-shot prompt win, or a cost win.
The original post did not provide a rubric, scores, success rates, elapsed time, token usage, billing, the complete prompt, tool traces, or version-locking information, so it cannot establish a reproducible ranking.
The visual quality shown in the video was affected by the author's choice of follow-up prompts and stopping point; it should not be attributed to a single capability of the model.
The author's description of 3T and API usage cannot be used to derive the actual price of this task or generalized into a cost conclusion for all providers.
At minimum, reproduction would require fixing the Kimi K3.1 Pro model endpoint, pi.dev harness version, tool permissions, context, prompts, maximum number of rounds, stopping conditions, and rendering environment. When comparing Opus 5.5, the initial task, iteration budget, and visibility conditions should be the same.
Each run should save the complete messages and tool traces, every round's output, code, rendered frames, elapsed time, token usage, and cost, and should define the geometry, materials, animation, interaction, and error criteria for the 3D scene in advance. Only when these conditions are consistent and a rubric and repeated runs are available is it appropriate to compare model results; the public content of this post is insufficient to complete that reproduction.
The figures, task set, reasoning tier, and client conditions apply only to the listed source and collection snapshot. Different versions, harnesses, or providers must not be compared directly; undisclosed parameters remain unknown.
For a reproduction, fix the model version, provider or client, reasoning tier, tools, task-set version, sample count, and collection date, and record failures, retries, and human corrections. Full steps are in the source notes below.
Reddit, r/aigamedev · u/blaind0 · Original publication date 2026-10-23 · Site edit date 2026-10-24
Open original sourceKimi K3.1 Pro
Download the Tabbit client to check model access