Kimi K3.1 Leaks: Three.js Demos and the 1/14 Cost Claim

On this page

1. Is Kimi K3.1 released, or is this still a leak cycle?
2. Why does the pelican-on-a-bicycle test matter for a coding model?
3. What do the other 3D demos add?
4. How big is the reported cost gap, and how should you read it?
5. Where does Kimi K3.1 still fail?
6. Why would code-first rendering produce better 3D scenes?
7. What should you test before you switch?
8. What is still unknown?
9. FAQ

The demo descriptions and cost figures below are reported accounts, not independently reproduced benchmarks.

Kimi K3.1 is being discussed as if it has launched. The official API model list checked on October 23, 2026 does not list it. A teaser lands, someone freezes a frame and spots the name, and within hours the internet has a spec sheet. This time the spec sheet is mostly a set of demo clips, and they are worth watching anyway. They show something more specific than another leaderboard score: a model writing graphics code, rendering it, and fixing its own scene.

That distinction matters if you build interactive pages, product configurators, data rooms, or training material for the browser. Most of that work is not an image problem. It is a geometry and state problem, and a model that can iterate on code is a better fit than a model that samples pixels. It also sets a clear limit, which the giraffe clip exposes.

Is Kimi K3.1 released, or is this still a leak cycle?

It is still a leak cycle. The supplied report identifies a teaser as the official signal. Everything else is a trail of configuration strings, menu entries, and anonymous leaderboard names that testers have connected to each other.

The trail starts in late September, when developers reported finding kimi-k3-1 in the configuration files of Moonshot's API platform. On October 21, a K3.1 option appeared in the model switcher inside Kimi Code, which looks like a small, controlled test rather than a launch. Around the same time, two strong anonymous models, Kibitz and Kalmia, showed up in Arena blind tests. Kibitz did well on frontend and 3D code tasks. Developers matched the name to an earlier naming pattern: K2.5 was Kiwido, K2.6 was Kiwire, K3 was Kivine, so K3.1 would be Kibitz. That is a reasonable guess, not a confirmation.

The report also describes a pull request in the SGLang repository with a new Medium thinking level, which would take K3.1 from three reasoning tiers to four. A directly accessible pull request was not established for this account, so the fourth tier remains a reported detail rather than a verified API feature.

Why does the pelican-on-a-bicycle test matter for a coding model?

The prompt asks the model to build a pelican riding a bicycle in Three.js. It sounds like a joke, and it is a good geometry test. There is no stock asset to copy. The model has to understand the bird's body, the bicycle's mechanics, and the contact points between them, then place both in one scene with a camera and lights. A strong result needs three things at once: concept composition, physical intuition, and spatial reasoning.

Older models failed in ways that are easy to see. Claude 3.5 drew a bicycle as two circles and a triangle and turned the pelican into a round body with a banana-shaped beak. In the K3.1 clip circulated by testers, the arrangement is deliberately absurd. The bicycle sits on top of the pelican instead of the other way around, yet the stack holds together. The bird's weight looks supported, and the frame looks stable. The scene around it is dense: a crescent moon, hills against an orange sunset, a striped lighthouse throwing a beam, a cottage with warm windows, waves, a crab, and a sailboat in the distance.

The output was reportedly Three.js scene code, not a sampled image. The model wrote geometry and rendering instructions, and the browser drew them. One tester compared the finish to Claude Opus 5.5. That comparison is a personal judgment from a single clip, but the underlying point stands. A scene like this is assembled from objects with positions, not from pixels with plausible colors.

What do the other 3D demos add?

The pelican is the memorable one, but the other clips point at the same skill from different angles. A medieval castle shows dense architecture with towers, flags, a drawbridge, a moat, hills, and birds, all under one late-day light. A floating island tower adds vertical structure and attached stairs. A steam train goes further: the model splits the locomotive into separate parts, including the boiler, cars, tanks, and red wheels, and floats them in an exploded view with each part still in the right place. Another tester reports a working interactive helicopter model in 15 minutes, with adjustable speed and live data readouts.

None of these demos is a render of a single object. Each one is a small system. A dashboard needs charts and a 3D view to share one coordinate space. A simulation needs timed events that stay in sync with geometry. An exploded view needs every part labeled and positioned so a viewer can map it back to the whole. The early demos suggest K3.1 handles that class of work better than it handles freeform animation, which is a narrower claim than "it can do 3D" and a more useful one.

How big is the reported cost gap, and how should you read it?

Two numbers are circulating, and both come from testers rather than from Moonshot. The first is a comparison on a Minecraft-style build task. GPT-6 Astra produced a robot-shaped structure, K3.1 produced a spherical one, and the tester reported that K3.1 cost about one fourteenth of the other run. The second comes from a tester who spent a week with the model and reported that K3.1 costs about 70% of what Kimi K3 costs.

A 14x gap is the kind of number that changes purchasing decisions, which is exactly why it needs a methodology. The post did not say how the cost was measured, how many attempts each model needed, or whether both outputs were accepted on the first try. A cheap run that needs four retries is not cheap. The 70% figure compares two members of the same family, but the task conditions and billing basis are not published, so it is still a single report.

