How to Use Kimi K3 for Coding with Kimi Code

Moonshot AI built Kimi K3 for coding work that does not fit in a single prompt. The goal is long-horizon engineering: point a model at a large repository, let it inspect files, run tools, execute tests, read logs and screenshots, and iterate until the task is complete. That requires more than autocomplete—it requires a coding agent around the model. Moonshot provides that agent as Kimi Code. This guide shows how to run K3 in Kimi Code, structure an agentic workflow, compare it with Claude Code and Cursor, and verify the APIs it generates.

Try Apidog today

TL;DR: Running Kimi K3 for coding

Kimi K3 is Moonshot AI’s flagship model, launched July 16, 2026, with a 1 million token context window and an architecture tuned for repository-scale work. Use it through Kimi Code, Moonshot’s terminal and IDE coding agent: select the model with /model, then give it a concrete task.

K3 is designed for navigating large codebases, using tools, debugging, and iterating against screenshots, logs, tests, and runtime feedback. It is cost-effective on cache-heavy loops thanks to a reported cache-hit rate above 90%, but it is not the fastest option at roughly 62 tokens per second. Moonshot also states that K3 trails Claude Fable 5 and GPT-5.6 Sol on raw capability.

When K3 generates or changes an API, use Apidog to send real requests and confirm the endpoints behave as expected. For model background, start with what is Kimi K3.

What Kimi Code is

Kimi Code is Moonshot’s coding agent. It runs in a terminal, integrates with IDE workflows, reads and writes files, executes shell commands, and manages an engineering session instead of only answering questions.

Open Kimi Code from a project directory, describe a task, and let it:

1. Inspect the repository.
2. Plan an approach.
3. Edit files.
4. Run commands and tests.
5. Read failures and logs.
6. Revise the implementation.

The model provides text generation and tool use. Kimi Code provides the working environment: filesystem access, shell access, test output, logs, and screenshots. Together, they can execute a complete engineering loop.

Kimi Code existed before K3; the Kimi K2 line used the same agent. For installation details, see the Kimi Code CLI guide and the broader how to use Kimi CLI reference.

Getting Kimi K3 running in Kimi Code

Moonshot can change installation commands and flags, so verify the current syntax in the official Kimi documentation or the Kimi Code CLI guide. The following commands illustrate the workflow rather than providing guaranteed current syntax.

1. Install Kimi Code and authenticate

Install the command-line agent, then authenticate it with your Kimi account and API key from the Kimi developer platform.

Store the API key as an environment variable. Do not paste it into a project config file that could be committed accidentally.

# Representative syntax only. Check Kimi documentation for current commands.
export KIMI_API_KEY="your-key-here"

# Launch the agent from the current directory
kimi-code

2. Start Kimi Code from the repository root

Kimi Code treats the current directory as its workspace. Start it from the repository root so it can inspect the project structure and resolve paths correctly.

cd path/to/your-repository
kimi-code

3. Select Kimi K3

Inside the Kimi Code session, switch to K3 with /model:

/model kimi-k3

Use the same command to switch between K3 and other available models, including coding-focused options such as Kimi K2.7 Code.

4. Set an appropriate reasoning effort

K3 supports configurable reasoning effort, including a max setting.

Use higher reasoning effort for:

• Large refactors
• Difficult debugging
• Multi-step failures
• Tasks that require tracing behavior across many files

Use lower effort for:

• Small edits
• Straightforward test additions
• Renaming or formatting work
• Simple configuration updates

Once K3 is selected and Kimi Code is running in your repository, give it a concrete task. If you want to try K3 without installing Kimi Code, see how to use Kimi K3 for free.

A practical agentic coding workflow

The reliable pattern is simple:

1. Give K3 a specific, verifiable task.
2. Let it collect context and make changes.
3. Require it to validate the result with objective feedback.

Give it a concrete task

Avoid vague prompts such as:

Improve the auth module.

Instead, define the failure, expected behavior, and validation criteria:

The /login endpoint returns HTTP 500 when the password field is empty.

Reproduce the bug, identify the root cause, fix it, and add a test
covering the empty-password case. Run the relevant test suite before
you finish.

A task like this gives the agent a clear finish line:

• Reproduce the error.
• Find the relevant route, service, or validation layer.
• Implement a fix.
• Add regression coverage.
• Run tests to prove the fix.

K3’s 1M-token context window makes repository-wide tasks more practical. The agent can follow a request from a route handler into middleware, services, data access code, and tests without requiring you to manually provide every relevant file.

Let the agent use tools

K3 supports tool calls. Inside Kimi Code, that means it can inspect files, search code, run builds, execute tests, hit a local service, and read the resulting output.

A typical loop looks like this:

