How to Use Kimi K3 in Cursor Without Breaking Your Agent Workflow

How to use Kimi K3 in Cursor comes down to two routes: paste a Moonshot API key into Cursor Settings with the base URL https://api.moonshot.ai/v1 and model id kimi-k3, or route through OpenRouter. Both enable chat only; Agent mode, Tab, and indexing stay on Cursor's backend.

What Kimi K3 is, and why developers want it in Cursor

Kimi K3 is Moonshot AI's flagship model, launched on 2026 July 16. It is a roughly 2.8 trillion parameter Mixture of Experts architecture with 896 experts and 16 active per token, a Kimi Delta Attention mechanism, native vision, and up to a 1 million token context window. The launch variants are K3 Max and K3 Swarm Max. The specs are covered in detail by CNBC and Simon Willison. You will also see people search for it as Kimi 3, but the official name is Kimi K3.

The reason developers want it inside Cursor is simple math. Launch pricing is 3.00 dollars per million input tokens on a cache miss, 0.30 dollars per million cached input tokens, and 15.00 dollars per million output tokens, flat across the full 1 million token window, according to eesel AI's pricing breakdown. That is about 40 percent cheaper than Claude Opus 4.8 at 5 and 25 dollars per million tokens respectively, per the Morph LLM comparison. Third parties are calling K3 a value bet if the benchmark numbers hold, not a certified winner on every axis. Treat it that way: cheap enough to experiment with seriously, not yet proven enough to bet your whole workflow on.

The second reason is plumbing. The Kimi K3 API is OpenAI compatible, supports tool calls, JSON mode, structured output, and context caching, and exposes the model id kimi-k3 at the base URL https://api.moonshot.ai/v1, per the Requesty model page. OpenAI compatibility is exactly what Cursor's custom key override expects, which is why this setup works at all.

A quick note on who this guide is for. Developers wiring an editor are the obvious audience, but GTM engineers reading this are usually evaluating whether a cheap, capable model can power parts of an AI native outbound stack or the wider tooling covered in our best AI SDR platforms for 2026 roundup. The setup is identical either way. What changes is what you expect the model to do once it is connected, and that distinction drives the second half of this article.

Before you start

Get three things ready before you touch Cursor Settings.

First, a Cursor install where you can reach Settings, then Cursor Settings, then the Models section. Cursor's policy on custom keys and which plans gate which model settings has shifted over time, so before you build a daily workflow around a custom key, verify the current state against Cursor's own docs and forum. The threads on what changes with your own key and agent mode with an own key are the right starting points.

Second, a key. For the direct route, create an account at platform.moonshot.ai, which is Moonshot's console for keys and billing, and generate an API key there. The kimi-k3 API is pay as you go, per the Requesty model page. For the aggregator route, create an OpenRouter account and key instead. One is not better than the other by default; the tradeoffs are in the route sections below.

Third, the exact values you will paste. Getting these wrong by one character is the most common failure mode, so copy them from here:

• Moonshot direct: base URL https://api.moonshot.ai/v1, model id kimi-k3.
• OpenRouter: base URL https://openrouter.ai/api/v1/cursor, model name moonshotai/kimi-k3.

If your work also involves connecting a coding agent to a repository rather than just chatting about one, the GitHub MCP connection is the cleaner path for repo access, and it pairs fine with everything below.

Route A: wire Kimi K3 with the Moonshot direct API

This is the route Moonshot documents in its own Kimi Cursor guide, and it is the one I recommend starting with because it has the fewest moving parts between you and the model.

1. Open Settings, then Cursor Settings, then Models.
2. Under API Keys, enable the OpenAI API Key toggle and paste your Moonshot key from platform.moonshot.ai.
3. Enable Override OpenAI Base URL and set it to https://api.moonshot.ai/v1 .
4. Add a model named kimi-k3 and toggle it on.
5. Pick Kimi K3 in the chat model dropdown.

Then verify. Send a short message in chat and confirm two things: that a response comes back at all, and that usage shows up in your Moonshot console billing. If chat returns an authentication error, the key is wrong or the key lacks billing. If it returns a model not found error, the model name in the Models list does not exactly match kimi-k3. Both are five second fixes once you know which one you are looking at.

