Run Kimi, Claude, GPT and Gemini in Kimi Code

Kimi Code already speaks the router's protocol

Use the one-command setup instead of copying TOML: curl -fsSL https://apitoken.sale/setup/connect.sh | bash. On Windows PowerShell use irm https://apitoken.sale/setup/connect.ps1 | iex. The command asks which provider to install and writes every model for that provider.

To use an apiToken.sale key in Kimi Code, run the one-command setup. It selects the provider-native protocol, writes a private config under ~/.config/apitoken/kimi-code, and adds one model alias for every model in the selected provider namespace. Start it with ~/.local/bin/apitoken-kimi-code so KIMI_CODE_HOME selects this configuration. Your existing ~/.kimi-code settings stay intact.

The config model is deliberately split in two. A provider entry owns the protocol, endpoint and credential; a model entry owns the alias you type, the wire ID sent to the server, and the context window the CLI budgets against. That split is what makes a multi-provider key comfortable here — the provider is written once, and adding Claude, GPT or Gemini later means adding one small table per model, not a new credential.

One behavior matters before you write anything: Kimi Code resolves credentials only from the config file. It checks the provider's api_key field, then the [providers.<name>.env] sub-table, and fails loudly at startup if neither is set. Exporting a variable in your shell does nothing — the CLI never falls back to shell environment variables for provider credentials.

See also: Run Kimi K3 and Kimi for Coding in Claude Code

Install the CLI and write every model

1. 01Install Kimi Code if it is not already installed.
2. 02Run curl -fsSL https://apitoken.sale/setup/connect.sh | bash. On Windows PowerShell run irm https://apitoken.sale/setup/connect.ps1 | iex. Select Kimi Code and the provider you want.
3. 03The setup writes every enabled model and restricts the config file to your account.

curl -fsSL https://apitoken.sale/setup/connect.sh | bash

# Windows PowerShell
irm https://apitoken.sale/setup/connect.ps1 | iex

Do not run /login for this setup. It starts the Kimi Code managed OAuth flow instead of the apiToken.sale provider.

Prove the route before the first real task

1. 01Start a session on the alias: kimi -m apitoken/k3.
2. 02Run /status and confirm the active model reads apitoken/k3 — it reports the session runtime state: version, model, working directory and permission mode.
3. 03Send one deterministic prompt: Reply with exactly: connected. A clean answer proves key, base_url and balance in a single round trip.
4. 04List what the key can actually reach: curl https://router.apitoken.sale/v1/models -H "Authorization: Bearer sk-pool-•••" — the catalog is scoped to the key, so it shows only models currently routable and priced for it.

If you edit config.toml while the TUI is open, run /reload. It applies provider and model changes without restarting the CLI; a new shell export would not, because the file is the only credential source.

One provider block, every model family

The alias (the [models."..."] key) is a local name only. What the router routes on is the model field, and it expects the unified catalog's namespaced IDs — kimi/k3, openai/gpt-5.6-terra, google/gemini-3.6-flash. Because the provider already holds the endpoint and key, each additional model is three lines:

[models."apitoken/kimi-for-coding"]
provider = "apitoken"
model = "kimi/kimi-for-coding"
max_context_size = 262144

[models."apitoken/gpt-terra"]
provider = "apitoken"
model = "openai/gpt-5.6-terra"
max_context_size = 400000   # review against the model page

[models."apitoken/gemini-flash"]
provider = "apitoken"
model = "google/gemini-3.6-flash"
max_context_size = 1048576  # review against the model page

• max_context_size is required per alias. The CLI uses it for overflow checks and for deciding when automatic compaction fires, so copy the model's reviewed window — 1048576 for K3's 1M mode, 262144 for Kimi for Coding — rather than guessing.
• Kimi Code auto-detects capabilities such as thinking, vision and tool use from known model name prefixes. For a namespaced gateway ID it may not recognize, declare them explicitly, e.g. capabilities = ["thinking", "tool_use"]; declared tags are unioned with the detected ones.
• Switch between declared aliases mid-session with /model — no restart and no config edit.
• All providers stream by default; if a gateway ever returns reasoning under a non-standard field name, the model alias accepts a reasoning_key override.

Reviewed context windows and per-model prices →

What these sessions cost on prepaid balance

Figures are per 1M tokens. Kimi caching is automatic, terminal usage reports which input was served from cache, and reasoning tokens bill as output — they are not a separate token class. apiToken.sale applies a flat 50% B2C discount to official rates, so a Kimi Code session costs exactly the tokens it consumed at half the official spend; an idle week costs nothing.

The balance is shared across every alias on the key, so a Claude-heavy day and a Kimi-heavy day draw from the same pool. The practical guardrails are a lifetime spending limit and an expiration date per key, plus settled usage in the dashboard. A 402 mid-session means the pool is empty — top up and the next request succeeds; retrying will not.

Failures that are configuration, not model quality

• Startup fails before any request — the provider has no credential. Write api_key (or the [providers.apitoken.env] sub-table) in config.toml; a shell export is never read.
• 401 on the first turn — the key is wrong or revoked, or base_url lost its /v1 suffix. Reproduce with the curl catalog call to isolate which half is broken.
• 404 for a model you just declared — that ID is not in the key-scoped catalog. Trust GET /v1/models over memory, and re-check it before pinning an alias into a long-lived config.
• Compaction fires far earlier than expected — max_context_size is declared below the model's real window, so the CLI thinks it is out of room.
• The key sits in plain text — that is by design for this provider type, which is why chmod 600 is part of the setup and why the file belongs outside any synced or committed directory.

Frequently asked questions

Related guides