1. Read relevant files and form a hypothesis.
2. Make a targeted edit.
3. Run tests, a build, or the application.
4. Read failures, stack traces, logs, or HTTP responses.
5. Revise the implementation.
6. Repeat until checks pass.

This is the key difference between asking a model for a code snippet and assigning a task to an agent: the agent can observe the result of its own changes and correct itself.

Use screenshots and runtime output

Agent feedback is not limited to text.

For frontend work, the loop can be:

1. Update the component or CSS.
2. Build and render the application.
3. Capture a screenshot.
4. Compare the result with the expected UI.
5. Adjust and repeat.

For backend work, replace screenshots with:

• Test reports
• Structured logs
• Stack traces
• HTTP responses
• Database query output

The workflow is the same: change, run, observe, revise.

Keep the loop honest with tests

Tests are the best completion signal for autonomous coding loops. Without them, an agent can make a plausible change while breaking behavior elsewhere.

For bug fixes, start with a regression test:

it("returns 400 when password is empty", async () => {
  const response = await request(app)
    .post("/login")
    .send({ email: "[e-mail]", password: "" });

  expect(response.status).toBe(400);
});

Then ask K3 to make that test pass without weakening existing coverage.

A strong task prompt is:

Add a failing regression test for empty passwords on POST /login.
Implement the smallest fix that makes the new test pass.
Run the authentication test suite and do not remove or weaken existing tests.

Kimi K3 vs Claude Code and Cursor for coding

K3 in Kimi Code is one option for running an agent against a codebase. Here is a practical comparison.

Dimension	Kimi Code (Kimi K3)	Claude Code (Fable 5)	Cursor
Form factor	Terminal and IDE coding agent	Terminal coding agent	AI-native code editor
Default model	Kimi K3, selectable with /model	Claude Fable 5 plus other Claude models	Built-in or bring-your-own models
Context window	1M tokens	Large, model-dependent	Depends on selected model
Repo navigation	Designed for large-repository, long-horizon work	Strong file and shell access	Strong editor indexing and retrieval
Tool use	Tool calls, shell, tests, screenshots	Tool calls, shell, MCP	In-editor tools, terminal, MCP
Cost lever	Lower cost on cache-heavy loops	Priced per Claude token	Subscription plus model usage
Open weights	Expected around July 27, 2026	Closed	Proprietary editor; models vary
Best for	Long repo-scale agent runs on a budget	Top-tier reasoning and reliability	Developers who want an in-editor workflow

A few practical takeaways:

• For maximum raw reliability on hard tasks, Moonshot says Fable 5 in Claude Code is ahead of K3.
• If you prefer an agent integrated into a polished editor, Cursor and Cline-style tools may fit better.
• If you want to compare alternative models in these tools, see GLM-5.2 in Claude Code, Cline, and Cursor.
• K3’s main advantages are its large context window, repository navigation, and pricing structure for long, repetitive agent loops.
• Once weights are released, K3 is expected to be the only option in this comparison that can be self-hosted.

Strengths and honest limits

What K3 is good at

Repository-scale context

A 1M-token context window lets K3 retain a large portion of a codebase at once. This reduces the need to manually decide which files the agent needs before it begins work, especially in monorepos.

Tool use and long-horizon autonomy

K3 is tuned for extended engineering sessions where it can orchestrate terminal tools, execute commands, inspect output, and correct its own work. That is useful for tasks such as:

• Multi-file refactors
• Debugging production-like failures locally
• Incremental migration work
• Build and test repair
• API implementation with test coverage

Cost on cache-heavy loops

Agentic workflows repeatedly send shared context, such as the file tree, system prompt, instructions, and previously read files.

K3’s cache-hit input price is listed as $0.30 per million tokens, compared with $3.00 per million tokens on a cache miss. Moonshot’s Mooncake inference reportedly reaches cache-hit rates above 90% on coding workloads.

For pricing details, see the Kimi K3 pricing breakdown.

Where K3 falls short

It is not the top raw-capability model

Moonshot’s launch post states that K3 still trails Claude Fable 5 and GPT-5.6 Sol.

On Moonshot-published coding benchmarks:

• Terminal Bench 2.1: K3 scores 88.3 vs. GPT-5.6 Sol at 88.8.
• DeepSWE: K3 scores 67.5 vs. Fable 5 at 70.0 and GPT-5.6 Sol at 73.0.

K3 is competitive, but it is not presented as the highest-scoring model. See the Kimi K3 benchmarks analysis for more detail.

It is not the fastest option

According to the Artificial Analysis listing, K3 generates roughly 62 tokens per second, below the median for its price tier. Its default behavior also leans toward maximum thinking effort.

For interactive workflows where you watch output stream in real time, that can be noticeable. If latency matters more than the last increment of quality, benchmark a faster model on your own repository first.

