Kimi K3 Just Dropped. Here's How To Actually Use It.

At a glance

Leon van Zyl does the thing almost nobody does with a new frontier model: he installs it properly, configures it properly, and then makes it build something genuinely hard, on camera, including the parts where it struggles. The model is Kimi K3 from Moonshot AI, which Artificial Analysis has sitting third on its overall intelligence index, hot on the heels of GPT 5.6 and Fable 5, and above Opus 4.8 on max. The reason everyone is talking about it is the price: cheaper than GPT 5.6 and roughly a third the cost of Fable 5.

The video is a complete setup walkthrough followed by a real build. He installs Kimi Code, the native CLI, signs in with a subscription rather than an API key and explains why, switches the model off the K2.7 default, sets reasoning effort to max, and turns off approval prompts. Then he runs the whole thing through his RAMP framework: Rules in an AGENTS.md, Augment with MCP servers, Map the build in planning mode, Prove the work with automated tests. The warm up is Tetris in Python, which K3 nails. The real test is rebuilding WebDev Cody's 3D version of Excalidraw, which it does not nail. That build runs past two hours, exhausts his usage limit twice through the swarm feature, and only gets close after he starts feeding screenshots of the reference app back into the agent. It does end with a working app deployed to a live public domain, driven entirely by the agent through an MCP server. The honest verdict he lands on: much cheaper than Fable, not as fast, and turn swarm off.

Where K3 actually lands, by his numbers

He opens on the showcase page, and it is a good one. A black hole simulator. A physics site with animations he calls beautiful. A satellite tracking app plotting the real world positions of actual satellites. All built by the model, all sitting on kimi.com as proof of what it can do in one shot.

Then he goes to the scoreboard. On Artificial Analysis, Kimi K3 is "hot on the heels of GPT 5.6 and Fable 5 in terms of intelligence," and on the overall intelligence index it currently sits third, which puts it above Opus 4.8 running on max. His reaction is the honest one: "which is just crazy to say out loud."

But the ranking is not why the model is having a moment. The cost chart is. Over a year, K3 comes in cheaper than GPT 5.6 and at about a third of the cost of Fable 5. That is the whole pitch, and it is the thesis the rest of the video is built to test: if you want a cheaper alternative to a frontier model, is this actually usable for real work, or does it fall apart the moment the task gets hard?

The four ways in, and why the website is not one of them

Before anything gets installed he lays out the access paths, because picking the wrong one is the most common way to have a bad time with this model.

• The website. Great for demos, genuinely not ideal for agentic coding tasks. This is the one most people try first and the one he explicitly steers you away from.
• The desktop app. Fine for building apps.
• The CLI tool, Kimi Code. What he uses for the entire video.
• Everything else. You can run K3 inside Cursor, inside opencode, and in plenty of other clients. There are also official VS Code and Cursor extensions on the Kimi Code page.

He picks the native CLI deliberately: "I really want to stick to their native solution to give it the best possible shot." That is the right instinct for a review. If you wrap a new model in a third party harness and it underperforms, you have not learned whether the model or the harness was the problem.

Plans, API keys, and the subsidy argument

While the installer downloads he goes over billing, because you need either a Kimi account or a Kimi API key before the CLI is useful.

Go to kimi.com, scroll down to upgrade, and pick a plan. He toggles to monthly to make the comparison legible, and says he personally subscribed on the annual plan, which works out to about $20 per month.

The alternative is an API key, which is pay as you go against your usage. His advice is unambiguous and generalizes past this one model:

"Honestly, when it comes to any of these plans or any of these providers, you're almost always better off just using their subscriptions, as these subscriptions are highly subsidized. It's way cheaper than paying per token."

That is worth sitting with, because it is a claim about the economics of the whole category. Providers price subscriptions below what the same usage would cost through the API, on purpose. The catch shows up later in this exact video, at minute 22, when the subsidy turns into a hard usage ceiling and he has to stop working for a few hours.

Installing Kimi Code

The install itself is one line. Go to code.kimi.com, choose your operating system, and copy the command it gives you. He is on Windows and runs it in PowerShell; the page has the equivalent line for macOS and Linux.

# from code.kimi.com, pick your OS, copy the command it prints
# he does not read the line out on camera, so grab it from the page rather than from here