One behavior worth expecting: Cursor may warn that the model has limited agentic support. That warning is accurate, and the reasons are in the limitation section below. It does not block chat.

Route B: wire Kimi K3 through OpenRouter

OpenRouter sits between Cursor and Moonshot, which gives you one bill and one key across many models. The values come from the OpenRouter tutorial for Cursor:

1. In Cursor Settings, then Models, enable Override OpenAI Base URL and set it to https://openrouter.ai/api/v1/cursor .
2. Add the model moonshotai/kimi-k3 .
3. Paste your OpenRouter key in the OpenAI API Key field.
4. Toggle the model on and select it in the chat dropdown.

Note the model name difference. Direct uses kimi-k3; OpenRouter uses the namespaced form moonshotai/kimi-k3. Mixing them up is the classic route B failure.

Which route should you pick? Route A has fewer hops, direct billing visibility in the Moonshot console, and one less third party in the request path. Route B is better if you already run other models through OpenRouter and want consolidated spend, or if you want to swap between providers without touching Cursor Settings again. For a first setup, go direct. You can always add OpenRouter later; the two configurations coexist.

The one thing a custom key cannot do in Cursor

This is the section most setup guides skip, and it is the one that will actually bite you.

A custom OpenAI compatible key in Cursor enables chat completions only. Cursor Agent, also called Auto mode, Cursor Tab autocomplete, and codebase indexing stay on Cursor's own backend and do not route to an external key, per the Cursor forum threads on what changes with your own key and agent mode with an own key. This is also why Cursor may warn that your custom model has limited agentic support. The warning is not a bug in your configuration. It is the architecture.

The practical consequence: you can chat with Kimi K3 inside Cursor, but you cannot point Cursor's agent loop at it. The features that make Cursor feel agentic, the ones that edit multiple files, run commands, and tab complete as you type, are still being served by whatever models Cursor runs on its own infrastructure. Your Moonshot or OpenRouter spend covers chat turns, nothing else.

Also be aware that this policy has shifted over time. What a custom key enables has changed across Cursor versions, and it may change again. Before you standardize a team on this setup, verify the current behavior against Cursor's documentation, and recheck after major Cursor updates. Do not build a cost model that assumes the agent loop will eventually route to your cheap key. It might never.

If your plan was "get Opus class coding help at K3 prices for everything Cursor does," that plan does not survive contact with this limitation. Adjust expectations now, not after a week of confusing behavior.

When Cursor is the wrong home for Kimi K3

There is a real question hiding under the setup question: do you want Kimi K3 answering in a chat pane, or do you want it doing work?

The model itself is not the constraint. The kimi-k3 API supports tool calls, JSON mode, structured output, and context caching, per the Requesty model page, which is the full ingredient list for agent behavior. Open weights were also slated to publish by 2026 July 27 under a Modified MIT license for self hosting, per the Kimi K3 status page, subject to the serious hardware a 2.8 trillion parameter model demands. The constraint is the harness. Cursor's chat pane with a custom key is a completions client. It cannot hold a multi step job, call your tools, or own an outcome.

If the job is coding assistance while you type, Cursor plus route A is a fine, cheap setup and you can stop reading. If the job is autonomous execution, you need an agent runtime where the model is a swappable component. We have written about what that looks like with Claude Code as an agent runtime for GTM work, about building your own GTM agent from scratch, and about the broader category of autonomous sales agents. The pattern is always the same: the model reasons, the runtime orchestrates tools and state, and the operator keeps review over anything customer facing.

Concrete example. Say you want K3 to qualify inbound leads overnight: pull fresh accounts from a data source like Crustdata, run a defined lead qualification task, and write results back to the CRM. No editor does that, regardless of which key you paste in. That is an agent operating system problem, which is the architecture behind an agentic GTM operating system.

This is also where Yalc fits, once, plainly: Yalc is an agentic GTM operating system that runs autonomous, conversational GTM agents on top of your existing CRM, sequencer, call recorder, and data providers, and it is model agnostic by design. If Kimi K3's price to capability ratio holds up, it is exactly the kind of model you would want to drop into that runtime and evaluate against your current one, without rewiring anything else. If you only ever want a cheaper chat panel in your editor, you do not need it.