A free one-hour course on Moonshot's new flagship. Six modules, ten minutes each — and by the end you're not reading about K3, you're operating it. Every module uses something real I built on launch day.

A new model drops and you know the routine.
You open nine tabs. The launch thread. Three hot takes. Two benchmark arguments.
You read for an hour.
And at the end of that hour, you can talk about the model at dinner — but you can't do anything new.
No profile in your stack. No test you ran. No build with your name on it.
Next week another model drops and the tabs open again.
Reading about models is a hobby. Operating them is a skill.
The 60-Minute Operator breaks that cycle for good.
You've spent an hour on launch threads this week already — this hour ends with K3 actually running on your machine.
And the modules are independent: even module one alone (10 minutes) leaves you with a working frontier model.
This course teaches one thing: how to go from "new model exists" to "new model works for me" — using Kimi K3, which launched this week, as the live example.
K3 in one breath: Moonshot's new flagship — a 2.5-trillion-parameter machine with a one-million-token memory, benchmarking around the Fable and Sol tier, tuned for long agent jobs. Slow on hard problems, right at the end of them.
The free part is double. The course costs nothing. And the model might too — if you're on the Kimi coding plan, K3 is already included; if not, it's $3 per million tokens on OpenRouter.
Each module is ten minutes: a thing to understand, a thing to type, and a checkpoint you can verify. Miss nothing, skip nothing, and at minute sixty you're an operator.
Every module below is complete on this page — commands included, nothing held back for a checkout.
The paid thing that exists (the Boardroom) is for people who want it done WITH them — the course itself is whole.
Open a terminal next to this page (Mac: press ⌘ + Space, type "Terminal", hit enter — that's the whole setup). Every module below is: do this → here's exactly what you'll see → checkpoint. If you can copy and paste, you can finish this course.
Not a terminal person at all? Modules 3 and 4 work in the chat at kimi.com too — I'll flag it when they do.
What you'll have at the end: a working K3 connection, very possibly for free.
K3 has two doors, and most people don't realise they're already holding a key to door one.
Step 1 — find your Kimi key. If you have the Kimi coding plan (the one that powers Kimi Code), log into kimi.com → settings → API keys. It starts with sk-kimi-. Copy it.
Step 2 — ask the endpoint what your plan serves. Paste this into your terminal (swap in your key):
export KIMI_API_KEY="sk-kimi-your-key-here"
curl -s https://api.kimi.com/coding/v1/models -H "Authorization: Bearer $KIMI_API_KEY"
Here's what you'll see — a JSON list of models. On launch day mine came back with three, and the one that matters is just two characters:
{"data":[
{"id":"kimi-for-coding", ...},
{"id":"kimi-for-coding-highspeed", ...},
{"id":"k3", ...} ← this line means the flagship is on your existing plan
]}
See k3 in that list? You're done paying. That's a 2.5-trillion-parameter frontier model riding a subscription you already own.
No Kimi plan? Door two. Grab a key at openrouter.ai — the model slug is moonshotai/kimi-k3, $3 per million input tokens, and everything in this course works the same way (endpoint https://openrouter.ai/api/v1 instead).
401 Unauthorized → your key is fine but it's the wrong KIND of key. Kimi has two: platform keys and coding-plan keys. K3-for-free needs the coding-plan key on the /coding/v1 endpoint.
404 or an empty list → you're on api.moonshot.ai (the platform endpoint). Point at api.kimi.com/coding/v1 — same key, different door.
✅ Checkpoint: your terminal shows a models list containing k3 (or your OpenRouter key accepts the slug). That's minute ten.
What you'll have at the end: a real conversation with K3 — and proof of what's actually answering.
Step 1 — say hello properly. This is the exact request shape you'll use all course. Two settings matter and I'll explain both the moment you see them:
curl -s https://api.kimi.com/coding/v1/chat/completions \
-H "Authorization: Bearer $KIMI_API_KEY" -H "Content-Type: application/json" \
-d '{"model":"k3",
"messages":[{"role":"user","content":"What model are you?"}],
"max_tokens":16000}'
Why max_tokens: 16000 and not 500? K3 is a reasoning model — it thinks before it answers, and the thinking spends your token budget. Set it low and the thinking eats everything: you get an empty answer and assume the model is broken. It isn't; it starved. I learned this the annoying way — my first SEO audit came back blank at 4,000. 16,000 is the floor; long builds want 48,000.
And don't set temperature. The coding endpoint accepts exactly one value (1) and errors on anything else: invalid temperature: only 1 is allowed. Just leave it out.
Here's what you'll see — and here's the trap. K3 answers something like:
"I'm Kimi K2.7, an AI assistant from Moonshot AI..." ← the model, being wrong about itself
Ask a model what it is and it tells you what its training data remembers — models are the last to know their own names. The truth is in the response envelope, not the prose. Step 2 — read the envelope:
curl -s https://api.kimi.com/coding/v1/chat/completions \
-H "Authorization: Bearer $KIMI_API_KEY" -H "Content-Type: application/json" \
-d '{"model":"k3","messages":[{"role":"user","content":"hi"}],"max_tokens":16000}' \
| python3 -c "import json,sys; print('served:', json.load(sys.stdin)['model'])"
Here's what you'll see:
served: k3 ← the endpoint's own receipt. This one can't lie.
✅ Checkpoint: served: k3 in your terminal. You now have a verification habit that transfers to every model you'll ever test.
What you'll have at the end: proof, on your own documents, that the headline feature is real. (This one works at kimi.com too — paste instead of curl.)
The pitch is a one-million-token window — roughly 750,000 words in view at once. Spec sheets say that; needles prove it.
Step 1 — build a haystack. Take the longest documents you have and stack them into one file. On a Mac:
cat ~/Documents/project-docs/*.md > haystack.txt
wc -w haystack.txt # aim for 50,000+ words — the bigger the better
Step 2 — bury a needle. Open the file and paste one invented line somewhere in the MIDDLE (the middle is where models forget):
The vault code is 7429 and the contact is Marcus Webb.
Step 3 — make it dig. Send the whole haystack with the question "What is the vault code and who is the contact?" — nothing else, no hints about position.
Here's what you'll see. My launch-day run: 162,000 tokens of noise, needle at line 4,321. K3 came back in 18 seconds:
The vault code is 7429 and the contact is Marcus Webb. ← exact, no "I think", no partial recall
What this means for your actual work: your whole codebase in one prompt. Your whole client-doc folder. A month of chat logs. "Summarise what we decided about pricing across all of this" becomes a real question.
✅ Checkpoint: exact recall of YOUR needle from YOUR haystack. If it misses, your haystack was probably under 10k words — too easy for the test to mean anything. Go bigger.
What you'll have at the end: a working artifact that didn't exist ten minutes ago. (Also works at kimi.com — same prompt, download the file it returns.)
Step 1 — pick the build closest to your business and use this exact prompt shape:
"Build a beautiful one-page website for [your business].
Dark elegant design, hero + services + contact section.
ONE self-contained HTML file — all CSS and JS inline. Return ONLY the HTML."
The two load-bearing phrases: "one self-contained HTML file" (so you get a thing that opens, not a folder of fragments) and "return ONLY the HTML" (so you don't have to fish code out of an essay).
Step 2 — start it, then walk away. Here's what nobody tells you about K3: it's SLOW on hard tasks, and that's a feature. My one-shot game took 13.4 minutes of thinking and produced 30,880 tokens of working code with zero errors. The wrong move is watching the cursor blink and assuming it died. Set max_tokens to 48000, start the request, make coffee.
Step 3 — save and open what comes back. Paste the output into a file called build.html, double-click it. Here's what you'll see — both of my module-4 runs, embedded live:
Both are the actual files K3 returned — playable and scrollable right here, not screenshots.
Step 4 — the round-two move. Don't accept draft one; steer it. I sent the game back with "add four hunter drones that chase the player, a hull bar, and redesign it Tron-style" — one follow-up, and the drones in that embed above are the result. Whatever your build is missing, ask for it in one specific sentence.
✅ Checkpoint: a file open in your browser doing what you asked — plus one steered improvement, so you've felt the edit loop, not just the magic trick.
What you'll have at the end: K3 completing a multi-step job with a verifiable end state — the thing it's actually tuned for.
A chat answers you. An agent CHANGES something and proves it did. The difference is the job description — give it a task where success is checkable:
"Create a file called playbook.md containing a 300-word briefing on [your topic]
with 5 numbered steps. Write the file, VERIFY it exists on disk,
and report its exact size in bytes."
Run that through any agent runner you have (Kimi Code CLI, Hermes, Claude Code with the K3 endpoint — the runner matters less than the job shape). Here's what you'll see — my launch-day run, verbatim:
✓ Wrote k3-agent-demo.md
✓ Verified: file exists on disk
✓ Size: 2,119 bytes · 5 numbered steps present
The agent closed the loop — wrote, checked, reported. Nobody re-prompted it.
And when you're ready to see how far this goes: the same pattern, pointed at Blender through an MCP connection, produced this — a video the agent modelled, lit, animated, luminance-checked and rendered by itself:
Module 5 at full power: the agent's own MP4 — 150 frames, keyframed liftoff, tracked camera. It even measured its check-frames' brightness before committing to the final render. The full build story is in The Long-Haul Engine.
✅ Checkpoint: a job that ended in a verified artifact, not a paragraph of advice.
What you'll have at the end: K3 living inside your daily stack as one switch among several.
Step 1 — give it a permanent seat. If you run Kimi Code, add an alias so k3 is one flag away — this exact block goes in ~/.kimi-code/config.toml:
[models."kimi-code/k3"]
provider = "managed:kimi-code"
model = "k3"
max_context_size = 1048576
display_name = "K3"
Running Hermes? Same idea, two commands: hermes profile create kimi-k3 --clone-from kimi-highspeed (then set its model to k3 and drop your key in the profile's .env), and hermes profile alias kimi-k3 so kimi-k3 -z "the job" --yolo dispatches it from anywhere.
Here's what you'll see — mine, wired into the Agent OS dashboard the same afternoon:

K3 as one labelled toggle among four — next to the models it now competes with for every job.
Step 2 — decide its lanes. The operator move is routing, not religion. From a week of real use: K3 gets the MILLION-TOKEN jobs (whole-codebase questions, giant doc analysis) and the UNATTENDED jobs (agents that run twenty minutes and verify their own work). Your fast daily driver keeps the quick chats — K3 is too slow for those, and that's fine.
Step 3 — bench it on YOUR work. Take one real task you did this week, run it through K3 and through your current model, compare outputs side by side. That comparison — not launch-thread hype — decides what K3 does for you. (Want the full version of that method? The Frontier Shootout.)
✅ Checkpoint: K3 answers from inside your own stack, your old models still in their seats, and you know which jobs are K3's.
Time. You're an operator now — you've verified it, stretched it, built with it, run it as an agent, and given it a seat. That's the whole hour.

What you're looking at: the module-4 standard — K3's one-shot game under automated playtest. Your first build won't need to be a game; it needs to be REAL and yours.

What you're looking at: module 6 completed on my machine — K3 as one toggle among four, inside a stack that existed before it and will outlive it.
Check what your existing plans already include before paying anyone. K3 was sitting on the coding plan on day one.
The served-model field is truth; the model's self-description is folklore. One curl settles it forever.
Whatever the launch thread brags about — context, speed, agents — design one ten-minute test that would expose the brag if false.
One real artifact beats fifty hot takes. The file in your browser is the only review that counts.
New models earn a slot beside the old ones. Jobs migrate one at a time to whoever wins them.
Because the six habits are model-agnostic — K3 is just this month's live cadaver. The same hour works on every launch after it.
Operators who ran this loop on launch day had real opinions by dinner. That gap compounds monthly.
No — that's the biggest myth about it. The everyday 90% runs on free local models on your own machine, and free APIs slot in for more — this entire course runs on a model your coding plan may already include.
For the frontier work, the Agent OS drives the plans and CLIs you already pay for — your Claude subscription includes the Claude Code CLI, your Kimi plan now includes K3. It's a layer on top of what you own, not a second bill.
And inside the AI Profit Boardroom there are full token-optimisation tutorials, so usage drops further still.
Wrong: "I need to be technical to test frontier models properly."
Right: The whole course is six copy-paste commands and four prompts. If you can paste into a terminal once, you can run every module.
Wrong: "The real testing happens at AI labs; I just consume the results."
Right: The needle test, the build test and the agent test in this course are more relevant to YOUR work than any lab benchmark — because they run on your tasks, your stack, your bill.
Wrong: "A free course can't change how I work."
Right: The change isn't the course — it's the habit of spending launch day operating instead of reading. That habit is free and it compounds every single month.
Members post their wins every day — agency owners, ecom founders, course creators, solo operators across 38 countries. Real businesses, real numbers, in their own words.
Read the 158-page wins doc →Every checkpoint in this course is something I did for real on launch day — the game, the sites, the needle test, the agent run and the stack wiring all shipped within hours of the announcement, and they're all linked above.
Then you'll have benched it, known early, and moved on — with the six-module habit intact for the next launch.
The hour was never really about K3. It's about never being a spectator on launch day again.
0:00 — hit the models endpoint on your coding-plan key; no plan → OpenRouter slug.
0:10 — verify served: k3 from the API response, never the model's self-report.
0:20 — needle test: bury a fake fact in your longest docs, demand exact recall.
0:30 — one-shot build: a landing page or tool for YOUR business, one self-contained file.
0:40 — agent task: file written, verified, reported. An end state, not an opinion.
0:50 — wire it in as one profile beside your existing models; bench before trusting.
1:00 — pick K3's lane: long-memory jobs and unattended agent runs first.
Ongoing — rerun this exact hour on every future launch. The habit is the asset.
All six modules, checkpoints verified. Keep the artifacts — they're your before/after proof.
Route your real work through it for a week. Track which jobs it wins against your daily driver.
Build one workflow only possible at 1M context — whole-repo review, full-archive Q&A, all-docs audits.
Write your own six-module checklist so the next launch costs you 60 minutes, not a weekend.
On a key you may already own — checked before you paid anyone.
Served-model from the endpoint, forever. No launch-day identity confusion again.
The 1M window proven on your own documents, not a spec sheet.
An artifact in your browser with your name on it — the only review that counts.
A task that ended in a checked file. That's the K3 speciality, witnessed.
The same six modules work on every launch after this one.