Kimi K3

Overview

Kimi K3 is a large open-weight model from Moonshot AI. It is built for long-context reasoning and for agentic tasks, which means jobs where the model plans, calls tools, reads results and keeps going over many steps. Teams look at models like Kimi K3 when they want to run an agent on their own infrastructure, with long documents or long tool traces in the context.

This article explains what Kimi K3 is, how the Kimi line developed, and how a large sparse model built for agent work operates. It includes a worked example, a comparison with other models, and a section on how a language model relates to tabular foundation models that learn directly from raw tables. Sizes, context windows and licence terms differ between releases, so confirm them on the official model card.

What it is

Kimi K3 is a large language model released with open weights. Open weights means the trained parameters can be downloaded and run privately, under a licence that you should read carefully.

Three ideas in one sentence

It is large, so it has broad capacity. It is tuned for long context, so it can keep a lot of material in view. It is tuned for agent work, so it is good at choosing tools, reading their results and continuing a plan.

What "agentic" means

An agentic task is one where the model acts in a loop.

1. Read the goal and the current state.
2. Decide the next step, which may be a tool call.
3. Run the tool and read the result.
4. Update the plan.
5. Repeat until done, or ask a person for help.

Examples include researching a topic across many pages, fixing a bug across several files, running a data analysis with code, or filling a form after checking sources. See ReAct loop, plan and execute and multi-agent systems.

What "long context" means

Context is the text the model can see at once. Long context means it can hold very large inputs, such as many documents, a big code base or a long chain of earlier tool outputs. This is vital for agents, because every step adds to the history.

Typical strengths

• Long-document reading and question answering.
• Multi-step tool use.
• Coding and debugging across files.
• Reasoning on hard problems in a thinking mode, where offered.
• Structured output for programs.

Typical delivery

• Downloadable weights for self-hosting, subject to the licence.
• Hosted APIs from the developer or from third-party providers.
• Quantised builds from the community for smaller setups.

Where it came from

Moonshot AI is a Chinese AI company that launched the Kimi assistant, which became known early for handling very long inputs. The company later published open-weight models under the Kimi name.

A short timeline in general terms

• 2023 and 2024: the Kimi assistant gains attention for long-context handling.
• 2025: the K2 generation arrives as a very large mixture-of-experts model with open weights, aimed at agentic work, and it uses a custom optimiser called Muon in a stabilised form for training at scale.
• Later updates in 2025 add thinking variants and longer context.
• Kimi K3 continues the line as a large open-weight model for long-context reasoning and agents.

Ideas the line is known for

• Very large sparse mixture-of-experts design, with a small share of parameters active per token. See mixture of experts.
• A focus on agentic training, with many synthetic tool-use tasks and rewards from checkable outcomes.
• Use of training methods that aim for stability at huge scale.
• Strong attention to long context, which suits agent histories.

Where it fits in the field

It sits beside other open-weight families such as DeepSeek V4.1, Qwen 4 and GLM 5.3. Each has a slightly different emphasis, and all of them make private hosting of strong models possible.

How it works

Follow a prompt through a large sparse agent-oriented model. Each step has an everyday analogy.

Step 1: Tokenisation

Text is split into tokens by a learned tokenizer. See BPE and SentencePiece. Analogy: a long letter is cut into small labelled index cards.

Step 2: Embedding and position

Each token becomes a vector. Position information tells the model the order. For long context, position schemes are often stretched or adjusted so the model still understands order across very long inputs. Analogy: page numbers in a very long book, which must stay clear even at page ten thousand.

Step 3: Attention over a long history

Each layer lets tokens look back at earlier tokens. Long context makes this costly, so models use tricks to save memory and time.

• Grouped or compressed key-value storage, so the KV cache is smaller.
• Efficient kernels such as FlashAttention.
• Sometimes mixed attention patterns, with some layers that look at everything and others that look at a local window.

Analogy: when reading a long report, you read the recent pages closely and skim older ones, but you keep an index so you can jump back when needed.

Step 4: Sparse expert layers