The more useful comparison might be the one against Haiku 5.5. Both models built a village scene with a dragon attack, a thunderstorm, and a day and night cycle. Each took about 15 minutes. Testers who commented generally preferred the K3.1 look. That is a preference poll, not a benchmark, and it says more about visual taste than about correctness. Still, it points at the actual buying question: if two models finish in the same time, which output needs fewer manual repairs?

Where does Kimi K3.1 still fail?

Motion. In a test framed as "which model can catch Claude Opus 5.5," four models were asked to animate a running giraffe. Testers described the K3.1 result as biologically wrong. The legs did not follow a believable gait, and the movement read as strange rather than fast.

This failure is consistent with how the model seems to work. Placing a lighthouse, a moon, and a crab in one scene is a layout problem. Making a giraffe run is a simulation problem. The model has to keep a skeleton consistent across frames, transfer weight through the legs in the right order, and preserve speed and balance. A single frame can look correct while the sequence falls apart. The same code-first loop that catches a misplaced wheel may not catch a bad gait, because each frame can look acceptable on its own.

One clip from one comparison cannot show how large the weakness is, but it does flag a possible weakness to investigate. If your work depends on believable character motion, treat this as the first thing to test, and do not assume that strong static output carries over.

Why would code-first rendering produce better 3D scenes?

The reported workflow is close to how a developer would build the scene by hand. The model reads the brief, plans the geometry, writes Three.js code, renders a frame, inspects the result, and patches the code when something looks wrong. If a wheel is flat or a light points the wrong way, the fix happens in the source, not in a new sample. The loop can repeat until the scene holds together.

Image models work differently. They sample pixels from a learned distribution. That is excellent for texture and mood, and weak for exact contact points, because those contact points are not necessarily represented as explicit scene geometry. The code-first approach makes those relationships explicit. It also produces something a developer can keep: a scene file, not a flat picture.

This did not appear overnight. Kimi shipped K1, a visual reasoning model, in December 2024. In April 2025 it open-sourced the Kimi-VL family, built on MoonViT, with 2.8 billion active parameters, and matched much larger models on MathVision and OCR. In July 2026 it released Kimi K3 at 2.8 trillion parameters, which took first place in the Arena frontend code category and led six frontend areas. K3.1 looks like an extension of that line into 3D and interactive work, with a reported focus on longer agent tasks through post-training and computer-use data.

What should you test before you switch?

Wait for the model card, then run a small evaluation of your own. The demos are useful for choosing what to test, not for deciding what to ship.

1. Rebuild one real scene. Pick a page or configurator you already maintain and ask for it in Three.js. Compare the result against your current model, not against a demo clip.
2. Count cost per accepted scene. Include retries, failed renders, and manual fixes. A model that costs less per token and needs three extra attempts may cost more per deliverable.
3. Check materials and lighting. Look for flat shading, blown highlights, missing shadows, and textures that stretch at close range.
4. Test one animation. A walk cycle, a rotating mechanism, or a camera path will expose timing problems that a still frame hides.
5. Inspect the output format. Confirm that you get readable code with named objects, not a compressed blob that nobody can edit.
6. Verify API terms. Model ID, context limit, rate limits, latency, and price should be in writing before anything moves to production.

What is still unknown?

Almost every number that would matter to a buyer. The supplied report provides no confirmed public K3.1 model ID, context window, price, rate limit, weight release date, or benchmark table with a harness. The official API model list checked on October 23 does not list K3.1. The October launch window comes from reporting, not from Moonshot. The 14x and 70% cost figures have no published method. The giraffe result has no frame count or scoring rubric. A Nomura report cited by the original article says Moonshot is working on a 5 to 6 trillion parameter model, which people are calling K4, and that compute supply is the main constraint. That is a report about a different model, not a K3.1 fact.

For now, the only thing a developer can plan around is the direction of the work. If the code-first loop holds up, the useful comparison is not image quality. It is how many iterations it takes to get a scene you can ship, and whether the result stays editable afterward. That is a test you can run in an afternoon once access is real.

FAQ

Is Kimi K3.1 released?

K3.1 is not listed in the official Kimi API model list checked on October 23, 2026. The supplied report describes a teaser and limited testing, but does not establish a public release or confirmed API terms.

Is Kimi K3.1 the model behind the Arena entries Kibitz and Kalmia?

That is the community's inference, not an official statement. The names follow a pattern used in earlier Kimi Arena entries, but Moonshot has not linked either entry to K3.1.

Can Kimi K3.1 be used for Three.js or WebGL projects today?

Testers reportedly had limited access, and the supplied report says a K3.1 option appeared in Kimi Code on October 21. Public API access, rate limits and pricing are not established here; verify those terms before planning production use.

How much cheaper is Kimi K3.1 than GPT-6 Astra?

One community comparison of a Minecraft build task reported about one fourteenth of the cost. A separate tester reported K3.1 at 70% of Kimi K3's cost. Neither figure includes a published prompt, retry count, or scoring method.

What is Kimi K3.1 weak at?

Motion. In a four-model test, a running giraffe moved in a way testers described as biologically wrong. Static composition and lighting looked strong, but believable gait and timing did not.