<think>**Translating API integration title**</think> Kimi API Integrates Two Agent Protocols

<think>Planning technical markdown translation</think>

Kimi Now Directly Supports Codex and Claude Code

On September 2, Moonshot AI announced that the Kimi API now natively supports both the OpenAI Responses API and Anthropic Messages API formats. Users can now configure custom model providers in Codex and Claude Code to directly invoke models such as kimi-k3, kimi-k2.7-code-highspeed, kimi-k2.7-code, and kimi-k2.6, eliminating the need to maintain protocol conversion scripts or run an additional local proxy.

The Base URLs for the two API formats are:

• OpenAI Responses format: https://api.moonshot.cn/v1
• Anthropic Messages format: https://api.moonshot.cn/anthropic

On the surface, this update merely adds support for two additional API endpoints. In practice, however, it addresses one of the biggest sources of friction in today’s coding agent ecosystem: protocols.

In the past, when developers wanted to connect a third-party model to Codex or Claude Code, the model’s coding ability was only the first hurdle. They still had to deal with a series of compatibility issues involving request structures, streaming events, tool calls, message roles, error responses, and context continuation. Supporting the traditional OpenAI Chat Completions API did not mean a model could directly run Codex, which is built around the Responses API. Likewise, simply changing the path of a standard chat API did not make it compatible with the Anthropic Messages protocol used by Claude Code.

This time, Moonshot AI has bypassed the intermediate conversion layer and implemented both mainstream agent protocols directly on the Kimi API server. For developers, the most immediate change is that they can begin testing simply by changing the Base URL, API key, and model name.

Responses Is Not Just Chat Completions at a Different Path

When first integrating with the Responses API, many developers encounter errors such as field messages is required, missing input fields, or response structures that cannot be parsed. The underlying cause is usually not that the model is unavailable, but that the formats of two generations of OpenAI APIs have been mixed together.

The traditional Chat Completions API uses /v1/chat/completions, with a messages array as its core request field. The Responses API uses /v1/responses and places greater emphasis on input, instructions, response objects, and continuous state management. It is not simply the old API under a new name; it is a redesigned abstraction layer for tool calls, multimodal input, and agent workflows.

The distinction can be understood this way: Chat Completions is more like a series of independent chat requests, while the Responses API is more like an agent-oriented task container. The latter can carry different types of input and output items and is better suited to managing tool-call workflows. Codex uses this format precisely because a coding agent is not a single-turn question-answering tool. It needs to read files, execute commands, analyze results, and then determine what to do next.

Now that the Kimi API accepts the Responses format, Codex no longer needs to downgrade requests into traditional messages, and developers no longer need to maintain local mapping logic from input to messages. This is more specific than generic claims of “OpenAI compatibility”: many providers previously used that phrase to mean only Chat Completions support, while Responses compatibility capable of serving Codex directly sets a significantly higher bar.

According to the information currently disclosed by Moonshot AI, this endpoint supports text and image input, but not video for the time being. When video analysis is required, the company recommends first using FFmpeg to extract keyframes and then sending those images to the model. This limitation has little impact on code generation, but additional data preprocessing is still required for use cases such as video understanding, automated test recording analysis, and UI interaction replay.

Claude Code No Longer Needs an OpenAI Wrapper

The other newly added endpoint is for the Anthropic Messages API. Claude Code is designed around Anthropic’s own message format, content blocks, and tool-call workflow. In the past, connecting it to other models typically required deploying a local compatibility proxy to translate Anthropic requests into the OpenAI format and then repackage the model’s output back into Anthropic’s format.

Such proxies can work, but they present three practical problems.

First, they are expensive to maintain. After a Claude Code update, any change to event types, tool fields, or message ordering may require corresponding changes to the conversion layer. This may be acceptable for temporary testing by individual developers, but for long-term team use, the layer can easily become hidden infrastructure.

Second, they lengthen the debugging chain. A failed tool call could originate in Claude Code, the proxy conversion, the model API, or streaming-event parsing. The request shown in the logs may not even be the request ultimately received by the model.

Third, protocol conversion can lose semantics. OpenAI and Anthropic do not organize system instructions, content blocks, tool results, and streaming events in exactly the same way. Simple field mappings may be sufficient for basic Q&A, but they may not reliably support long-running, multi-step coding tasks.

The Kimi API now offers a direct Anthropic Messages endpoint, meaning this adaptation work is handled server-side. Claude Code users can connect directly to Kimi models through a custom provider without being forced to rely on a local proxy. This is especially valuable in enterprise environments: removing one persistent process also eliminates an additional set of versioning, port, logging, permission, and security-audit concerns.

However, “Messages API support” should not be interpreted as full coverage of every advanced capability in the Anthropic protocol. Whether Prompt Caching, extended thinking, token usage reporting, tool-call details, and specific streaming events are fully aligned should still be verified against Moonshot AI’s actual API documentation and test results. For production teams, being able to launch Claude Code is only the first step in compatibility testing. Continuous tool calls, long-context stability, and error recovery are more critical acceptance criteria.

The Real Competition Is for Access to Developer Tools

Competition among model providers is no longer limited to model leaderboards. For coding models, the products developers actually open every day may be Codex CLI or Claude Code in the terminal, or perhaps desktop clients and IDE extensions. Providers that can enter these tools at low cost are the ones most likely to gain real usage.

