The Kimi Agent SDK keeps the CLI in the loop, and that is the whole design

A set of thin clients over a CLI agent runtime

Kimi Agent SDK is described as a set of multi-language libraries that expose the Kimi Code, the Kimi CLI, agent runtime in your applications. The README says the intent plainly: use it to build products, automations and custom tooling while keeping the CLI as the execution engine.

That last clause is the design decision everything else follows from. The SDKs are described as thin, language-native clients that reuse the same Kimi CLI configuration, tools, skills and MCP servers. They stream responses in real time, surface approvals and tool calls, and let you orchestrate sessions programmatically.

So this is not a reimplementation of the agent in three languages. It is a way to drive an existing agent process from code, with the same configuration files, the same tool definitions and the same MCP server connections that a person at a terminal would get.

The practical consequence is that there is one runtime and three ways to talk to it. Anything that requires the agent to behave exactly as it does for an interactive user, with the same tools and the same permission model, gets that for free. Anything that requires a different agent loop, or a different sandbox, or a deployment with no CLI at all, does not.

The primary language of the repository is listed as TypeScript, but that is the implementation of the Node client, not a preference, since the SDK ships for Go, Node.js and Python. The licence is Apache 2.0, with a LICENSE file and a NOTICE file at the top level.

Three languages, three package names, one runtime

The available SDKs table lists the three implementations and where they live in the repository, and all three are marked Available.

| Language | Package | Status | |----------|---------|--------| | Go | [go/](./go) | Available | | Node.js | [node/agent_sdk/](./node/agent_sdk/) | Available | | Python | [python/](./python/) | Available |

The published package names differ from the repository directory names, which is worth noting before you paste an import path. The Go module is github.com/MoonshotAI/kimi-agent-sdk with the go subdirectory, the npm package is scoped as @moonshot-ai/kimi-agent-sdk, and the PyPI project is kimi-agent-sdk.

The repository layout confirms the structure. There are go/, node/, python/ and guides/ directories at the top level, plus examples/, scripts/, .github/ and .vscode/. The examples directory is split the same way, with examples/go/ and examples/python/.

The version badges at the top of the README are per language and point at the Go package on pkg.go.dev, the Node package on npm and the Python project on PyPI. The Go badge filters on tags prefixed go-v, which is how the three SDKs are versioned independently in one repository.

Three languages means three maintenance surfaces rather than one, and the repository does not describe a policy for keeping them in step. That is a question worth asking before you standardise on it internally.

Installing any of the three takes one command

The installation section gives one command per language, and each is followed by a link to that language's quick start.

For Go, the module path and the subdirectory are both in the import.

# Go
go get github.com/MoonshotAI/kimi-agent-sdk/go

The Go quick start lives in guides/go/quickstart.md.

For Node.js, the package is scoped under the moonshot-ai organisation, and the quick start is in the package's own README rather than in the guides directory, which is a small inconsistency worth knowing when you are looking for the starting point.

# Node.js
npm install @moonshot-ai/kimi-agent-sdk

For Python, the PyPI name is unprefixed, and the quick start is in guides/python/quickstart.md.

# Python
pip install kimi-agent-sdk

What none of the three commands tell you is how to obtain or configure the Kimi CLI itself, which the SDK is driving. The README assumes you already have the CLI, and the fact that the SDK reuses the CLI configuration, tools, skills and MCP servers implies that the CLI is installed and configured separately on the machine or in the container where your program runs. That is the deployment requirement to plan around, and it is not documented in the installation section.

What the SDK actually exposes: sessions, tools and approvals

The Overview section lists four things the interface is for, and they describe the surface an application touches.

Build custom applications, integrating Kimi Agent into your own tools and workflows. Automate tasks, scripting complex multi-turn conversations. Extend capabilities, registering custom tools that the model can call. And handle approvals, responding programmatically to permission requests.

That last item is the one that distinguishes an SDK from a chat wrapper. In an interactive CLI session, a human approves a tool call. In a product, nobody is watching, so the approval has to be answered by code, and the SDK surfaces those requests as something your program can respond to. If you are building an unattended automation, that is the part that makes the difference between the tool working and the tool hanging.

Registering custom tools is the other half. The SDK reuses the CLI's tools and skills, and the extension point lets you add your own that the model can call. So the tool surface is the union of what the CLI already provides and what your application adds.

