Kimi K3 in n8n: Using Moonshot's 2.8T Model for AI Agents

On July 16, 2026, Moonshot AI released Kimi K3, a 2.8-trillion-parameter model with a 1-million-token context window. It is the first open-weight model to reach the 3-trillion-parameter class, and it lands with something n8n builders can use right away: an OpenAI-compatible API that speaks tool calling. That means you can point an n8n AI Agent at Kimi K3 today, without waiting for a native integration.

This guide covers what Kimi K3 is, how to wire it into an n8n AI Agent, what it costs, and when it is the right call over a frontier model like Claude or GPT. The facts here are current as of late July 2026. Model pricing and open-weight timelines move fast, so verify against Moonshot's platform before you commit a production workflow.

What is Kimi K3?#

Kimi K3 is Moonshot AI's flagship model, released on July 16, 2026. It uses a mixture-of-experts design with 2.8 trillion total parameters, a 1-million-token context window, and native vision. Moonshot positions it for long-horizon coding and agent work, and it reaches the hosted API today, with open weights scheduled to follow.

The headline number is the context window. A 1-million-token window is large enough to hold an entire codebase, a long support-ticket history, or a stack of documents in one prompt, which changes how you design an agent around it. The parameter count matters less on its own, but a 2.8-trillion-parameter mixture-of-experts model is a signal that Moonshot is chasing the frontier tier rather than the budget tier.

The 1-million-token context is the headline for agent builders. It holds a whole codebase or a long history in a single prompt.

Why should n8n builders care about Kimi K3?#

Three things make K3 practical for n8n. Its API follows the OpenAI Chat Completions format, so it drops into existing nodes. It supports tool calling and structured JSON output, which the AI Agent node needs to work. And its 1-million-token context lets an agent hold large documents or long histories without a separate retrieval step for every run.

Tool calling is the part that matters most. An AI Agent that cannot call tools is just a chat model, so a new model is only useful to agent builders if it selects and calls tools reliably. Kimi K3 supports function calling in the same shape OpenAI uses, which is what the AI Agent node connects its tools through. Because the API is OpenAI-compatible, you also skip the wait for a dedicated n8n node, the same model-swap trick that works for other providers.

How do you use Kimi K3 in an n8n AI Agent?#

Use the OpenAI Chat Model sub-node, not a Kimi-specific one. Create a credential with your Moonshot API key, set the base URL to https://api.moonshot.ai/v1, and enter kimi-k3 as the model name. Then connect that model to the AI Agent node exactly as you would connect OpenAI, and your existing tools and memory keep working unchanged.

A few practical notes. Your Moonshot account needs a small minimum top-up, around 1 dollar, before an API key will authorize. The model names you can enter are kimi-k3 for the flagship, or kimi-k2.7-code and kimi-k2.6 for the cheaper tier. Because the endpoint is OpenAI-shaped, the same setup also works in a plain HTTP Request node if you would rather call the API directly, though the AI Agent node is the reason most people are here.

Kimi K3 is OpenAI-compatible, so the setup is the OpenAI Chat Model node with the base URL pointed at Moonshot, then wired to the agent.

How much does Kimi K3 cost?#

As of late July 2026, Kimi K3 costs 3 dollars per million input tokens on a cache miss, 30 cents per million on a cache hit, and 15 dollars per million output tokens. That sits well under frontier closed models on input. If you want cheaper, the older kimi-k2.6 and kimi-k2.7-code run at 95 cents input and 4 dollars output.

The cache-hit price is the interesting line. At 30 cents per million, a repeated system prompt or a stable tool list becomes almost free on later calls, so prompt caching pays off more than usual here. Here is how the current tiers compare.

If cost is your main driver, the cheaper tiers are the story, not K3 itself. Pair any of them with the cost levers that apply to every model.

K3 leads on input cost, context size, and open weights. Frontier closed models still lead on ecosystem breadth and tuned latency.

Kimi K3 versus a frontier model: when should you switch?#

Pick K3 when cost per token, a very large context, or open weights matter more than ecosystem polish. Stay on a frontier model like Claude or GPT when you need the lowest latency, the widest tool ecosystem, or the most consistent instruction following. For many n8n agents the honest answer is to route by task, not to standardize on one.

This is the same open-weight versus closed-model trade-off that shows up whenever a strong open model ships, as it did with GLM-5.2. n8n makes the route-by-task approach easy: keep a multi-model fallback so a cheap model handles the routine calls and a frontier model handles the hard ones. You do not have to choose one model for the whole workflow.

K3 wins on cost, context, and openness. It is newer and less battle-tested in agents, and a 2.8T model can add latency.

What about Kimi K3's open weights?#

Moonshot has scheduled the full K3 weights for release on July 27, 2026, on Hugging Face, after which self-hosting becomes possible in principle. In practice, a 2.8-trillion-parameter model needs data-center hardware, so most n8n builders will keep using the hosted API. The open-weight release matters more for providers and regulated teams than for a solo automation.

If your reason for wanting open weights is local, private inference, a 2.8-trillion-parameter model is the wrong tool. The smaller open models are the realistic path for running a model locally with n8n. Moonshot has used a modified MIT license for recent Kimi releases, but it had not published the final K3 license terms at the time of writing, so treat the license as unconfirmed until the files land.

Should you move your n8n agent to Kimi K3?#

Run a small test before you commit. Point one non-critical agent at kimi-k3, replay a handful of real runs, and compare tool-call accuracy, latency, and cost against your current model. If K3 holds up on the tasks you actually run, roll it out gradually. The path below turns that into a quick check you can finish in an afternoon.

Wire an OpenAI-compatible model node, then test tool calls and cost on a non-critical agent before you standardize on Kimi K3.