Kimi K3: an open weight AI model built for long work

You paste a four hundred page specification into a chatbot and watch it remember the last third while the first half fades into static. That kind of work shows up every day in real companies, and most tools quietly make it worse by only holding a small chunk of context.

In July 2026, Moonshot AI open-sourced Kimi K3, a 2.8 trillion parameter model built with a one million token context window and a new attention design. It is not a small experiment. It is the kind of open weight model that can actually take on long work, and it is worth understanding before you decide to run it on your own hardware or in your own private cloud.

What Kimi K3 is

The official GitHub repository describes Kimi K3 as an open weight, natively multimodal, agentic model. That last word, agentic, is doing real work here.

A standard chat model waits for a prompt, answers, and stops. An agentic model is built to read, decide, act, read again, and repeat across many steps. It can look at a file, run a command, look at the result, and choose the next step without you typing a fresh prompt each time.

Kimi K3 is designed for exactly that loop. Its companion product, Kimi Code, is a terminal coding agent that reads and edits code, runs shell commands, searches files, and fetches web pages. The model and the tool are built together, and that is where the real story lives.

Here is the part most people underestimate. The one million token context window sounds impressive, but context windows are only as useful as the model behind them.

Older large context models had a real problem. They could see a lot of text, but they often treated the beginning of that text as decoration. The longer a document got, the more the model leaned on the most recent chunk and ignored earlier details. Moonshot built Kimi K3 around two architectural changes to fix exactly that.

The first is Kimi Delta Attention, or KDA. The second is Attention Residuals, or AttnRes. Moonshot describes these as a hybrid that combines linear and full attention. In plain terms, the model can scan long documents cheaply and then apply careful, exact attention to the pieces that matter. The result is a model that does not drop the front half of a document just because the back half arrived later.

That design choice changes what the tool is good at. It is not a general chatbot that happens to have a big window. It is a model shaped to keep a long thread of work coherent, which is the core skill an agentic coding agent needs.

Who it is for

Kimi K3 is not a desktop app you double click to open. It is a model, and the way you use it depends on the kind of team you are.

Developers and small software teams get the clearest value. Kimi Code runs in your terminal, which means it works where your code already lives. There is no separate window to drag a file into. You point it at a repository, describe the task, and let it work through files, commands, and searches. If your team is already comfortable with an agentic coding setup, this is the kind of tool that fits into regular work rather than a demo.

Private and local teams get the open weight angle. Because the weights are public, you can run the model in your own environment and keep your data on your own servers. That matters a lot when your work includes customer records, internal documents, or code you do not want sent to a cloud provider.

Knowledge workers also benefit from the long context. Legal review, contract drafting, technical writing, and product documentation all benefit from a model that can hold a long document and reason across it without you re pasting pages every time.

The honest caveat is that you need to be comfortable with infrastructure. Running a model of this size is not a single download. You need real compute, and you need to decide whether you will run it on your own machines, on a private cloud, or through a hosted provider that serves the weights.

Limits and things to watch

Every tool has edges, and an agentic coding model has a few worth naming before you start.

First, it is a long work tool, not a magic one click fix. Agentic agents are best when they can take a step, check the result, and adjust. The moment the task is ambiguous or the repo is messy, you will be reviewing their work more often, not less.

Second, the architecture is new. The KDA and AttnRes design is described by Moonshot as a hybrid approach, and a new attention mechanism has real cost implications. Long context can be expensive to run, and the price of that depends on your hardware, your provider, and how much you use it. If you are running this locally, budget for real compute before you budget for convenience.

Third, agentic models can take action. They run commands and edit files. That is the whole point, and it is the whole risk. You want clear guardrails, small scopes, and review steps. You want to know what the agent is allowed to touch before it starts touching it.

Finally, do not confuse a model with a finished product. Kimi K3 is the brain. Kimi Code is the body. You need both to get the full experience, and you need to understand which parts you are actually using when you evaluate cost and privacy.

Pricing and cost notes

Moonshot has not published a single public price list that we can point you to here, and the GitHub repository focuses on the model and its technical setup. That is normal for open weight releases. The cost question changes a lot depending on how you run it.

If you run the model locally or on your own private servers, your main cost is compute. You need enough memory and enough acceleration to serve the weights at a useful speed, and the one million token window makes long context runs more demanding than short chat turns. If you serve it through a hosted provider, you pay for those providers on top of the model itself, and prices vary by region and by how you bundle the serving.

The practical rule is simple. Do not buy hardware on a guess. Prototype the workflow you care about, measure the tokens you actually use, and then decide whether the cost is worth it. An agentic coding agent that saves you an hour a day is a different business case than a model you only run a few times a week.

How it compares to the field

Kimi K3 sits in a crowded space. You will already see open coding agents like Kilo Code in your editor, long context models from major labs, and commercial agentic tools that bundle the model with the product for you.

The difference with Kimi K3 is that it is open weight, natively multimodal, and built with a long context attention design that is explicitly aimed at long work. That combination is the thing to evaluate. If your team already runs an editor based coding agent and is happy with it, Kimi K3 is not the only option on the table. If you want a long context, open weight agentic model you can run in a private environment, it is one of the clearer picks available right now.

Should you try it

Try it if you are a developer or a private team that wants an open weight agentic coding model with a real long context window, and you are ready to build or manage the compute. It fits best when you have concrete long work, a repository you control, and a need to keep your data on your own systems.

Pass if you want a small desktop app, if your work is mostly short chat turns, or if you do not want to deal with infrastructure at all. In that case a hosted coding agent or a shorter context model may be a better fit for your budget and your habits.

Either way, the official repository is the place to start. Read the technical setup, check the model files, and decide how much compute you can actually spare. Then run the workflow you care about before you decide the rest.

Visit the official Kimi K3 GitHub repository to see the model and its documentation.