A router picks a few experts for each token. Most parameters sit idle for any given token. That is how a model with a huge total size can still serve at a reasonable cost per token. Analogy: a large hospital where each patient sees only the few relevant specialists.

Step 5: Predicting the next token or the next action

The model predicts the next token. In an agent loop, that token stream may form a tool call, such as a function name and arguments in JSON. The host program runs the tool and returns the result as new context. See function calling and MCP.

Step 6: Thinking

In thinking variants, the model writes reasoning first. In agent work it may also reason between tool calls, deciding what the last result means and what to do next.

How an agentic model is trained

1. Pre-training on a very large corpus with next-token prediction, on text, code and more.
2. Long-context training to extend the usable window.
3. Supervised fine-tuning on instruction and tool-use examples. See SFT.
4. Large-scale synthetic tasks where the model practises using tools in simulated environments, with checkers that score the outcome.
5. Reinforcement learning to improve success rates. See reinforcement learning.
6. Preference and safety tuning.

The idea is to teach the habit of acting, checking and correcting, not just answering once.

Why agents stress long context

An agent that runs fifty steps might add a tool call and a long result at every step. Soon the history has tens of thousands of tokens. Without strong long-context behaviour, the agent forgets its own plan or repeats work. See agent memory and long-running tasks for ways to manage this.

Key concepts and terms

A worked example

This example shows a small agent loop with one tool and a context budget. The host is a placeholder, and the tool is a stub.

A tool-using loop

import json
import os
from openai import OpenAI

client = OpenAI(base_url="https://inference.example.internal/v1",
                api_key=os.environ.get("EXAMPLE_KEY", "x"))

tools = [{
    "type": "function",
    "function": {
        "name": "run_sql",
        "description": "Run a read-only SQL query on the analytics database.",
        "parameters": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"],
        },
    },
}]

def run_sql(query: str) -> str:
    # Stub: in real use, connect to a read-only replica with a row limit.
    if not query.strip().lower().startswith("select"):
        return "error: only SELECT is allowed"
    return json.dumps([{"region": "north", "orders": 120}, {"region": "south", "orders": 95}])

messages = [
    {"role": "system", "content": "You are a careful analyst. Use tools. Stop when you can answer."},
    {"role": "user", "content": "Which region had more orders last month, and by how much?"},
]

for step in range(6):  # hard cap on steps
    r = client.chat.completions.create(model="kimi-k3-placeholder", messages=messages,
                                       tools=tools, temperature=0.2)
    msg = r.choices[0].message
    messages.append(msg)
    if not msg.tool_calls:
        print(msg.content)
        break
    for call in msg.tool_calls:
        args = json.loads(call.function.arguments)
        result = run_sql(**args)
        messages.append({"role": "tool", "tool_call_id": call.id, "content": result})

Notice the safety features: a step cap, a read-only tool and a check inside the tool. Agents should never be trusted with open-ended power.

A context budget walk-through

Suppose each step adds 300 tokens of reasoning and a tool result of 1,500 tokens. After 20 steps the history holds about 36,000 tokens. After 60 steps it holds about 108,000. If the window is limited, you need a plan: summarise old steps, drop bulky raw results and keep only the key facts. Doing this early keeps cost and latency down, since every new step re-reads the whole history, or at least pays for storing it in the KV cache.

A needle-in-a-haystack check

To test long-context recall on your own data:

1. Take a long document set of known length.
2. Insert a short unique fact at a chosen depth.
3. Ask a question that depends on that fact.
4. Repeat at several depths and lengths.
5. Plot accuracy by depth and length.

If accuracy falls in the middle or at the far end, shorten the input or use retrieval.

Serving outline

Large sparse models are served with engines that support expert parallelism, such as vLLM and SGLang. A typical plan has several GPUs on one or more nodes, with fast interconnect. See tensor parallelism, NCCL and NVIDIA H200 for the hardware side.

A failure walk-through

Agents fail in recognisable ways. Knowing them helps you design checks.

Analogy: a new employee with a checklist, a manager who signs off big decisions and a locked cabinet for dangerous tools. Good agent design copies that setup.

