20 Things Kimi K3 Can Build From One Prompt That Most Users Don't Know

Four days ago, the largest open-weight AI model in history quietly went live.

Save this :)

No keynote. No livestream. Moonshot AI just flipped kimi.com overnight and shipped Kimi K3: 2.8 trillion parameters, a one-million-token context window, and a coding ability that just did something no open model has ever done.

In blind human testing on Arena, where developers vote on outputs without knowing which model made them, K3 took the number one spot in the Frontend Code arena. It beat Claude Fable 5. It beat GPT-5.6 Sol. First place, for building things, chosen by developers who did not know they were picking the open model.

Most people saw the headline and moved on. Almost nobody has actually pushed it to see what it builds.

I did. Here are 20 things K3 produces from a single prompt, most of which the people arguing about benchmarks have never even tried. Copy the prompts. Test them yourself. Bookmark this before it scrolls away.

A quick note before the list, because honesty is the whole point: K3 is genuinely number one in the world for frontend code in blind testing, but overall it sits around fourth place, roughly Opus 4.8 tier, and trails Fable 5 and GPT-5.6 Sol on the broadest benchmarks. Where it wins, it wins hard. This list is that territory.

First, 60 Seconds on What K3 Actually Is

If you are new to this, here is the whole thing in plain English before we get to the builds.

Kimi K3 is a large language model from Moonshot AI, a Beijing lab founded by former Google researcher Yang Zhilin and backed by Alibaba. It launched on July 16, 2026, in two flavors: a Max version for chat and agent work, and a Swarm version built for large-scale parallel jobs.

The 2.8-trillion-parameter number sounds impossible to run, and it would be, except K3 is a Mixture-of-Experts model. Picture a building with 896 specialists instead of one enormous brain. For any given task it wakes only the 16 best-suited specialists, about 1.8 percent of the total, and the rest stay asleep. So it carries the knowledge of a 2.8-trillion-parameter model while costing far less to actually run. Enormous on paper, lean in practice. That is the trick that makes everything below affordable.

Add three things to that: a one-million-token context window, so an entire codebase or a stack of long documents fits in its memory at once; native multimodal input, so it reads images and video directly rather than through an add-on; and always-on reasoning, which Moonshot calls "thinking mode," so it works through problems by default. That last one is a double-edged sword we will come back to.

That is the machine. Now here is what it does.

Part 1: Games and 3D Worlds (Where It Beats Everything)

This is the category that won K3 its number-one arena spot. The wall between "describe a 3D thing" and "have a working 3D thing" is now one prompt.

1. Playable browser games with real physics.

Not a game-like demo. Playable scenes with hit reactions, impact feedback, and physics that actually behave. People have pulled combat arenas with visual effects, browser-based 3D city traversal with grappling mechanics, top-down racers, and zombie shooters out of single prompts. The detail that separates K3 here is that it handles the twenty small things that normally break: collision response, momentum, camera feel.

1Build a single-file browser game: a top-down arena where the player dodges
2and shoots waves of enemies. WebGL or canvas, no external assets.
3Include: real movement momentum, enemy hit reactions, screen shake on
4impact, a score counter, and a restart button. 60fps target.
5Make it feel responsive, not floaty. Build the whole thing.

2. Interactive 3D products that look like renders, not demos.

A wristwatch with correct glossiness and light behavior. A camera you can take apart. A mechanical object modeled as dozens of individual parts that assemble and disassemble on click. The difference from every previous "AI builds a 3D thing" attempt is material accuracy: roughness, metalness, and real shadows instead of flat plastic.

3. Physics simulations that are computed, not animated.

Cloth that drapes. A structure that collapses under its own weight. Two vehicles colliding mid-air with momentum transfer that looks right instead of scripted. Ocean surfaces with genuine wave dynamics. Ask K3 to compute the physics and comment the math so you can verify it, and it will.

1Build three HTML5 canvas scenes with computed physics, no libraries,
2one file each: (1) a bridge collapsing and dropping a vehicle into water
3with displacement, (2) cloth falling over an invisible object, (3) a stack
4of blocks toppling from a nudge. Physics computed not animated, 60fps,
5reset button, and comment the equations. Don't ask questions first.

4. Shader and WebGPU visual scenes.

The genuinely hard graphics stuff. A black hole with gravitational lensing that bends the starfield behind it. Particle systems with thousands of points. Procedural terrain that generates as you move. This is the work that used to require someone who writes GLSL for a living, and K3 will draft it, then refine it against a quality bar you set. The trick is to name the standard out loud, "this should look like a demoscene entry, not a tutorial," because K3 responds to standards far more than to instructions.

1Build a single-file WebGL scene: a black hole with gravitational lensing
2that visibly bends a starfield behind it, plus an accretion disk with
3color based on temperature. Add orbit controls. Quality bar: this should
4look like a science visualization, not a shader tutorial. Build the file.

Part 2: Real Products and Interfaces

Beyond eye candy, K3's frontend strength turns into shippable product work.

