Installing Kimi Code and K3 to write this blog (The Clean Version)
I wrote a companion post about installing Kimi Code and using Kimi K3 to write this blog. That one was the clean, it-all-worked version. This is the other half: what it was actually like to get Kimi K3 running on Windows 11 through WSL, and the five things that made me grind my teeth along the way.
None of these are dealbreakers. But if I had read them before I started, I would have saved myself a couple of hours and a chunk of context window I did not need to burn.
Why WSL at all
My daily driver is a Windows 11 laptop, but every coding-agent tool I like assumes a Unix shell. Rather than fight that, I run everything inside WSL2 with an Ubuntu distribution. The Kimi Code CLI and the Claude Code-style terminal flow both behave like they are on Linux, because from their point of view they are.
If you do not already have WSL set up, from an elevated PowerShell:
wsl --install -d Ubuntu
Then reboot, let Ubuntu finish first-run setup, and do the rest inside the WSL shell, not PowerShell. That distinction matters more than it sounds like, because a lot of the confusion later came from tools and keys that care which environment they were created in.
Inside WSL, the install itself is the easy part:
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash
kimi --version
And pointing a Claude Code-style flow at Kimi:
export ANTHROPIC_BASE_URL=https://api.kimi.com/coding/
export ANTHROPIC_API_KEY="your-kimi-code-api-key"
export ANTHROPIC_MODEL="k3[1m]"
That part took ten minutes. The rest of this post is everything that was not ten minutes.
Challenge (a): the API key only works with the path you got it for
This was the first wall I hit, and it is the one I most want to warn people about.
Kimi has three different paths, and they are not interchangeable:
- Kimi Code (Anthropic-compatible) —
https://api.kimi.com/coding/ - Kimi Code (OpenAI-compatible) —
https://api.kimi.com/coding/v1 - Kimi Open Platform —
https://api.moonshot.cn/v1
The trap is that a key minted for one path does not authenticate against another. I generated a key, wired it in, and got authentication errors that looked like the key was bad. It was not bad. It was a perfectly valid key — for a different door.
The mental model that finally worked for me: the key is scoped to the product, not to “Kimi” in general. If you are doing the Claude Code-style integration, you need a Kimi Code key used against the Kimi Code base URL, and you have to keep the Anthropic-compatible vs OpenAI-compatible endpoints straight on top of that. Match the key, the base URL, and the API shape as a single unit. If any one of the three is from a different path, you get an error that misleadingly looks like a credentials problem.
Do the check early with /status and confirm the Base URL really is the coding endpoint before you go debugging anything else.
Challenge (b): the TUI sprays text while it thinks, and there is no silence key
Once it authenticates, you meet the interface. The Kimi TUI is busy. While the model is thinking, it streams a running commentary — reasoning, tool deliberation, partial plans — straight into the terminal, continuously.
I understand the intent. Visible thinking is reassuring the first time. By the tenth prompt it is noise. And the part that genuinely annoyed me: there is no silence key. No toggle I could find to say “think quietly, show me the result.” You cannot easily mute the stream, so long tasks scroll pages of thinking that you then have to scroll back through to find the actual answer or the actual diff.
On a small screen, this is worse. My WSL terminal window is not huge, and the thinking output pushed the meaningful output — the file it changed, the command it wanted to run — off the top before I could read it. I ended up leaning on my terminal’s own scrollback and search rather than anything the TUI offered.
If you are used to a calmer agent UI, budget some patience for this one.
Challenge (c): 12% of a 1M context window just to explain how the blog works
Here is the one that actually cost me money.
This blog is a plain Jekyll site. Posts live in _posts, the filename encodes the date and slug, and the front matter is three lines. That is the entire mental model. But getting the agent to reliably operate on it — find where posts live, match the existing tone, use the right filename format, not invent config that is not there — took a lot of back-and-forth.
By the time it genuinely understood the repo, I had burned roughly 12% of a 1,000,000-token context window. That is ~120k tokens spent on orientation, before a single useful line of the post was written.
Some of that is on me. In hindsight the fix is to front-load the context instead of letting the model discover it conversationally:
- Keep a short
CLAUDE.md/ project note describing the repo layout and the post format. - Point the agent at one existing post as a template up front.
- State the filename convention explicitly rather than making it infer one.
But it is worth saying plainly: a large context window is not free, and “let the agent figure out the project” is a surprisingly expensive way to start. The 1M window lulls you into being lazy about scoping, and then you pay for it.
Challenge (d): it struggles to pick the right tool for the task
The other big time sink was watching it hunt for the right tool. Faced with a simple job — read a file, list a directory, make an edit — it would sometimes reach for the wrong approach first: shelling out where a direct file read would do, or exploring broadly when the target was already known.
Individually these detours are small. Cumulatively they add up, both in wall-clock time and in context consumed (see challenge c — a lot of that 12% was tool flailing). It made the whole effort feel slower and less deterministic than I wanted. The task was never in doubt; the route to it was.
What helped was being more prescriptive. Instead of “add a new blog post,” something closer to “create a file at _posts/YYYY-MM-DD-slug.md with this front matter, matching the style of this existing post” gave it far less room to wander. The less I left to tool discovery, the better it went.
Challenge (e): I am genuinely not sure it is cheaper
The pitch for going to Kimi K3 was partly cost. And here is my honest verdict after doing real work with it: I am not sure it actually saved me anything.
The per-token price may well be lower. But cost is not just the sticker rate, it is rate times tokens times number of turns. And on this task:
- The chatty TUI and the tool flailing meant more turns.
- The orientation problem meant a large upfront token spend (that 12%).
- More turns and more tokens partly eat whatever the lower per-token rate saves you.
So the theoretical savings and the effective savings are not the same number. On a well-scoped task where I hand it tight context, I suspect Kimi K3 could come out genuinely cheaper. On this task — loosely scoped, exploratory, lots of back-and-forth — the efficiency losses clawed back a good part of the discount. I did not come away convinced I had saved money. I came away thinking the savings are real only if you work in a way that keeps token count down, which is exactly the way the tool does not naturally nudge you toward.
Would I do it again?
Yes, but differently. The install on Windows 11 via WSL is not the hard part — that genuinely is a ten-minute job. The hard part is everything around the model:
- Get the key/path/endpoint triad right the first time (challenge a).
- Make peace with, or scroll past, the noisy TUI (challenge b).
- Front-load project context so you are not paying to explain the obvious (challenge c).
- Be prescriptive about the task so it does not shop for tools (challenge d).
- Do not assume “cheaper per token” means “cheaper overall” (challenge e).
Kimi K3 with a 1M context window is a capable backend, and running it under WSL on Windows 11 works fine. But the experience rewards discipline and punishes hand-waving. Go in with tight scope, or go in expecting to pay for the slack.