Measuring success across many runs

A single run proves little, because agent behaviour varies from run to run. A better method is:

1. Define 30 or more tasks with a clear pass or fail check.
2. Run each task several times with the same settings.
3. Record the pass rate, the average steps and the average tokens.
4. Look at the failed runs, not only the average.
5. Change one thing, then repeat.

Pass rate alone can hide cost. A model that passes slightly more often but uses three times the tokens may be the worse choice.

Position effects in long inputs

Models often recall the start and end of a long input better than the middle. Plan for this.

• Put instructions and key facts near the start or the end.
• Repeat critical constraints just before the question.
• Use short headers inside long documents so the model can find sections.
• Prefer retrieval of the few relevant passages over sending every passage.

Strengths and limitations

Strengths

• Large capacity from a sparse design.
• Long-context handling that suits big documents and agent histories.
• Strong tool use and multi-step behaviour.
• Open weights allow private hosting and audit.
• Active community around serving and quantisation.
• Useful teacher model for distilling smaller agent models.

Limitations

• Heavy hardware needs, since all experts must sit in memory.
• Long contexts are expensive in time and memory.
• Agent loops can go wrong: repeated actions, wrong tool choice, drifting from the goal.
• Can hallucinate, including inventing tool results if the host does not enforce structure.
• Safety behaviour needs your own testing, especially with powerful tools.
• Licence terms must be read before commercial use.
• Quality at the far end of the window may be lower than at the start.

Where it is not the best fit

• Small devices or tight budgets, where a small dense model is easier.
• Pure numeric prediction on tables, where tabular models are better.
• One-shot short questions, where a smaller model is cheaper.

How it compares with alternatives

Agent frameworks that can drive a model like this

Most agent frameworks accept any model behind an OpenAI-compatible endpoint, so a self-hosted open-weight model can often be plugged in. Examples of frameworks include LangGraph, CrewAI, smolagents and PydanticAI. Test tool-call formatting carefully, because small differences in format can break an agent.

How to choose

1. Write the tasks your agent must do and the tools it needs.
2. Build a test harness with scripted tools and scoring.
3. Run several models through the same harness.
4. Compare success rate, steps used, cost and time.
5. Add safety tests: bad inputs, tool failures, hostile text.
6. Pick the model with the best success per unit of cost, not the highest raw score.

Role in tabular foundation models

Kimi K3 reads text, code and tool outputs. Tabular foundation models read tables. In practice the first often orchestrates the second.

What a tabular foundation model does

Models such as TabPFN, TabICL and TabSTAR are pre-trained on many tables, often synthetic ones generated from random causal structures. At use time you supply labelled rows as context and rows to predict, and the model returns predictions in one forward pass. That is in-context learning on tabular data, with no training on your table. The design is described at /model/architecture, and the supporting research at /model/research.

Their special traits:

• They treat rows and columns as structure, not as a flat token stream.
• They handle numbers, categories, dates and text together.
• They treat missing values as part of the input.
• They stay useful when column names are missing or meaningless.
• They are built so row order and column order do not change the answer. See axial attention.
• They support tasks such as imputation, anomaly detection and sector or semantic classification. See masked cell modeling, imputation networks, anomaly detection and semantic sector heads.

Where Kimi K3 fits: the agent that uses a table model

A long-context agent model is well suited to the planner role in a data workflow.

• It reads a long data dictionary, many schema files or a long report in a single context.
• It writes SQL and Python to explore and clean data, runs them through tools, and reads the results.
• It decides when to call a tabular model as a tool for prediction, imputation or anomaly scoring, using function calling or MCP.
• It reads the tool's output, checks it against sanity rules and decides the next step.
• It writes a final report, with caveats and a list of what a person should review.

A concrete flow

1. The user uploads a transaction table and asks for unusual customers.
2. The agent calls a profiling tool and reads column types, missing rates and ranges.
3. It writes cleaning code, runs it in a sandbox and checks the result.
4. It calls a tabular anomaly model with the clean table.
5. It receives scores per row, picks the top rows, and fetches extra context with SQL.
6. It writes a short summary with evidence per row.
7. A person approves any follow-up action. See human in the loop.