5. Landing pages that look designed, not templated.

Give it a product and an aesthetic ("brutalist," "warm editorial," "clean fintech") and it produces a page with real typographic hierarchy and layout intent, not the generic AI-slop look. Set the standard explicitly and it meets it.

6. Full-stack app scaffolds from a spec.

Describe the product, the stack, and the features, and K3 scaffolds the frontend, the backend, the database schema, and the auth layer together, wired up rather than as disconnected snippets. It is not a toy; it is a starting codebase you harden from, which is exactly what its long-horizon design is for. Give it the whole spec in one prompt and let it build in stages.

1Build the scaffold for a habit-tracking web app. Stack: React front end,
2Node/Express API, Postgres, email-and-password auth. Features: user signup,
3create/edit/delete habits, daily check-ins, a streak counter, and a weekly
4summary view. Build the database schema first, then the API, then the UI.
5Wire them together and note anything I'd need to configure to run it.

7. Real-time collaborative features that actually stay in sync.

This is where weaker models quietly fake it. Real-time state has to sync across clients, not just save to a database, and the bugs only appear with two browsers open. K3 handles the WebSocket layer, reconnection, and multi-client sync, and you can force it to prove the work.

1Add a real-time collaborative layer to an app: live cursors plus click-to-drop
2comment pins, like Figma. Use WebSocket (Socket.io or native ws). Requirements:
3other users' cursors shown live, comments appear for everyone instantly, graceful reconnect with no ghost cursors, debounced cursor updates.
4Build it end to end, then prove sync works with two simulated clients before calling it done.

8. Dashboards and data visualizations from raw data.

Hand it a CSV and a question and it builds an interactive dashboard, charts, filters, and all, in one pass. Its chart-and-figure reasoning is one of its documented strengths, so it does not just plot the data, it reasons about what the data shows.

Part 3: Serious Engineering (The Long-Horizon Superpower)

K3 was built for sustained coding sessions across huge codebases. This is the part that matters if you write software for a living.

9. Whole-repo work with a measurable objective.

The single most powerful way to use K3. Do not give it a chore, give it an outcome and let it work until the number moves.

1Read this entire codebase before changing anything.
2Objective: cut p95 response time on the /search endpoint by 30%.
3Rules: profile first and show me where the time goes; don't change public
4interfaces or outputs; run the tests after every change; if a change makes
5things worse, revert it and say why. Work until the objective is hit or you
6can prove it can't be without breaking a rule.
7End with a log: what you changed, what it bought, what you tried that failed.

10. Putting an entire real repository in context at once.

The one-million-token window is not a spec-sheet flex here. You can load a genuine codebase and ask architecture-level questions, write documentation, or trace a bug across dozens of files, because the model can actually see the whole thing rather than guessing at the parts you did not paste. This is the single biggest practical difference between K3 and a model with a smaller window: it reasons about your system, not about fragments of it. One caveat worth knowing, though, a tight 200K of the files that matter usually beats a bloated 900K of the whole monorepo, because focus, not volume, is where its long-horizon strength comes from.

11. Migrating code between frameworks or languages.

K3 is state of the art on multilingual software engineering, so porting a service from one language to another, or one framework to its successor, is squarely in its wheelhouse, including the boring edge cases that usually get missed. Because it holds the whole project in context, it keeps behavior consistent across the migration instead of translating file by file and quietly changing what the code does.

12. Autonomous sessions with a verifiable success condition.

K3 can run long, largely unattended, but only well when the goal is checkable. "Improve the code" makes it wander. "Make this test pass" or "hit this benchmark" gives it a target it can grind toward without drifting. Always hand a long-horizon task a number, not a vibe.

Part 4: Agents, Tools, and Research

K3 is near the top of the tool-use and web-research benchmarks, which turns it into an operator, not just a writer.

13. Terminal and browser orchestration.

It drives the shell, the browser, and API calls without falling apart, which is the connective tissue every real agent task needs. Point it at a goal that requires looking things up and acting on them, and it chains the steps itself instead of stopping to ask you what to do at every fork.

1Goal: find the three most-requested features in this open-source project's
2GitHub issues, then draft a short spec for the top one.
3Steps: search the repo's issues, rank by reaction count and comment volume,
4identify the top three, pick the highest-impact one, and write a one-page
5spec with scope, edge cases, and a rough implementation plan. Show your work.

14. Deep, tool-augmented web research.

K3 is state of the art on browsing benchmarks. Give it a research question and it searches, reads primary sources, cross-references, and comes back with something structured and cited, in the time it used to take to skim ten tabs.

15. Massive parallel work through the Swarm variant.

K3 shipped in two forms, and the Swarm variant is built for large-scale parallel processing: fan a big batch job out across many sub-agents at once, then merge the results, instead of grinding through it one item at a time.

16. Turning a document pile into a single deliverable.

Point it at a folder of PDFs or a long research corpus and ask for one synthesized output, a literature review, a comparison table, a brief, and it processes the set and hands back the assembled result rather than fifteen separate summaries.