The same page offers the VS Code and Cursor extensions if you would rather not live in a terminal.

Then the step people skip and then file a bug about: restart your terminal. He closes PowerShell and starts it again. Only then does the kimi command resolve.

kimi          # launches Kimi Code

First run: sign in, then fix the model

Launching it is not enough. You are not signed in yet, so nothing works. The sign in command:

/login

That offers two options, matching the billing choice above: sign in with your Kimi subscription, or use an API key. He picks the subscription, which opens the Kimi website in a browser and authenticates the account. Back in the terminal he types hey, gets a response, and confirms the connection is live.

Now the detail that would silently ruin your entire evaluation of this model: it does not default to K3. His session opens on Kimi K2.7. If you install the CLI, say hello, run a build, and conclude K3 is underwhelming, you may never have used K3 at all.

/model

That lists the available models. He selects Kimi K3, and then, still inside the /model picker, uses the left and right arrow keys to set the reasoning effort. He picks max. To change effort later without touching the model:

/effort

He stays on max for the whole video, which turns out to matter: at minute 22, when his usage evaporates, the first thing he suggests trying is dropping effort to medium or high.

Here is every command the video uses, in one place.

Why he runs a terminal tool inside a code editor

"I personally don't like just staring at a terminal screen." So he opens VS Code on a blank project folder, opens Terminal, New Window from the menu, and runs kimi there instead.

The reasoning is practical and it is the single best beginner tip in the video. Running an agentic CLI inside an editor buys you two things a bare terminal cannot:

1. You see the files as they are created. Every file the agent writes appears in the sidebar the moment it lands. You are not reading a wall of tool output trying to infer what exists on disk.
2. You get version control for free. He clicks initialize repository before writing a single prompt, so git tracks changes from the first keystroke and every version the agent produces is visible and revertible from the editor.

Initializing the repo first is the part worth copying. An agent in yolo mode with no version control is a machine for losing work.

Test one: Tetris in Python

The warm up prompt, verbatim:

Please create the game of Tetris running in Python.

It takes a few minutes, because the agent spends a lot of time reasoning on max effort. Then it asks permission to apply its changes. He approves for the session, then removes the friction permanently:

/permission

He selects yolo. "I'm feeling super brave today."

The files appear in the sidebar, and here is his first real criticism of the model: it put everything in a single file. "I personally don't like the fact that it added all of this code to a single file. I think it would have been cleaner if it could create a more modular system, but maybe this is fine for most people."

Then a test most reviewers do not think to run. The agent tells him the command to launch the game. Rather than run it himself, he asks:

please can you start the game

It runs the command itself and the game window opens. This is a small thing that tells you a lot: the agent can execute, not just author. He plays it on camera, speeds pieces up, rotates them, deliberately stacks badly enough that viewers will yell at him, completes a line, and the blocks disappear. "So the game logic is actually working. I'm actually really impressed by this."

Tetris in Python is not a hard benchmark, but a working game loop, collision detection, rotation, and line clearing in one shot with no follow up prompts is a clean pass.

Then he wipes the slate: escape to stop the session, delete the project files, and

/new

which starts a fresh session and frees the context window. Context hygiene between tasks is a running theme, and it comes back with force in the planning section.

The RAMP framework

Now the real test, and he runs it through a named process rather than vibes. He calls it RAMP, and he teaches it in a free course linked from his description. The four steps as he states them:

• Rules. Set up the environment and the rules the agent must follow.
• Augment. Add MCP servers and skills.
• Map. Produce a detailed implementation plan.
• Prove. Implement, and make the agent verify its own work.

The elegant part, which becomes obvious only at minute 21, is that these steps are not independent. The Prove step happens automatically at the end because of a rule written back in step one. Nothing in the final prompt asks for testing.

R for Rules: AGENTS.md and the pirate test

Step one produces an AGENTS.md. Kimi prepopulates it with a set of default rules, and his verdict is blunt: "you know what, this is not actually useful." He throws the defaults out. All you actually need is the file.

Then he proves the file works, in the most efficient possible way. He adds one line:

always respond like a pirate

Starts a new conversation, says "Hey", and the agent answers like a pirate. Ten seconds, and you now know, with certainty, that this file steers the model. "Trust me, anything you add to this file will be followed by the agent."

