Kimi K3.1 has appeared in a video posted by Moonshot AI's official Kimi account, giving anyone following the next model a concrete preview to examine. The opening places the model inside Kimi Code and pairs it with a request to build a procedural 3D scene. For developers and creators, that makes creative programming the clearest theme of the teaser.
The official Kimi post, dated October 23, is brief: approximately 24 seconds of terminal footage and visual sequences. It establishes that the company is publicly showing the K3.1 name. It leaves the release schedule, pricing, and measurable improvements over K3 unanswered.
What the Official Kimi K3.1 Teaser Shows
The video opens on a beige desktop computer displaying Kimi Code. Near the top of the terminal, the model field reads “Model: Kimi K3.1.” A prompt below asks it to build a complex procedural 3D scene in Three.js. The interface then shows a file-writing action and JavaScript code.
Frame from Moonshot AI's official teaser, captured around 0.5 seconds. Source: Kimi on X. This is the company's promotional material, not an independent test.
Three.js is a JavaScript library used to build 3D graphics for the web. Procedural scenes use code to define their geometry and behavior. That framing is relevant to interactive websites, visual experiments, educational demonstrations, and prototypes that need more than static text or images.
Later sequences include a mechanical cutaway, a swirling ocean surface, and lunar imagery. These establish the video's visual direction, but the montage does not document the complete production process for each scene. It would be premature to claim that every sequence was generated in one attempt or without human editing.
Why the Coding Focus Matters
The most useful interpretation is that Moonshot wants viewers to associate this preview with making things through code. The terminal shows a concrete request and a file operation, placing attention on an executable artifact rather than a conversational answer.
Our reading is that creative coding will be an important area to examine when the model becomes available for testing. A successful tool in this category needs to translate a visual idea into working structure, keep the implementation coherent, and support revisions without breaking the result.
Consider a product demonstration with a rotating 3D object. Getting an attractive first render is only part of the job. The project also needs usable controls, correct resizing, consistent lighting, and code that remains understandable after several edits. The teaser makes that kind of workflow interesting to investigate; it does not establish how reliably K3.1 handles it.
Kimi K3.1 vs. K3: Start With the Existing Baseline
Any meaningful comparison needs to account for what K3 already does. Moonshot's official model list describes K3 as a model for software engineering, knowledge work, and deep reasoning, with native visual understanding and a one-million-token context window. Tokens are the units of text a model processes; the context window determines how much material it can consider at once.
Capability | What Is Already Documented for K3 | What Would Establish a K3.1 Upgrade? |
|---|---|---|
Long context | A one-million-token context window | A larger supported limit or better performance using lengthy material |
Visual understanding | Native vision support | Stronger results on matched visual tasks |
Adjustable reasoning | Low, high, and max settings | Better quality, latency, or token use under comparable settings |
Agent workflows | Support for Agent and Agent Swarm products | More reliable execution across extended tasks |
The reasoning settings come from Moonshot's K3 reasoning-effort documentation. Agent and Agent Swarm support is described in its official Agent overview. An agent uses tools to carry out a task; a swarm coordinates multiple agents.
These existing features should therefore be treated as the starting point for comparison. Seeing similar controls in a preview would not, by itself, establish a new capability.
Which Improvements Would Make the Biggest Difference?
For a future evaluation, three questions follow naturally from the coding focus. They are evaluation priorities, not confirmed specifications.
Does it complete more of the requested project correctly? A useful comparison would check functional requirements and interaction details, alongside the appearance of the final scene.
Does it recover from problems with less help? Real development includes broken dependencies, unexpected errors, and changing requirements. The relevant measure is how often a person must step in to keep the work moving.
Does it finish the same job more efficiently? Total task time and total token consumption matter alongside output speed. A faster response is less valuable if the project requires many additional repair attempts.
Those questions provide a practical way to assess an update without assuming that a higher version number guarantees an improvement in every workload.
Kimi K3.1 Benchmarks, Pricing, and Release Date
As of this check on October 23, the teaser provides no benchmark table, API price, or dated launch announcement. The official API model list reviewed for this article still lists K3 and other existing models, without a K3.1 entry.
The preview also does not establish which subscription plans will include the model, whether Kimi Code and the API will receive it together, or whether downloadable weights will accompany a release. Existing K3 pricing and access arrangements should not automatically be assigned to K3.1.
For now, the official video gives readers a specific reason to follow Kimi K3.1: Moonshot is showing the model in a creative programming workflow. The next meaningful evidence will be a release announcement, updated model documentation, and results that explain what changed under comparable conditions. Those details will determine how much of the teaser's promise carries into everyday work.