Part 5: Multimodal and Power Moves

K3 reads text, images, and video natively, and that unlocks a different class of work.

17. Screenshot or mockup straight to working code.

Show it a design mockup or a screenshot of an interface and it writes the frontend that reproduces it. Native vision plus its frontend crown make this one of the most immediately useful things on this list for anyone building UI.

18. Reasoning over charts, figures, and visual math.

Feed it a chart, a diagram, or a photographed math problem and it does not just describe the image, it reasons about it, extracts the numbers, and works with them, backed by Python when the task needs real computation. Documented as one of its state-of-the-art areas.

19. Video understanding as an input.

Because multimodal input includes video, you can hand it footage as context rather than transcribing first, and have it reason about what actually happened on screen.

20. Owning the model outright after July 27.

The biggest power move is the one most people misunderstand. On July 27, K3's full weights go open under a permissive license. For a serious team that means self-hosting on your own hardware, fine-tuning on your own data, inspecting exactly how it behaves, and depending on no one's API staying online or terms staying favorable. That independence, on a frontier-adjacent model, is the part that actually reshapes the market.

Two Honest Warnings Before You Dive In

Because a list of superpowers without the fine print is how people waste money and get burned.

Do not make K3 your default for everything. Its reasoning is always on. It thinks hard about every request, which is glorious for the twenty things above and absurd for formatting a list or renaming variables. Early testers watched it burn thousands of reasoning tokens on tasks that should cost a fraction of a cent. Route trivial work to a smaller, faster model and save K3 for jobs that justify the horsepower. This is the single most expensive mistake new users make.

One nuance on cost that cuts the other way, though: K3's API price of $3 per million input tokens and $15 per million output is mid-tier, not cheap, but it tends to use fewer output tokens to finish a real job than pricier models that ramble to the same answer. So the honest way to judge it is cost-per-finished-task, not cost-per-token. On the work it is built for, the total bill often comes in lower than the sticker price suggests. On trivial work, the always-on thinking erases that advantage entirely, which is exactly why routing matters.

"Open weights" does not mean "runs on your laptop." When the weights drop on July 27, you are not downloading K3 onto your MacBook. Even heavily compressed it is well over a terabyte and needs dozens of accelerator chips to run. Open weights is a gift to organizations that can self-host and to researchers who can fine-tune, not a private model for your gaming PC. For almost everyone, "using K3" means the app or the API, and that is completely fine.

How to Try It Today

→ Chat: kimi.com, live right now, the zero-setup way to run every prompt above.

→ API: OpenAI-SDK compatible, so switching from an OpenAI or Anthropic setup is a base URL and a model string, not a rewrite.

→ In your codebase: install the Kimi Code CLI from the official instructions on kimi.com, open your project, and let it plan, edit, and test with direct file access.

→ Weights: full open release scheduled for July 27, the date this stops being a service you rent and becomes something anyone with the hardware can own.

Why This Is Bigger Than a Benchmark

Step back from the prompts for a second, because the context is the real story.

Moonshot built a 2.8-trillion-parameter frontier-class model under three years of escalating US export controls on the exact chips you would normally need to train something this size. They did it through architectural cleverness rather than raw compute, and then, instead of locking it behind an API forever, they announced they would give the weights away. The release was timed to land just before the World Artificial Intelligence Conference in Shanghai, which is not a coincidence.

The interesting question was never "did China catch up." It is what happens to the economics of closed, expensive frontier models when a free, open one lands in the same tier. When frontier-grade capability stops being something only three companies can sell, and becomes something any well-resourced team can download, the pricing power of the closed labs changes. That pressure is the actual event here, more than any single benchmark number.

There is a real open question hanging over it, too. Chinese regulators have been discussing their own AI export rules, so whether K3 is the last great open-weight release from that side or the first of many is genuinely unclear. Either way, the model is out, and it is not going back in.

The Real Takeaway

For three years the deal was simple: the American labs built the frontier, and everyone else got a cheaper copy half a year later. Kimi K3 broke that. It is the largest open model ever made, it is the number-one model in the world for frontend code in blind human testing, and in one week it goes free.

It is not the cheapest tokens, it does not top every chart, and you will not run it at home. All true, and none of it changes the headline: a frontier-tier model that beats the closed flagships at building things is about to belong to everyone.

The twenty prompts above are your head start. The people who actually run them this week will know what this model can do while everyone else is still arguing about a benchmark table.

Most people will read the launch tweet and never open the model. The ones who spend one evening building with it will be a month ahead of the entire timeline.

I break down every major AI release without the hype, and hand you the prompts to try it yourself. Follow me for the next one, and bookmark this while K3 is still news.

How to try it:

→ Chat and app: kimi.com

→ API: OpenAI-SDK compatible

→ Open weights: expected July 27

If you found this useful, follow me @eng_khairallah1 for more AI content like this. I post breakdowns, courses, and tools every week.

hope this was useful for you, Khairallah ❤️