This is a genuinely good technique and it generalizes to any agent config file you are unsure about. Do not read the docs and hope. Write an absurd, instantly visible rule, restart the session, and see if it fires. If the pirate shows up, your real rules are being read too.

Then he replaces the joke with the real rule set. He does not read it out line by line, inviting viewers to pause and read the screen instead, but he describes each block. Rebuilt from what he says on camera, his AGENTS.md covers four areas:

# Responses
Keep responses concise and to the point. Do not burn through tokens
unnecessarily. I prefer short responses.

# Planning mode
Always ask clarifying questions. Never assume design, text, or features.

# Testing
Use any tools you have available to test your work. Never assume that
things simply work. Always test.

# UI design
Always follow the design system defined in design.md.

Every one of those four does visible work later in the video. The planning rule is why Kimi interrogates him before writing the plan at minute 16. The testing rule is why sub agents write unit tests and drive a browser at minute 21, unprompted.

He also creates a design.md for the design system: typography, colors, borders, whatever rules a web app needs, referenced from the UI rule above so the agent enforces it on every new page and component. For this particular project he does not fill one in, but he flags it because it is the mechanism people ask him about most.

A for Augment: his honest take on skills

Step two adds capability, and it splits in two: skills (detailed prompts the agent can follow) and MCP servers (actual tools it can call). His take on the first half is the most contrarian thing in the video, and it is aimed squarely at a specific fashion:

"People, for some reason, love these skills like the grill me skill, and I personally don't get it. I mean, if you have a look at the grill me skill, it's nothing more than just a few lines of text, and all you really have to do with modern agents is simply to ask the agent to ask you clarifying questions. The same thing we just did with the rules file."

He is not against skills as a mechanism. He is against installing a package to do something a sentence in your rules file already does. His earlier aside makes the positive case: "You really do not have to install every grill me skill or whatever is out there. You need to start to feel comfortable to add your own prompts and to just set your own rules and build your own skills."

So when is a skill worth installing? His answer is a genuinely useful filter: when it carries reference documentation you do not have.

Think about the tech stack you are using and look for a skill specific to it. Building on Next.js? Search for the Next.js best practices document, specifically skills published by the official provider, in that case Vercel. Using Clerk for authentication? Go to Clerk, the official provider, and install theirs.

The distinction is the payload. "This is not some useless throwaway prompt. This contains a lot of very detailed guidelines and documentation from the official providers." A skill that is three lines of behavioral nudging is a rule you should have written yourself. A skill that is a vendor's full implementation guide is knowledge the model does not otherwise have in reliable form.

A for Augment: the two MCP servers

For this project he needs no skills, but two MCP servers.

The Playwright MCP server, so the agent can open a real browser and visually test the app end to end. Installing it requires no config editing at all. He copies the server URL and hands it to the agent in plain English:

please install this MCP server in this project so that you can use it

<paste the Playwright MCP server URL here>

Kimi creates a .kimi folder containing an mcp.json with the full configuration written for you. This is the pattern worth internalizing: modern agents install their own tools. You do not hand edit connector config any more, you paste a URL and ask.

The Hostinger MCP server, so the agent can take the finished project and deploy it to a live domain on his behalf. The setup on the provider side:

1. Sign in to Hostinger.
2. Go to API.
3. Choose configure manually.
4. Enable the scopes. He enables websites and domains, and notes what that grants: "this also means the agent can register domains as well, by the way." He enables all of them.
5. Copy the config block.

Then, back in the agent:

please add this config as well

<paste the Hostinger MCP config block here>

He is upfront that Hostinger sponsored the video and that his links are affiliate links, with code LEONHOSTING for 10% off. His actual technical claim is narrower and fair: hosting companies are going to start shipping MCP servers like this, and this one happens to already exist. Any host with an MCP server, or any static host you can reach with a CLI, slots into the same position in the workflow.

With both servers configured he starts a brand new session to clear the context window, which also connects the MCP tools. The connections come back successful. Rules set, agent augmented.

M for Map: planning mode, and the interrogation

Step three is where you discuss the project with the agent until you have an implementation plan it can follow like a map.

shift + tab      → planning mode

In planning mode the agent makes no changes to the codebase at all. It is conversation only.

