In 30 Sekunden
Matthew Berman tests Kimi K3.1 Pro on a Rubik’s Cube simulator, 3D models, a knot animation and a browser game. He finds impressive rendering alongside spatial mistakes and invented benchmark figures. He also examines the model’s published specifications, evaluations and API pricing, cautioning that benchmark strength does not guarantee the same quality on every practical task.
- 1A convincing cubeThe model produced a 3D cube with scrambling, controls and a solver, passing a test that Berman says often trips up open-weight models.
- 2The knot exposes a weaknessThe Blender rendering and motion graphic failed to show the rope’s crossings clearly enough to teach the knot.
- 3Invented benchmark dataA generated comparison chart used placeholder figures, and the model needed repeated prompts to use supplied data.
- 4Specifications and benchmarksKimi describes a mixture-of-experts model with 2.8 trillion total parameters and 104 billion active parameters; Berman compares published results with his own experience.
- 5Pricing and task costThe displayed API rates and cost-per-task comparison suggest competitive economics, subject to the task and token usage.
Das Wichtigste
- The Rubik’s Cube simulator worked well, but a belaying-knot model failed to represent the knot correctly.
- A polished visual can still contain inaccurate details or invented benchmark numbers.
- Short prompts expose a model’s defaults; detailed prompts are useful when specific results matter.
- K3.1 Pro’s published benchmark and price figures look competitive, though hands-on results vary by task.
Den bearbeiteten Text nach Kapiteln lesen
Testing the 3D cube
Berman introduces K3.1 Pro and tests an interactive Rubik’s Cube. The solver and rendering impress him.
Kimi K3.1 is here: an open-weight model in the three-trillion-parameter class. I signed up, paid for a subscription and used the desktop app to build a series of projects. The benchmarks look impressive, but I also wanted to see what the model could actually produce.
My first test was a 3D Rubik’s Cube. Open-weight models often struggle with the physics: colors disappear, rotations make no sense, or the cube suddenly switches to a solved state. This time the rendering looks realistic, and I can rotate the cube and scramble it using the controls.
The cube is truly three-dimensional, with reflections that change as it moves. It also has keyboard controls, a timer, undo, reset and adjustable turn speed. I noticed the small eyebrow text common in AI-designed interfaces, a style I have also seen in Claude-generated work.
The solver calculates a sequence of moves rather than simply reversing the scramble, then plays the turns out in 3D. The result earns an absolute pass, and it is one of the best versions I have seen. Kimi says the model is particularly good at 3D animation and rendering.
Recent proprietary models have also improved at 3D modeling, while some competitors lag in my experience. These visual tasks are useful tests because a game or model quickly shows what the system can build, even if the result is only one slice of its capabilities.
Rendering a phone
A WebGL phone model looks polished but misses important physical details. Berman asks it to research and revise the design.
Next I asked for a browser-based WebGL rendering of the iPhone Duo. The materials and reflections look good, but the phone itself is inaccurate: the logo is odd and the screen has a large split where it should be unified. Attractive rendering does not necessarily mean a faithful representation.
I asked the model to research the device’s appearance and measurements and try again. The initial render took 28 minutes and 45 seconds; despite using web search, it still missed important details. I used K3.1 Pro with high reasoning effort to keep the test consistent.
The belaying-knot tests
A Blender model and two motion graphics reveal weaknesses in spatial reasoning and instruction. A competing model produces clearer crossings.
A new test combines several skills: model a rope being tied into a belaying knot in Blender. The model must use software, research the knot and reason spatially about overlapping strands. It even visited Blender’s site to find a release, demonstrating web use along the way.
The result has the rough shape of a figure-eight knot, but the rope is not properly knotted or attached to the harness, and the human figure looks strange. I call this a failure. It is a difficult test precisely because the relationship between the strands matters.
I then asked for a motion graphic explaining how to tie the knot. Kimi’s first version was a silent 28-second, 1080p guide covering the figure eight, harness tie-in, retracing and checks. It warned viewers that the animation was not a substitute for instruction.
The problem is that the rope looks like lines drawn together: you cannot clearly see which strand passes over or under another. It resembles the knot but would not teach me how to tie it. The detail that matters most is missing from the visual explanation.
For comparison, GPT-6.1 Sol produced a 54-second silent animation from the same prompt. Its rope path makes the crossings much clearer, and I think I could follow along with a real rope. It also included a warning to learn with a qualified instructor.
I asked Kimi how to make its graphic prettier, then told it to implement its suggestions. The revision added depth, camera movement and better distinction between rope sections, but the crossings remained unclear. It looked better without solving the core instructional problem.
Games, design and video
Kimi builds a browser obstacle game, redesigns a website and assembles a parody video. Berman discusses what short prompts reveal.
Another favorite test is a browser-based Fall Guys clone. I kept the prompt short and asked the model to search for reference videos and images. Short prompts reveal what assumptions a model makes and let me see more of its own design choices.
After about 48 minutes it produced Bean Blitz, a 3D obstacle race with twelve competitors, CPU rivals, moving obstacles, checkpoints, a timer and touch controls. The result was decent for an open-weight model, though the colors were too pastel, collisions were inaccurate and there was flickering.
Simple prompts are fine when I want to explore a model’s defaults. If I have firm preferences about colors, animation, level design or the technology stack, that is when I add specifics. The amount of detail should match how much control I want over the result.
I also asked it to redesign Forward Future’s website. It followed the brand colors and fonts, but the layout still felt recognizably AI-generated and had spacing problems. My verdict was that it looked okay, not that it had produced a finished design.
A viewer requested a deliberately chaotic YouTube Poop-style video of Theo. Kimi reported creating five animated parody clips with its video generation API, orchestrating the edit and soundtrack with Python and NumPy, and using FFmpeg and FFprobe for editing and verification. I was impressed that it assembled the five-minute result.
A misleading benchmark chart
The model invents benchmark numbers before Berman supplies data. He contrasts the resulting chart with his practical experience.
The model sometimes needs more nudging than its competitors. I asked it for a graph comparing model benchmarks; the first chart used broad categories without naming tests. When I requested specific benchmarks, it produced numbers that looked wrong and admitted they were invented placeholders.
I supplied published benchmark figures and asked again. Even then, I had to explicitly ask it to create the image; the final chart largely recreated the source graphic with new colors. This is a reminder to inspect the underlying numbers and not trust a polished chart at face value.
The published benchmarks are strong, but my initial hands-on tests leave me thinking the model is good rather than at the very top of the proprietary field. I speculate about similarities with other systems, but these experiments do not establish how Kimi was trained.
Specifications and evaluations
Berman reviews the model’s architecture and company-reported benchmarks. He separates benchmark rankings from his own tests.
Kimi describes K3.1 Pro as an open-weight model in the three-trillion-parameter class. Its stated specifications include 2.8 trillion total parameters, 104 billion active parameters and a one-million-token context window. As a mixture-of-experts model, it activates only part of its parameters for a given prompt.
The model is multimodal and accepts images; I had not tested video and was unsure about audio. Kimi highlights full-project coding, game development, parametric 3D modeling and finance work. Its claims about matching proprietary models are specifically benchmark claims, which may not predict every real task.
In the company’s chart, K3.1 Pro scores 65.7 on Terminal-Bench 4.0, close to Opus 5.5 at 66.4, and leads SWE Marathon at 51.7 versus 46.3. It performs less well on Terminal-Bench Science. A model can look very different depending on which evaluation is measured.
The chart also shows Kimi close to the leader on GDPval, and at 79.6 on OSWorld, a computer-use evaluation. My own impression of computer use does not perfectly match those rankings. On price-performance curves, the desirable position is higher quality at a lower cost.
Price and final assessment
He compares API prices and cost per intelligence task, then weighs competitive economics against uneven real-world results.
The pricing shown for standard K3.1 Pro is $2 per million input tokens, $10 per million output tokens and $0.20 per million cached input tokens. The high-speed version doubles input and output prices while keeping cached input at $0.20; Kimi says it is two to three times faster.
Kimi’s technical post includes demonstrations of financial modeling and 3D work in FreeCAD and Blender. Those examples look impressive, although I have not yet reproduced all of that quality in my own tests. Open weights also give people the option to download and run the model themselves.
Artificial Analysis places K3.1 Pro at 55 on its intelligence index in the chart shown, ahead of several other models. I also look at cost per intelligence task, which accounts for both token prices and how many tokens a model needs: cheap tokens alone do not guarantee a cheap completed task.
In the displayed comparison Kimi costs $2.11 per intelligence task, substantially below some competing models. Overall I see a capable, competitively priced open-weight model with some excellent results and some obvious failures. Try it yourself and evaluate it against the tasks that matter to you.