What stays with the tabular model

• Cell-level prediction and imputation.
• Calibrated scores for anomalies.
• Handling of mixed types and missing values.
• Speed on large numbers of rows.
• Repeatable results.

What stays with the language model

• Reading free-text documentation.
• Proposing column meanings and sector labels from names and samples.
• Writing code and queries.
• Explaining results in plain language.
• Choosing which tool to run next.

Long context is not a replacement for a table model

It may be tempting to paste a whole table into a long context and ask for predictions. Do not rely on that.

• Even a very long window holds only a modest number of rows once numbers are tokenised.
• Cost rises with every row, and every step re-reads the context.
• Numeric precision suffers.
• Row order can change the answer.
• Results are hard to repeat.

Use the window for documentation, schemas, tool traces and summaries, and use tabular models and databases for the numbers.

Continual learning

Tabular systems that must adapt to new data can use EWC, experience replay and related methods to avoid forgetting. Agent systems adapt more often through memory stores, new tool descriptions and adapters. See agent memory. A regression set protects both kinds of system.

Practical guidance and best practices

Agent design

• Give each tool a clear name, a short description and a strict schema.
• Cap the number of steps and the total tokens per task.
• Make tools safe by default: read-only, row-limited, time-limited.
• Return short, structured tool results, not raw dumps.
• Ask the model to state its plan, then check it against the result at each step.
• Add a human approval step before any irreversible action.

Context management

1. Keep the system prompt short and stable.
2. Summarise old steps after a fixed number of turns.
3. Store large results outside the context and pass only IDs and key facts.
4. Put the most important instructions at the start and again near the end.
5. Test recall at the lengths you really use.

Serving

• Plan memory for weights plus a large KV cache.
• Use expert parallelism and a fast interconnect.
• Enable prefix caching for long shared prompts.
• Monitor queue length, time to first token and tokens per second.
• Use quantised builds only after quality tests. See AWQ and GPTQ.

Evaluation

• Score full task success, not only single answers.
• Track steps, tokens and cost per task.
• Include failure tests: tool errors, empty results, hostile text.
• Use evals and tracing to find where runs go wrong.

Safety

• Treat all tool output and retrieved text as untrusted. See prompt injection defense.
• Use guardrails on inputs, outputs and actions.
• Give the agent the least permission it needs.
• Log every tool call for audit.

Fine-tuning

Most teams do not need to fine-tune a model of this size. If you do, use adapters such as LoRA, keep a held-out set and respect the licence. Smaller models fine-tuned on filtered agent traces from a larger one are often a cheaper route.

A launch checklist for an agent

1. Write the allowed tools and their permissions on one page.
2. Write what the agent must never do.
3. Build a test set of tasks and a scoring script.
4. Run a hostile-input test, such as a document that tells the agent to ignore its rules.
5. Set budgets for steps, tokens and money.
6. Add logging and an alert for unusual tool use.
7. Start with a shadow mode where the agent proposes and a person acts.
8. Move to supervised action, then to wider autonomy only if the data supports it.

Working with data tools

• Prefer a read-only replica for exploration.
• Add row limits and timeouts to every query tool.
• Return summaries and samples, not full tables.
• Give the agent a data dictionary in the system prompt or via retrieval.
• Mask personal data before it reaches the model.

Common mistakes

• Giving an agent broad write access with no review.
• Having no cap on steps or tokens.
• Letting raw tool dumps flood the context.
• Trusting a model's claim that a tool succeeded without reading the result.
• Treating a long window as a place to dump everything.
• Testing recall only at short lengths.
• Pasting whole tables into the context and expecting accurate statistics.
• Estimating hardware from active parameters instead of total parameters.
• Skipping a sandbox for generated code.
• Judging an agent by one lucky run instead of many.
• Ignoring licence terms before commercial use.
• Changing the model and the tool descriptions at the same time, so you cannot tell what caused a change.

