Last updated August 7, 2026

Codex Kimi: Use Kimi K3 & K2.7 in Codex

This guide shows you how to add Kimi models — Kimi K3 and the K2.7 Coding entries — to the Codex model picker with Codex Router. Kimi is special because it offers two completely separate authentication and billing paths: the Kimi Code CLI OAuth session and the Kimi Platform API key. Both are supported, and both can coexist.

KimiOAuthAPI key

What you can add

Picker label	Model ID	Authentication
K2.7 Coding Highspeed (OAuth)	`kimi-oauth/kimi-for-coding-highspeed`	Existing Kimi Code CLI OAuth session
K2.7 Coding (OAuth)	`kimi-oauth/kimi-for-coding`	Existing Kimi Code CLI OAuth session
Kimi K3 (OAuth)	`kimi-oauth/k3`	Existing Kimi Code CLI OAuth session
Kimi K3 (API)	`kimi-api/kimi-k3`	Separately billed Kimi Platform API key

Kimi K2.7 Code is also available through ollama-cloud/kimi-k2.7-code (an Ollama Cloud account), which bills separately.

Choose your authentication

Kimi Code OAuth reuses the official Kimi Code CLI session. Nothing extra is stored: the router reads the credential under $KIMI_CODE_HOME or ~/.kimi-code and refreshes it under a cross-process lock. Use this if you already use Kimi Code.
Kimi Platform API uses a separately billed Kimi Platform API key entered through a hidden prompt. Use this if you want Kimi K3 billed to a developer platform account.

The two Kimi entries intentionally coexist: OAuth and Platform are separate account and billing systems, and the router never shares a credential between them. Do not copy an OAuth token into an API-key file or an environment variable.

Enable Kimi OAuth

Install the official Kimi Code CLI if you have not already, then sign in:

kimi login

Then enable the OAuth provider in the router:

./bin/model-router codex providers enable kimi-oauth
./bin/model-router codex doctor

Guided setup offers to run kimi login for you when the CLI exists, so if you install through the guided wizard you may not need the manual step.

Enable Kimi API

./bin/model-router codex provider-key kimi-api set
./bin/model-router codex providers enable kimi-api

The hidden prompt disables terminal echo. On Windows, use ./codex-router.ps1 codex provider-key kimi-api set.

Verify the integration

./bin/model-router codex doctor
./bin/model-router codex providers

Both kimi-oauth and kimi-api should report SHOW and ready when connected. Then fully quit Codex, reopen it, create a new task, and check the picker for Kimi K3 (and the K2.7 entries). For a live check of the OAuth route:

./bin/test-model 'kimi-oauth/k3' --live --yes

How Kimi requests behave

Kimi K3 API requests select the kimi-k3 upstream model and force maximum reasoning. Kimi Code OAuth retains its own refresh and device-identity behavior, so long-running sessions stay fresh without re-login. Native GPT models and your ChatGPT login are unaffected — the router keeps the built-in OpenAI provider intact.

Common pitfalls

OAuth is not an API key. If kimi-oauth shows needs-sign-in, run kimi login again. If kimi-api shows needs-key, set the platform key. They cannot replace each other.
Keys never go in chat. The router prompts invisibly for API keys and reports only presence and source in diagnostics.
Provider policy risk. Moonshot AI may restrict or block proxy traffic. Routing Kimi through a third-party router is at your own risk (UAYOR).
Windows users: Kimi OAuth works on Windows, but if you use Grok OAuth there, see the Smart App Control caveat.