The target is deliberately unfair: WebDev Cody's 3D version of Excalidraw, a canvas app where you move shapes around in actual 3D space. He is generous about it, calls Cody a friend of the channel and a really good software engineer and architect, and tells viewers to go watch him. He is also honest about the difficulty: "this is not an easy project at all. Honestly, I don't even know if Kimi can do this. But if it's pretending to be at the level of Fable, then it should be able to build something like this."

He pastes in a long, detailed prompt describing the app, and stores it in the project code so it travels with the repo. He does not read it out, telling viewers to pause and copy it, and publishes the repo publicly afterwards.

Then the AGENTS.md rule fires. Because he told it to always ask clarifying questions in planning mode, Kimi comes back with a list instead of a plan:

• "Where should the app be scaffolded?" He answers: in the current root.
• "How should the automatic graph layout be implemented?" He answers: custom, so zero dependencies.
• The question comes round again on implementation detail, and this time he takes the model's recommended option, on purpose: "I really want to test the coding capabilities and reasoning capabilities of this agent. So for this demo, I'm not really going to steer it much."

That is a deliberate methodology choice. Every time you steer an agent, you contaminate the experiment. He wants to see what K3 does when left alone.

Where the plan lives, and why the context window decides it

The agent writes the plan, and he immediately dislikes where it put it. So he creates a plans subfolder inside the .kimi folder and moves it there. His first attempt is to ask the agent to do it, which takes long enough that he hits escape and drags the file in by hand instead. "That was way, way quicker." A small, honest moment: not everything is worth an agent call.

His reasons for colocating the plan with the code are all about continuity:

• It lands in the GitHub repo when he pushes, so viewers and team members can read it.
• It is easy to refer back to later.
• If he cannot finish in one session, he closes the machine, comes back hours later, pulls the same plan back in, and asks the agent to continue. The plan is the save file.

But the real reason is the context window, and this is where he states the most important hard number in the video:

"At the moment we're using like 20% of the context window, and the context window on Kimi is not that large. It's only 256,000 tokens. And if you're used to GPT and the Claude models, they go up to a million."

Then the part that matters more than the number:

"But either way, I wouldn't really want to use that many tokens either, as you start to move into the dumb zone. That is when the agent's responses start to degrade."

Planning eats context. Twenty percent of the window is gone before a single line of the app has been written. Because the plan is a file on disk, he can wipe the entire conversation, start clean at zero percent, pull the plan back in, and implement with the full window available. The plan file is not documentation. It is a context compression device: hours of discussion collapsed into a document you can re read for a few thousand tokens.

P for Prove: swarm, and the browser UI

Time to build. Kimi Code ships a feature called swarm, which kicks off sub agents to work on tasks in parallel, delegating different coding and research jobs across them. This task is complex, so he enables agent swarm, pulls the project and the plan into context, and sends:

please implement this project

While it runs, the alternate interface. If you do not like living in a terminal:

/web

Confirm with continue, and a web page opens in the browser showing all of your Kimi sessions in a clean view. He compares the feel to Claude Desktop or Codex. He also names /session as the way to get to that view. It is the same running session, just rendered in a browser instead of a terminal.

Back in the terminal the swarm has kicked off. Kimi first set up the project dependencies and files itself, then spawned multiple sub agents running in parallel, each showing what it is working on, with an indicator of current context window size beside them.

And then the framework closes its loop. The swarm is not only writing features. It spawns agents responsible for writing unit tests and for testing the app with available tools, including the Playwright MCP server. He points at the screen: "I did not open the browser at all. This is actually Kimi using Playwright to open the browser and performing some kind of smoke test."

Nothing in please implement this project asked for any of that. It happened because of a rule written into AGENTS.md fifteen minutes earlier. That is the argument for RAMP, demonstrated rather than asserted.

Where it goes wrong

This is the section that makes the video worth watching, because he leaves it in.

The usage limit. The agent kicked off a second wave of swarm agents, and his usage kept running out. He had to stop and wait several hours for it to reset. After wave two he told the agent to stop using swarm entirely and finish single threaded. His conclusion:

"It seems like swarms use a lot of tokens. It might help if we switch the effort level down to something like medium or high. Maybe just don't run it in max. But I ran out of my usage stupidly fast. So unless your project is really complex, I think just avoid swarms."