Open weights are scheduled, not immediately available

K3’s full weights are expected around July 27, 2026, rather than being available on launch day. If self-hosting is a requirement, treat that as a release date to track.

For direct comparisons, see:

• Kimi K3 vs Claude Opus 4.8
• Kimi K3 vs GPT-5.6 Sol
• Kimi K3 vs Kimi K2.7 Code

Real-world use cases

K3 is best suited to work that benefits from a long-running, feedback-driven loop.

Large monorepo refactors

Use K3 when a change touches routes, shared packages, services, tests, and deployment configuration. Its large context window can help it map the blast radius before it starts editing.

Example task:

Replace the legacy feature-flag client with the new adapter across this monorepo.

Update all affected packages, preserve existing behavior, remove unused imports,
run the workspace test suite, and report any packages that still depend on the
legacy client.

Long debugging sessions

Use K3 for bugs that require reproduction, inspection, and repeated validation.

Example task:

Investigate why the background worker duplicates email jobs after a retry.

Reproduce the issue locally, trace the retry path, implement a fix, add a
regression test, and run the worker test suite.

API implementation and contract verification

K3 can scaffold handlers, routes, validation, and tests. After it finishes, validate the actual client-facing behavior separately.

Example task:

Add POST /projects/:projectId/members.

Require authenticated users, validate the request body, return 201 for a new
member, return 409 for an existing member, document the endpoint in OpenAPI,
and add integration tests.

Verifying the APIs K3 builds

K3’s test suite can confirm that code runs. It does not automatically prove that an API behaves correctly for real clients.

Verify generated or modified endpoints for:

• Correct HTTP status codes
• Expected response body shape
• Validation failures
• Error payload consistency
• Authentication and authorization behavior
• Request headers
• OpenAPI contract compliance

This is where Apidog fits into the workflow. Send real requests to the generated endpoint, inspect response headers and bodies, and add assertions for status codes and JSON structure.

If K3 produces an OpenAPI specification, import it into Apidog to generate a request collection from the contract instead of manually rebuilding requests. Store API keys in Apidog environment variables so they do not leak into shared collections.

A practical verification flow:

1. Start the local API.
2. Import the generated OpenAPI spec into Apidog.
3. Create environments for local, staging, and production-like targets.
4. Send valid and invalid requests.
5. Add assertions for response status and JSON fields.
6. Save the collection as part of your repeatable API test workflow.

Because Apidog provides an MCP interface, you can also connect API tooling to an agent’s context. See visual debugging with Apidog’s MCP client for that workflow, or use Apidog in VS Code to keep API testing next to the code K3 writes.

Download Apidog to validate generated endpoints as soon as the agent finishes, rather than relying on a green unit-test run alone.

Where this leaves you

Kimi K3 is a capable option in Kimi Code when you use it for what it is designed to do: large repositories, long autonomous loops, and constant iteration against tests, logs, screenshots, and runtime output.

Its 1M-token context window and cache-oriented pricing make it practical for multi-step tasks that can become expensive with other frontier models. It is not the highest-capability coding model available, and Moonshot acknowledges that, but its cost and expected openness can make it a useful choice for repository-scale engineering work.

Start with a concrete, testable task. Let K3 inspect, edit, run, and revise. Then validate every generated API with Apidog before shipping.

For more background, see what is Kimi K3 and the Kimi K3 API guide.

Frequently asked questions

How do I use Kimi K3 for coding?

Run K3 inside Kimi Code, Moonshot’s terminal and IDE coding agent. Install the agent, open it in your project directory, select the model with /model kimi-k3, then give it a concrete task with clear validation criteria. Let it inspect files, run tools, execute tests, and iterate.

For installation details, see the Kimi Code CLI guide.

Is Kimi K3 good for agentic coding?

Yes. K3 is tuned for large-repository navigation, tool use, debugging, and iterative work against tests, logs, screenshots, and runtime feedback across a 1M-token context window. It is competitive on coding benchmarks, although it trails Fable 5 and GPT-5.6 Sol slightly.

Does Kimi K3 support tool calling for agent workflows?

Yes. K3 supports tool calls, tool-choice constraints, JSON mode, structured output, internet search, dynamic tool loading, and configurable reasoning effort. These capabilities allow it to run tests, execute shell commands, and manage an agent loop in Kimi Code.

For API-level implementation details, see the Kimi K3 API guide.

Can I test the APIs Kimi K3 writes?

Yes—and you should. The agent’s tests can show that the code runs, but they do not guarantee that a client receives the expected status code, response shape, validation errors, or authentication behavior.

Use Apidog to send real requests, add assertions, and import any OpenAPI specification K3 generates so you can validate the API contract.