The README also says the clients stream responses in real time, and that they let you orchestrate sessions programmatically. So the shape of the API is a session you create, a stream of events you consume, tool calls you can answer, and approvals you either grant or refuse.

The examples show two different things you can build

The examples section lists four sample programs, and they are worth reading as a description of what the SDK is for.

For Go there is ralph-loop and rumor-buster. For Python there is customized-tools and kaos, and the README adds a parenthetical that KAOS means sandbox backends, running the same agent tools in BoxLite, E2B, or Sprites.

The Python customized-tools example is the direct counterpart to the register custom tools capability. The kaos example is the more interesting one for anyone deploying this, because it is about where the agent's tools actually execute. Running the same tools in BoxLite, E2B or Sprites means the SDK's tool surface can be pointed at different sandbox providers, which is the question every team deploying an agent has to answer: what are the tools allowed to touch, and where.

The ralph-loop example, by its name, is about a loop that runs repeatedly, which is a task shape the Overview calls scripting complex multi-turn conversations. And rumor-buster suggests a multi-source investigation pattern where the agent gathers and checks claims.

None of these examples are described in detail in the README, and each links to its own directory, so the practical approach for anyone evaluating this is to read the example in the language you would use. The two languages with examples are Go and Python, so if you are on Node.js the closest equivalent is not in the tree and you would start from the Node quick start instead.

What the SDK deliberately does not do

The scope statement is short and it is worth reading it as a constraint rather than a summary.

The SDKs are thin, language-native clients. They reuse the same Kimi CLI configuration, tools, skills and MCP servers. The CLI is the execution engine. Every one of those phrases says the same thing, which is that the SDK owns the interface and not the runtime.

That has consequences for the cases where you would not want it. If your product needs a deployment with no CLI binary present, this does not serve. If you need to swap the agent's underlying model or its tool implementations, the fact that tools, skills and MCP servers come from the CLI configuration means the extension points are the ones the CLI offers rather than a new set. And if you need the agent loop itself to behave differently under different conditions, you are constrained by the CLI's loop, because the SDK orchestrates sessions rather than defining them.

The benefit of the same choice is equally concrete. There is one runtime, one set of tools and one configuration format, and a person debugging an issue at a terminal sees the same behaviour your product sees. For an organisation already running the Kimi CLI interactively, that consistency is worth more than the freedom of a bespoke runtime.

The approvals point deserves repeating, because it is where thin wrappers often fall down. Here the approval request is something the SDK surfaces, so an unattended run can be given a policy, for example a fixed rule that approves reads and refuses writes, without reimplementing the permission model.

Maintenance, versioning and the open question of the three clients

The repository is not archived and the last push was on 2026-05-29, and there are no GitHub releases. Version information for the three SDKs comes from the package registries rather than from a release list, and the Go badge in the README filters on tags prefixed go-v, so the Go client is tagged separately from the others.

That last detail tells you the three clients are versioned independently inside one repository, which follows from the fact that they are published to three different registries with three different naming schemes. A team standardising on one of them will be tracking a version number that moves on its own schedule.

The repository also has a NOTICE file next to the LICENSE file, which is the Apache 2.0 convention for third party attributions, and there is a .github/ directory, a .vscode/ directory and a scripts/ directory. The guides directory holds the Go and Python quick starts.

What the README does not document is worth listing, because these are the questions an integrator will have. There is no statement of which Kimi CLI version a given SDK version expects, and no note about the relationship between the SDK and the CLI's own version numbering. There is no guidance on how to configure the CLI that the SDK reuses, since the installation section stops at the package install. And there is no compatibility matrix across the three languages, so whether the three clients expose exactly the same surface is something you would have to check by reading the source of each.

For a project whose whole premise is reuse of the CLI, that gap between the two halves is the thing to close first.

Editorial conclusion

Adopt the Kimi Agent SDK if you want to build products or automations on top of the Kimi CLI agent runtime and you want the CLI to remain the execution engine rather than reimplementing its tool and skill handling. Do not adopt it if you need a self-contained agent runtime with no CLI dependency, or if the approval and tool calling surface is not what your product needs. Before you commit, read the quick start for your language in the guides/ and node directories, confirm the CLI version you pin against the SDK version, and check the examples for your language to see how sessions are driven.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MoonshotAI/kimi-agent-sdk on GitHub
4. README