Frequently asked questions

What is Kimi K3?

Kimi K3 is a large open-weight model from Moonshot AI. It is built for long-context reasoning and for agentic tasks, where the model plans, calls tools and continues over many steps. It is usually run on self-hosted infrastructure or through hosted APIs.

What does agentic mean for a language model?

It means the model works in a loop rather than answering once. It reads the goal, chooses a tool call, reads the result, updates its plan and repeats until the task is done or a person must step in. Good agentic models are trained to choose tools well and to correct themselves.

Why does long context matter for agents?

Each step of an agent adds reasoning and tool output to the history. After many steps the history is long. A model with strong long-context behaviour keeps track of the plan and earlier results instead of forgetting them or repeating work.

Is Kimi K3 open source?

It is open-weight, which means the parameters can be downloaded under a licence. That is not always the same as fully open source, since training data and some code may not be published. Read the licence for commercial use and redistribution.

What hardware does it need?

A large sparse model needs enough memory to hold all of its experts, so total parameter count drives the need, not active parameters. That usually means several high-memory GPUs and a fast interconnect, plus room for a large KV cache. Check the model card and test with your real prompt lengths.

Can Kimi K3 analyse tabular data?

It can read schemas, write SQL and Python, run them through tools and explain the results. It is not the right tool for accurate prediction from many columns. Use a tabular foundation model or gradient boosting for prediction and let Kimi K3 plan and report.

How does it relate to tabular foundation models?

Tabular foundation models are pre-trained on many tables and predict directly from rows and columns using in-context learning, handling mixed types and missing values. Kimi K3 is a language model, so it works at the level of text, code and tool calls. In an agent, it decides when to call the tabular model and how to interpret what comes back.

Can I put a whole spreadsheet in the context window?

A large window can hold a fair amount of text, but a table pasted as text uses many tokens, loses numeric precision and costs more with every row. It is better to pass the schema and a sample, and to let tools and tabular models work on the full data.

How do I make agent runs safe?

Limit steps and tokens, give tools minimal permissions, make database tools read-only, sandbox generated code, treat tool output as untrusted and keep a human approval step for irreversible actions. Log every call and review failures regularly.

Should I fine-tune it?

Usually not at first. Better prompts, tool descriptions, retrieval and context management give most of the gains. If you do need to tune, use adapters, keep a held-out test set and check the licence. Distilling agent traces into a smaller model is another option.

Glossary

• Agent: a program in which a model plans and calls tools.
• Agentic: relating to model behaviour in a plan, act and observe loop.
• Context compaction: summarising old history to save space.
• Context window: the number of tokens a model can see at once.
• Expert: one feed-forward block in a sparse layer.
• Expert parallelism: spreading experts across GPUs.
• Function calling: a model output that names a tool and arguments.
• KV cache: stored keys and values for earlier tokens.
• Long context: a large context window.
• MCP: a protocol for connecting models to tools and data.
• Observation: a tool result fed back to the model.
• Open-weight: weights available for download under a licence.
• Prefix caching: reusing computed state for a shared prompt start.
• Router: the component that picks experts.
• Sandbox: an isolated place to run untrusted code.
• Thinking mode: reasoning before answering or acting.
• Tool call: a request from the model to run a function.
• Verifiable reward: a reward computed by a checker.

Summary

Kimi K3 is a large open-weight model from Moonshot AI, built for long-context reasoning and agentic work. Its sparse design gives high capacity at a reasonable per-token cost, and its tool-use training makes it suitable as the planner in multi-step workflows. The costs are heavy memory needs, expensive long contexts and the extra care that agents require.

For tabular data, it works best as the orchestrator. It reads long documentation, writes and runs data code, decides when to call tabular foundation models for prediction, imputation or anomaly scoring, and explains the results. The cell-level work belongs to models described at /model/research, /model/architecture and /model/benchmarks. Cap steps, limit permissions, sandbox code, test recall at real lengths and keep humans in the loop.

Related

It belongs to Open-weight models in my stack, under LLMs, retrieval, and evaluation. Others in the same group: