Post
Khairallah AL-Awady
@eng_khairallah1
How to Build a $10K/Month Agentic Harness using Kimi K3 (Full Course)

Here is the thing almost nobody tells beginners: the model is not the agent.

Save it :)

You can take the most capable coding model on earth, hand it your repository, and watch it produce confident nonsense, break your tests, and wander off task by step forty. And you can take that same model, wrap it in the right scaffolding, and watch it profile a slow endpoint, fix it, run the tests, revert what didn't work, and hand you a clean diff with a log of what it tried.

Same model. Completely different outcome. The difference is the harness.

A harness is the scaffolding around a model that turns a thing that answers questions into a thing that does work. It is the loop, the tools, the permissions, the memory, and the rules. And Moonshot, the lab behind Kimi K3, says the quiet part out loud in their own documentation: the harness is part of the product. K3 was built to live inside one.

This is the full course on building that harness. By the end you will understand exactly what a harness is, how to stand one up with Kimi K3 in a few minutes, how to shape its behavior, how to keep it safe, and how to run it on real engineering work without babysitting it. Written for someone who has never built an agent in their life. Let's go.

What an Agentic Harness Actually Is

Forget the jargon for a second. Here is the whole idea in one picture.

A plain language model works like this: you send text, it sends text back, and it forgets everything. It cannot open a file, run a command, or check whether its answer was right. It is a brilliant intern locked in a room with no hands and no memory.

A harness gives that intern hands, eyes, and a checklist. Specifically, it wraps the model in a loop with four moving parts:

→ Plan. The model looks at the goal and decides the next step.

→ Act. It takes an action in the real world through a tool, reading a file, editing code, running a shell command, searching the web.

→ Observe. The result of that action, the test output, the error message, the file contents, gets fed back into the model.

→ Repeat. With that new information, it plans the next step, and the loop runs again until the job is done or a limit is hit.

That loop is the beating heart of every coding agent. Around it sit four more things that separate a toy from a tool: the tools it is allowed to use, the permissions that keep it from doing damage, the memory that lets it carry context across steps, and the success condition that tells it when to stop. Get those five things right, the loop, the tools, the permissions, the memory, and the success condition, and you have a real harness.

The good news for a beginner is that you do not have to build all of this from scratch. Kimi ships a ready-made harness, and the fastest way to learn is to use it first and understand it as you go.

Why Kimi K3 Is Built for This

Before the setup, a straight answer to "why this model." I am going to give you the honest version, strengths and limits, because a course that only sells you the upside is not teaching you anything.

K3 is Moonshot's flagship, launched in July 2026. It is a 2.8-trillion-parameter model, the largest open-weight model ever released, with a one-million-token context window and native vision. And it was explicitly designed for long-horizon coding: sustaining long engineering sessions with minimal human oversight, navigating large repositories, and orchestrating terminal tools.

Here is what that buys you in a harness, concretely:

→ A one-million-token context window means you can put a real, large codebase in front of it and have it reason across the whole thing, instead of feeding it a few files and hoping it infers the rest.

→ Strong repository navigation, which is the unglamorous skill that actually matters when an agent has to find the right file among four hundred.

→ Cache-friendly economics. On the long, repetitive loops that agents run, K3 reports a very high cache-hit rate, which keeps the bill down precisely where a per-token frontier model would run it up. Its token price is roughly a third of the top closed models. For work that loops a hundred times, that is the whole game.

And the honest limits, so you route intelligently:

→ It is not the fastest, and it is verbose. K3 runs at maximum reasoning effort by default, so expect longer first-token waits and more output tokens than a leaner call. Lower-effort modes are on the roadmap but max is the default today.

→ On raw capability, Moonshot itself concedes K3 trails the very top closed models on the hardest single tasks. Where it shines is long, repetitive, context-heavy agentic work, not necessarily the one impossible bug. It did, however, take the number-one spot in blind frontend-code testing, so for building UI it is genuinely best-in-class.

→ You are not self-hosting this on your laptop. At 2.8 trillion parameters the weights run to well over a terabyte even heavily compressed, which means multi-GPU servers, not your MacBook. For almost everyone, "using K3" means the hosted API or the app, and that is completely fine.

The takeaway: K3 is the model you point at big, long, repetitive engineering jobs where context and cost matter more than winning a benchmark by half a point. That is exactly the work a harness is for.