Note the two variables he identifies and does not get to separate: swarm width, and max reasoning effort. Both multiply token spend. He was running both at once.

The wall clock. Nearly two hours in, Kimi is still going.

The output. He looks at what exists so far: "this is what it looks like at the moment, which is definitely not great." There is some kind of 3D element. Zoom out and there is a canvas. "It's definitely not great. It's far from complete."

The fix that actually worked. Not more prompting in text. He took screenshots of the reference app and fed them back to the agent, and that is what got the canvas, the UI, and the 3D design close to the target. Visual feedback beat verbal instruction, and it is the single most transferable tactic in the last five minutes of the video.

He also notices the model got faster once swarm was off and everything ran in a single session.

Deploying: one sentence, one live domain

He stops there rather than keep iterating, because the deploy is the part viewers have not seen. First, a commit, called init, pushed to a fresh public repository on GitHub.

Then, because the Hostinger MCP is already wired in, the entire deployment is one sentence:

please go ahead and deploy this to Hostinger

First use triggers a one time Hostinger account authentication. Then the agent reports multiple hosting plans on the account and asks which to use; he takes the first. It deploys, verifies the site is live, and hands back a public facing domain anyone can open.

He loads it and works through the app on camera. Spacebar to move around. Alt to move around. Sliders to control the 3D view. Delete a node. Add a new node. Give it text. All of it works. "How easy is that?"

And a last capability worth flagging: if you want a custom domain instead of the generated one, you can do that through the agent too, because the domains scope was enabled back at MCP setup.

An honest ledger: what the cheap model actually cost him

Everything above is the video rebuilt. This section is the accounting, and it is worth doing carefully because the headline number and the lived experience point in different directions.

The pitch is a third the cost of Fable 5. The build was one app, and it consumed his monthly subscription's usage allowance to the point of a hard stop, twice, forcing a wait of several hours mid project. Both things are true at once, and the reconciliation is in his own words: subscriptions are heavily subsidized, which is exactly why they come with ceilings you can hit. The cheap price and the usage wall are the same fact viewed from two sides.

Three things are worth saying plainly on top of that table.

The experiment had a confound and he flags it himself. Max reasoning effort plus swarm plus a genuinely hard 3D graphics task is three difficulty multipliers at once. His own suggested next step, drop effort to medium or high and skip swarm, is the experiment this video did not run. Read the slowness as "K3 on max effort with parallel sub agents on a hard task is slow", not as a settled verdict on the model.

The single file Tetris is a real signal, not a nitpick. An agent that dumps a whole program into one file is telling you something about how it decomposes work, and that is the same faculty that has to structure a 3D canvas app. His instinct to complain about it early was right.

The most reusable ideas here are not about Kimi at all. The pirate test for verifying a rules file. Initializing git before the first prompt. Writing the testing rule once so verification happens forever. Storing the plan in the repo so you can clear context and keep going. Feeding screenshots instead of adjectives when the UI is wrong. Every one of those works identically in any agentic CLI you happen to be using.

Key takeaways

• The model does not default to K3. A fresh Kimi Code session opens on K2.7. Run /model, pick K3, and set reasoning effort with the arrow keys before you judge anything.
• The website is a showcase, not a tool. For agentic coding use the CLI or the desktop app. He picks the native CLI deliberately so the harness cannot be blamed for the model's results.
• Subscriptions beat API keys, and that is a category fact. About $20 a month on the annual plan, and providers subsidize subscriptions well below per token pricing. The flip side is a usage ceiling you can hit in a single hard afternoon.
• Run the CLI inside your editor and initialize git first. You see every file the agent writes, and every version is revertible. Yolo mode without version control is how you lose work.
• Prove your rules file works with something absurd. "Always respond like a pirate", new session, say hello. If the pirate shows up, your real rules are being read.
• Write the testing rule once and it fires forever. Nothing in his build prompt asked for tests. Sub agents wrote unit tests and drove a real browser because of four lines in AGENTS.md set fifteen minutes earlier.
• Install skills for documentation, not for behavior. A skill that is a few lines of nudging is a rule you should have written yourself. A skill that carries a vendor's full implementation guide is knowledge the model does not otherwise have.
• You install MCP servers by pasting a URL and asking. Kimi writes .kimi/mcp.json itself. No hand edited connector config.
• The plan file is a context compression device. The window is 256,000 tokens and planning burned 20% of it. Save the plan into the repo, wipe the conversation, pull the plan back in, and implement from zero. Beyond that, the "dumb zone", where responses degrade as context fills.
• Skip swarm unless the project genuinely demands it. Two waves exhausted his usage and forced a multi hour wait, and single threaded turned out faster. Try dropping effort to medium or high before reaching for parallelism.
• When the UI is wrong, send pictures. Screenshots of the reference app moved the build further than any amount of written correction.
• Deployment is now a sentence. With a host's MCP server connected, "please go ahead and deploy this to Hostinger" produced a live public domain, and the same scopes let the agent register domains.