As a result, protocols are becoming a new distribution channel.

OpenAI Responses and Anthropic Messages have emerged as two de facto agent API standards. If a model provider offers only its own SDK, developers must customize their toolchains specifically for it. If it supports only the traditional Chat Completions API, it will struggle to fully support the latest generation of coding agents. By supporting both formats, Kimi is effectively plugging itself into the existing ecosystem rather than asking the ecosystem to rebuild around it.

This is a pragmatic choice.

Compared with building an entirely new code editor, integrating with Codex and Claude Code allows Kimi to take advantage of mature agent front ends, permission interactions, and tool-execution environments. Kimi handles model inference and API services, while the client handles the file system, terminal, and task orchestration, creating clearer boundaries between the two sides. Developers can also compare the output quality, speed, and cost of different Kimi models without changing their everyday tools.

The models included in this release cover both general-purpose and code-focused options. Judging by its name, kimi-k2.7-code-highspeed targets low-latency coding scenarios and is suitable for interactive tasks that require frequent file reads and short tool-call cycles. The standard code model is better suited to tasks that are less latency-sensitive but require complex reasoning or large-scale changes. The final experience still cannot be judged by single-generation quality alone, because a coding agent triggers multiple rounds of inference within a single task. Time to first token, output speed, and the reliability of tool parameters are all amplified in such workflows.

Practical Implications for Developers

This update is especially relevant to the following groups:

1. Developers already using Codex or Claude Code: They can add Kimi to their existing workflows without changing clients.
2. Teams seeking to benchmark coding models side by side: With a standardized front end and task environment, differences among models become easier to quantify, preventing the evaluation results from being distorted by different agent frameworks.
3. Enterprise users unwilling to maintain local protocol proxies: Reducing intermediary components simplifies deployment, auditing, and troubleshooting.
4. Teams that need stable access in mainland China’s network environment: Direct access to a domestic API is generally easier to control in terms of latency and availability than combining overseas endpoints with a local conversion layer.
5. Infrastructure teams building multi-model routing systems: Responses and Messages are gradually becoming protocols that gateways must support. Kimi’s native support reduces the need for model-specific adaptation.

However, if a team needs to switch frequently among GPT, Claude, Gemini, DeepSeek, and Kimi, connecting to a single provider’s dual-protocol API still does not solve the fragmentation of API keys, billing, and model routing. Such scenarios are better served by using an aggregation platform such as OpenAI Hub to manage models centrally, and then selecting the appropriate endpoint based on each tool’s protocol requirements. Native provider compatibility solves “how to connect to Kimi,” while an aggregation platform solves “how to manage models from multiple providers at once.” These are not problems at the same layer.

Several Integration Pitfalls Still Require Attention

First, do not mix the request bodies of the Responses API and Chat Completions. The former is organized around input and instructions, while the latter is organized around messages. Even if the path is configured correctly, using the wrong request format will still result in missing-field or parsing errors.

Second, the two Base URLs are not interchangeable. Codex uses https://api.moonshot.cn/v1, while Claude Code uses https://api.moonshot.cn/anthropic. Many clients automatically append the specific endpoint to the Base URL. Manually adding an extra path may therefore produce duplicate /v1 or /messages segments.

Third, the name shown in the client interface may not be the actual model name. Moonshot AI specifically notes that after the Codex desktop client is updated to ChatGPT, the model selector may display only “Custom,” even though the backend is still invoking the configured Kimi K3 or another Kimi model. When troubleshooting, check the configuration and request logs rather than relying solely on interface labels.

Finally, before a team formally migrates, it is best to run regression tests against real repositories rather than merely asking a few algorithm questions. At a minimum, testing should cover:

• Reading and modifying multiple files;
• Shell command execution and retries after failures;
• Context retention in large codebases;
• Image input and UI screenshot analysis;
• Streaming-output stability during long-running tasks;
• Tool-parameter formatting and permission confirmation;
• Recovery behavior after rate limiting, timeouts, and interruptions.

These tests are much closer to real production experience than simply comparing coding leaderboard scores.

Assessment: Not a Flashy Update, but Potentially More Useful Than Adding Another Model

This Kimi API update does not introduce new model capabilities. Instead, it completes the “last mile” required for Kimi models to enter mainstream agent tools. Ordinary chat users will barely notice it, but for developers who use Codex and Claude Code every day, it could directly eliminate an entire layer of proxies, conversion logic, and maintenance.

More importantly, it reflects a shift in the direction of competition among model APIs. Providers previously rushed to support OpenAI’s Chat Completions API. The new threshold is the ability to handle Responses, Anthropic Messages, and potentially even more native protocols at the same time. A compatible endpoint that merely returns text is no longer enough to support sophisticated agents.

Kimi’s decision to support both Codex and Claude Code is an engineering-focused but strategically sound product update. Whether it can truly become developers’ everyday coding model will still depend on long-task stability, tool-call accuracy, latency, and pricing. At the very least, however, Kimi has removed the most obstructive layer from the integration process.

References

• ITHome: Kimi API Now Natively Supports Codex and Claude Code — Information on Moonshot AI’s product update, API endpoints, supported models, and multimodal limitations.
• Tokligence Gateway Chinese Documentation — An overview of how endpoints such as Responses and Anthropic Messages are routed and converted in a multi-protocol gateway.