The Fastest Harness: Kimi Code

The quickest way to get an agent running against your code is Kimi Code, Moonshot's own open-source coding agent. It runs in your terminal, and it is already a complete harness: it reads and writes your files, executes shell commands, and drives a full engineering session instead of just answering a question.

The setup is short. A few notes first, because these trip people up: the official installer does not require Node.js, and on Windows you need Git for Windows installed first, because the CLI uses its bundled Git Bash as the shell. Grab the current install command straight from Kimi's own docs so you are running the latest version, then the flow is:

1. Install the CLI using the official one-line installer from the Kimi Code docs.

2. Authenticate. Launch it and run the login step:

bash
kimi
/login

This opens a browser to connect your account. You can authenticate through your Kimi account or with a platform API key.

3. Pick the model. Inside a session, choose K3 with the model command:

bash
/model

Select K3 for the heavy work. One important habit: switching models mid-session invalidates the prompt cache, which is part of what keeps long runs cheap, so pick your model deliberately rather than flip-flopping.

4. Point it at a project and give it a task.

bash
cd your-project
kimi

Then describe what you want in plain English. It plans, edits files, runs commands, and reports back.

That is a working harness. But typing "fix my bug" into it is like hiring a contractor and saying "make the house better." The skill, the part that actually separates people who get results from people who get slop, is in how you brief it. That is the next section, and it is the most important one in this course.

The Anatomy of a Task That Actually Works

An agent is only as good as the goal you give it. Vague goals produce drift. Measurable goals produce results. Here is the template I would tattoo on a beginner's arm, and why every line is there.

markdown
Read the relevant parts of this codebase before you change anything.