Chapters

0:00 Kimi K3 lands at the level of Fable 5 and GPT 5.6 0:13 The ways to reach K3, and why the website is not one of them 0:27 The showcase: black hole simulator, physics site, satellite tracker 0:52 Artificial Analysis: third on the index, above Opus 4.8 on max 1:06 The real reason it is popular, a third the cost of Fable 5 1:31 Installing Kimi Code, and the other clients K3 runs in 2:09 Plans and API keys, and why subscriptions win 2:48 Restart the terminal, then run kimi 3:14 /login, subscription or API key 3:38 It opens on K2.7. /model, /effort, and setting max 4:15 Why he runs a terminal tool inside VS Code 4:42 Initialize a git repository before the first prompt 5:06 Test one: Tetris in Python 5:19 /permission and yolo mode 5:45 Reading the code: everything in a single file 5:58 Making the agent launch its own game 6:24 Playing it, and the line clears 6:49 Escape, delete, /new to free the context window 7:16 The RAMP framework, step by step 7:43 R for Rules: AGENTS.md and the pirate test 8:35 The four rules he actually writes 9:26 design.md and the design system rule 10:30 A for Augment: his honest take on skills 11:19 When a skill is worth it: official provider documentation 12:10 Installing the Playwright MCP server 12:51 Installing the Hostinger MCP server for deployment 13:56 The Hostinger sponsorship and the 10% code 14:35 M for Map: planning mode with shift and tab 15:13 The target: WebDev Cody's 3D Excalidraw 15:52 The planning prompt, and Kimi's clarifying questions 17:08 Moving the plan into the project, and why 18:38 256,000 tokens, and the dumb zone 19:16 Swarm: parallel sub agents, enabled 19:57 /web and /session, the browser interface 20:48 Watching the swarm run 21:26 Kimi drives Playwright to smoke test its own work 22:15 Swarm burns the usage limit, twice 22:54 Two hours in, and far from complete 23:43 Feeding screenshots back until the canvas is right 24:20 Cheaper than Fable, not faster 24:32 Commit, and a public repository 24:57 "Please go ahead and deploy this to Hostinger" 25:22 The live domain, and the working app 26:01 Custom domains through the agent, and the sign off

Notable quotes

"Kimi K3 was just released and, according to the benchmarks, it's at the level of Fable and GPT 5.6." (0:00)

"The first one is through their website, but that's really not ideal for agentic coding tasks. If you want to build apps, you really want to use either their desktop app or their CLI tool." (0:13)

"If we have a look at the overall intelligence index, it's currently in third position, beating out Opus 4.8 on max, which is just crazy to say out loud." (1:06)

"I really want to stick to their native solution to give it the best possible shot." (1:43)

"Honestly, when it comes to any of these plans or any of these providers, you're almost always better off just using their subscriptions, as these subscriptions are highly subsidized. It's way cheaper than paying per token." (2:48)

"At the moment I'm using Kimi K2.7, which is not what I want. So we can change the model by running the command /model." (3:38)

"The reason I like running this in sort of a coding editor is I can see any file changes or any files that are created by the coding agent." (4:42)

"And I'll just select yolo. I'm feeling super brave today." (5:33)

"I personally don't like the fact that it added all of this code to a single file. I think it would have been cleaner if it could create a more modular system." (5:45)

"And the blocks did disappear. So the game logic is actually working. I'm actually really impressed by this." (6:37)

