Kimi

RoboCo can run delivery agents on Moonshot AI's Kimi K3, via the official kimi (kimi-code) CLI and a Kimi subscription rather than a metered API key — the same "subscription, not credits" posture as the Grok, Codex, and Gemini paths, authenticated by an OAuth device-code login instead of a saved key.

V1: delivery roles only

Kimi runs the developer/QA/documenter/PM delivery roles. It does not back the interactive Intake or Secretary chats — those stay on Anthropic even under the one-click Kimi mode, and an explicit per-agent pin to Kimi on either seat is refused at spawn. This is a deliberate V1 scope, not a bug.

Set it up once

Authenticate Kimi on the host with the official CLI's device-code login, then point RoboCo at the resulting directory:

bash
1kimi login                     # once, on the host — device-code OAuth, creates ~/.kimi-code

Then in .env:

bash
1ROBOCO_HOST_KIMI_DIR=/home/youruser/.kimi-code   # the REAL host ~/.kimi-code to mount in (defaults sensibly if unset)2# ROBOCO_KIMI_CLI_MODEL=kimi-code/k3             # or kimi-code/kimi-for-coding (K2.7) for a cheaper lever

Finally, on Settings → AI Providers, either click the Kimi mode button (whole fleet, delivery roles) or pin individual agents to a kimi-code/* model in Mix mode — see Choosing a provider for the full precedence ladder.

The mount is read-write and shared, on purpose

Unlike Codex's read-only directory mount or Gemini's copy-into-a-writable-local-dir, ROBOCO_HOST_KIMI_DIR is mounted read-write and shared across every Kimi agent plus the orchestrator itself. Moonshot rotates its refresh token with only a short reuse grace rather than making it truly reusable, so two independent per-container copies of one credential snapshot would eventually cross-invalidate each other's tokens. Every container instead redeems the SAME rotating chain, serialized by the CLI's own cross-process lock — so there's still no orchestrator refresh daemon, the CLI refreshes itself exactly like Gemini's does, just against shared rather than copied state.

Model: K3 by default, K2.7 as the cheaper lever

ROBOCO_KIMI_CLI_MODEL defaults to kimi-code/k3 — a 256k context window on mid subscription tiers, 1M on top tiers. Set it to kimi-code/kimi-for-coding (K2.7) to trade some capability for a cheaper run. Both aliases are namespaced under the login-managed kimi-code provider, so they resolve from whatever account kimi login authenticated — there's no separate per-model credential to manage.

Guardrails without a --disallowed-tools flag

Like Codex and Gemini, the Kimi CLI has no CLI-flag equivalent to Grok's --disallowed-tools. Tool scoping is expressed as a rendered deny-first permission-rules array in the CLI's own config, and the same bash-discipline guard hook installed on the Claude and Grok paths rides along here too.

No exit-code taxonomy — classified from the run's own structured error

Kimi's non-interactive mode has no dedicated exit-code taxonomy either, so RoboCo classifies a run's terminal state the same disciplined way it does for Codex: from a structured error field on the run's own event stream plus stderr — never the model's own echoed assistant/tool content, which could false-positive on ordinary on-topic prose. A detected rate-limit/quota condition exits 75 and a missing or expired credential exits 78, parking the Kimi provider exactly like a Codex or Gemini park; the background probe-and-resume loop revives it once the condition clears.

Usage and cost still show up

Usage capture sums each run's real input/output/cache-read/cache-write four-bucket split from the run's own session log into the same usage-tracking shape every other provider feeds. Kimi traffic lands on the same usage dashboard as Claude, Grok, Codex, and Gemini, priced from the captured session totals.

Next

llms.txt