Objective: [a measurable outcome, e.g. "cut the p95 response time on the
/search endpoint by 30%", not "make it faster"]

Rules:
- Profile first. Show me where the time actually goes before touching code.
- Do not change public interfaces or the values the code returns.
- Run the existing test suite after every change.
- If a change makes things worse or breaks a test, revert it and tell me why.
- Keep working until the objective is met, or prove it can't be met without
  breaking a rule.

When you're done, give me a log: what you changed, what it bought, and what you tried that didn't work.

Every line earns its place.

"A measurable outcome" is the single most important thing in this entire course. An agent given "improve the code" has no way to know when it is finished, so it wanders. An agent given "cut p95 latency by 30%" has a target it can test itself against, which is what keeps it on the rails across a long run. If you cannot state how you would check whether it succeeded, it will drift. Full stop.

"Profile first" stops it from guessing. "Run the tests after every change" turns the test suite into a safety net the agent checks itself against. "Revert if worse" gives it permission to fail without leaving a mess. And "what you tried that didn't work" is the line that turns the output from a raw diff into an engineering log you can actually learn from.

Master this shape and you can point a harness at almost anything. The rest of the course is about making the harness itself smarter and safer around briefs like this.

Shaping the Harness: AGENTS.md and Custom Agents

Out of the box, the agent behaves generically. To make it behave like it works on your project, you give it a constitution.

Kimi Code reads a file called AGENTS.md from your project, and every session obeys it before doing anything. This is where you encode the rules that should never change. Moonshot's own guidance is explicit: if you want the agent to stay within well-defined boundaries and not improvise, put those constraints in the system prompt or in AGENTS.md.

A good starter AGENTS.md looks like this:

markdown
# Project Rules — read before any action

## How this project works
- Language / framework: [yours]
- Run tests with: [exact command]
- Run the app with: [exact command]

## Always
- Read before you write. Understand the existing pattern before adding a new one.
- Match the existing code style. Don't reformat files you didn't need to touch.
- Run the test command after every change and paste the result.
- Make the smallest change that solves the task.

## Never
- Never change public interfaces without flagging it first.
- Never touch files in /migrations or /secrets.
- Never delete tests to make a build pass.
- Anything destructive or ambiguous: stop and ask me.

This one file is the difference between an agent that respects your codebase and one that treats it like a blank canvas. Write it once, and every task inherits it.

Kimi Code also supports custom agents defined in Markdown, so you can build named, specialized agents, a "test writer," a "refactorer," a "reviewer", each with its own instructions, and call the right one for the job. Start with a solid AGENTS.md; grow into custom agents as you find yourself repeating the same kind of task.

Permissions and Safety: The Part Beginners Skip

Here is where amateurs and professionals split. You are about to let an autonomous agent read and write your files and run shell commands, possibly for a long time, possibly while you are not watching. The harness is not just what lets it act. It is what stops it from doing harm. This is not optional, and it is the most under-taught part of the whole topic.

Look at how Moonshot's own evaluation harness is configured, because it is a masterclass in sane defaults. The agent runs with the filesystem restricted to the workspace only, the network denied by default, secrets available only as synthetic test values, and deployment flatly denied. On top of that it runs under hard budgets: a cap on attempts per task, a wall-clock time limit, a maximum number of steps, and a maximum dollar cost.

Steal every one of those ideas for your own setup:

→ Version control before anything. Initialize git and commit before you let the agent loose. If a run goes sideways, one command rolls the whole thing back. This is your seatbelt; wear it every time.

→ Keep it in the workspace. The agent should touch your project directory and nothing else. No wandering into system files or unrelated folders.

→ Deny the network and hide real secrets by default. An agent does not need your production credentials to refactor a function. Give it synthetic values and turn networking on only when a task genuinely requires it.

→ Never let it deploy on its own. Building and testing is one thing. Pushing to production is a human decision. Keep an approval gate there, always.

→ Set budgets. A step cap, a time cap, and a cost cap. These are what stop a confused agent from looping for six hours and running up a bill. If it cannot finish inside the budget, that is information, not a failure.

None of this makes the agent less capable. It makes it something you can actually trust to run unattended, which is the entire point of building a harness in the first place.

Subagents: One Agent Is Good, a Team Is Better

Once you are comfortable with a single agent in a loop, the next level of leverage is having several work together. Kimi Code supports cooperative subagents, and the pattern that matters most is simple to understand.

Instead of one agent trying to do everything, you split the work by role:

markdown
Run this as a multi-agent workflow, not one agent doing everything.

The job: [describe the full task].

Structure it like this:
1. A lead agent reads the codebase and breaks the work into independent parts.
2. Spin up a worker agent per part to do them in parallel.
3. A separate reviewer agent checks every result against this standard:
   [your quality bar — tests pass, style matches, no interface changes].

Only return work that passes review. Anything that fails goes back to be
redone, and keep looping until the whole job meets the standard.

The reviewer is the secret ingredient, and here is why it works. A single agent grading its own output goes easy on itself, the same way you never catch every typo in your own writing. A separate agent checking the work against a fixed standard has no ego in it. That one structural change, a verifier that didn't do the work reviewing the work, catches a huge share of the errors that would otherwise slip through. K3's large context is what makes this practical: the lead can hold the whole repo in view while it splits the work.

The Loop That Runs Itself

Now put it together into the thing everyone actually wants: an agent that works on its own and hands you finished results.

The recipe is everything above, combined. A clear, measurable objective. An AGENTS.md that encodes your rules. Sane permissions and a budget. And a verifiable success condition the agent can check itself against without you in the loop.

That last piece is what makes autonomy safe. The reason a long unattended run works is that the goal is checkable. "Make this faster on this benchmark without changing what it outputs" is a goal an agent can pursue for hours because it can measure its own progress at every step. "Improve the code" is not, and an agent given that on a long leash will wander into the weeds. The measurable condition is the leash.

When you run one of these, insist the harness produce artifacts you can audit afterward: the trace of what tools it called, the final diff, the test results, and the token and cost breakdown. Moonshot's own harness requires exactly these. They turn "the agent did some stuff overnight" into "here is precisely what happened, what it cost, and what I can trust." Read the diff, run the tests yourself, and only then merge. The agent owns the throughput. You own the judgment about what ships.

For the Ambitious: Building Your Own Thin Harness

Everything so far uses Kimi Code, the ready-made harness, which is where every beginner should start. But if you want full control, wiring K3 into your own automation, your own editor, your own pipeline, the API is open to you, and it is OpenAI-SDK compatible, which means switching an existing integration over is often a change of base URL and model string rather than a rewrite.

You do not need to see hundreds of lines of code to understand the shape. A minimal harness you build yourself is just this loop:

markdown
1. Send the model a system prompt (its rules) and the task.
2. The model replies with either an answer or a request to use a tool.
3. If it asked for a tool, YOUR code runs that tool (read a file, run a
   command) and sends the result back to the model.
4. Repeat 2-3 until the model says the task is done, or you hit your
   step/time/cost budget.
5. Return the result and the log.

That is the entire concept. Everything sophisticated, subagents, verification, memory, is an elaboration of that five-step loop. The reason to reach for this door is control: your own agent decides what gets generated, when, with which model, in what order. The reason most people never need it is that Kimi Code already does all of this well. Start with the ready-made harness. Build your own only when you hit a wall it cannot get you past.

Routing and Cost: Don't Put Everything on K3

One habit will save you more money than any other, so I am making it its own section.

K3 runs at maximum reasoning effort by default, which means it thinks hard about everything, including trivial work that does not need it. Pointing K3 at a one-line formatting fix is like flying a cargo jet to pick up a sandwich. It works, and it is absurd.

The professional move is routing. Keep small, mechanical work, tiny diffs, boilerplate, formatting, on a lighter, cheaper model. Promote to K3 when the task is genuinely expensive in human time: architecture decisions, multi-module bugs, long agentic plans, big-context repo work. That is where K3's context, navigation, and cache economics pay for themselves many times over, and where a cheaper model would flail.

And remember that reasoning tokens are output tokens. If your bill looks higher than expected, it is usually not that the model is broken, it is that its thinking counts as output. Budget for it, route around it on cheap tasks, and let K3 do what it is uniquely good at.

When It Goes Wrong: A Short Troubleshooting Guide

Real rough edges, and what to do about each.

It drifts on long runs. Almost always because the goal was vague. Fix: give it a measurable success condition it can test itself against. This solves more drift than any other single change.

The context fills up anyway. A million tokens feels infinite until you dump a whole monorepo into it. Fix: point it at the directories that matter, not everything. A tight, relevant context beats a bloated one.

It's slow and verbose. That is max reasoning effort doing its job. Fix: accept it on hard tasks where the thinking is worth it, and route trivial work elsewhere.

The bill surprised you. Usually reasoning tokens counted as output, or K3 aimed at work a cheaper model should have handled. Fix: routing and a cost cap.

You wanted to run it locally. You can't, not on consumer hardware. Fix: use the hosted API or app, which is what nearly everyone does anyway.

The Point

Here is the shift this whole course is really about.

For a long time, "using AI to code" meant typing questions into a box and pasting answers back out. You were the loop. You planned, you ran the code, you checked the result, you fed it back. The model was fast, but you were still doing all the connective work by hand.

A harness moves that connective work to the machine. You stop being the loop and start directing it. You keep the judgment, what the goal is, which diff ships, what the thing should be, and the harness takes the volume, the planning, the edits, the test runs, the retries, the hundred small steps in between.

And here is the part that compounds: the harness outlives the model. When a better model lands, you drop it into the same harness and everything you built, your rules, your subagent workflow, your budgets, your success conditions, instantly gets sharper. You are not building around one model. You are building the thing that makes every model useful.

K3 is a genuinely strong model to build this on, huge context, real repo sense, cheap on the long loops that matter, honestly not the fastest and not the winner on every benchmark, but exactly suited to the long, patient, context-heavy work a harness is for. Start with Kimi Code, write a real AGENTS.md, give it measurable goals, lock down the permissions, and let it run.

The people who pull ahead in this next stretch will not be the ones with the best model. They will be the ones who built the best harness around whatever model is best this month.

Open a terminal, point it at a real repo, and give it something you'd never have the time to do yourself. That's the whole shift.

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 ❤️

3:09 AM · Aug 12, 2026
6.8M
Views
33
95
732
3.5K
Gipp 🦅
@gippp69
Aug 12
WW habibi
1
3
12K
Videl
@videleth
Aug 12
Great read brother
1
1
3.5K
Avid
@Av1dlive
Aug 12
Great post, brother. Love this
1
1
11K
See all the replies
Continue to X
Log in or sign up for X

See what’s happening and join the conversation

Continue with phone
Continue with Apple
Continue with Google
Continue with Google
or
Log in with username or email
Relevant people
Khairallah AL-Awady
@eng_khairallah1
Follow
Terms
·
Privacy
·
Cookies
·
Accessibility
·
US TIDA
·
Ads Info
·
More
© 2026 X Corp.
Scan to get the app