"Trust me, anything you add to this file will be followed by the agent." (8:10)

"You really do not have to install every grill me skill or whatever is out there. You need to start to feel comfortable to add your own prompts and to just set your own rules and build your own skills." (9:01)

"People, for some reason, love these skills like the grill me skill, and I personally don't get it. I mean, if you have a look at the grill me skill, it's nothing more than just a few lines of text." (10:55)

"This is not some useless throwaway prompt. This contains a lot of very detailed guidelines and documentation from the official providers." (11:44)

"This is not an easy project at all. Honestly, I don't even know if Kimi can do this. But if it's pretending to be at the level of Fable, then it should be able to build something like this." (15:39)

"I really want to test the coding capabilities and reasoning capabilities of this agent. So for this demo, I'm not really going to steer it much." (16:55)

"The context window on Kimi is not that large. It's only 256,000 tokens. And if you're used to GPT and the Claude models, they go up to a million." (18:38)

"I wouldn't really want to use that many tokens either, as you start to move into the dumb zone. That is when the agent's responses start to degrade." (18:50)

"So the agent is not just going to build the project, it's going to prove its work as well, which is the final step of the RAMP framework." (21:38)

"I did not open the browser at all. This is actually Kimi using Playwright to open the browser and performing some kind of smoke test." (21:50)

"It seems like swarms use a lot of tokens. It might help if we switch the effort level down to something like medium or high. But I ran out of my usage stupidly fast. So unless your project is really complex, I think just avoid swarms." (22:28)

"It's been nearly two hours, by the way, and Kimi is still going." (22:54)

"This is what it looks like at the moment, which is definitely not great. It does have some kind of 3D element to it ... but it's definitely not great. It's far from complete." (23:06)

"This took a really long time, and I basically had to end up taking a lot of screenshots from the reference app and just give that back to the agent to get it to fix up the canvas and that UI or the 3D design." (23:43)

"One thing I can say about this model is, yes, it's much cheaper than something like Fable. But I don't think it's as fast as Fable necessarily." (24:20)

"So we get this public facing domain, and anyone with this URL can actually access our website." (25:34)

Resources mentioned

• Kimi, the model and the web chat, including the showcase apps he opens on: the black hole simulator, the physics and animation site, and the live satellite tracker. Subscriptions are under upgrade, at about $20 per month on the annual plan.
• Kimi Code, the native CLI used for the whole video. The same page carries the per operating system install command and the official VS Code and Cursor extensions.
• Moonshot AI, the lab behind Kimi and the K3 model.
• Artificial Analysis, the source of the intelligence index ranking and the one year cost chart he shows.
• Fable 5 and Opus 4.8 from Anthropic, and GPT 5.6 from OpenAI, the three models K3 is measured against.
• opencode and Cursor, named as alternative clients you can run K3 inside.
• VS Code, the editor he runs the CLI inside so he can watch files appear and use git version control from the sidebar.
• PowerShell, the terminal he installs from, and the one you must restart after installing.
• Python, the language for the Tetris warm up build.
• AGENTS.md, the rules file convention every step of the RAMP framework hangs off, plus a companion design.md for the design system.
• Model Context Protocol, the standard behind the .kimi/mcp.json file Kimi writes for itself.
• Playwright MCP server, installed by pasting its URL, which lets the agent open a real browser and smoke test the app end to end.
• Hostinger, the host whose MCP server handles the deploy. Enable websites and domains under API, then configure manually, and copy the config. Sponsor of the video, with an affiliate discount code LEONHOSTING for 10% off.
• Next.js and Vercel, his example of a tech stack whose official provider skill is worth installing, alongside Clerk for authentication.
• Agent Skills, the mechanism behind the "grill me" style skills he argues most people do not need.
• Excalidraw, and WebDev Cody, whose 3D version of it is the build target. Leon calls him a friend of the channel and a genuinely good software engineer and architect.
• GitHub, where he commits the build and publishes the repository publicly.
• Claude Desktop and Codex, the interfaces he compares the /web browser view to.
• Leon van Zyl's free community, where the source code, the prompts, the RAMP course, and the repository link live.
• Agentic Labs, his paid program with the agentic coding masterclass and the design systems course he mentions.
• Leon van Zyl on YouTube, the channel.