AI Coding Agents
Guides
How to use Kimi K2 in Factory
July 1, 2026 - 2 minute read
Kimi K2 is a family of open-weight language models from Moonshot AI. Factory hosts Kimi models and handles inference and billing, so using a hosted model does not require your own GPU service or provider key.
The current model catalog lists Kimi K2.5 as deprecated but still available for now. It also lists Kimi K3. K2.7 Code and K2.6 are absent from the current catalog, so do not base a new automation on those older IDs.
Selecting Kimi K2 in a Droid
In an interactive CLI session, run /model and choose Kimi K2.5 if it is available under your organization's model policy. The Droid CLI reference documents model selection and execution flags.
For non-interactive runs, pass the model ID with -m:
bash
droid exec -m kimi-k2.5 -r high "review the date helpers and suggest regression tests without editing files"Kimi K2.5 accepts off and high reasoning, with high as the default. The example explicitly selects high and requests a read-only review. Approve editing and command execution separately when moving from a review to implementation.
Cost and the credit multiplier
The catalog lists Kimi K2.5 at a 0.25x credit multiplier. This is a billing multiplier, not a fixed price for completing a task. Check the current catalog before a run and include retries and validation when comparing total usage.
Because K2.5 is deprecated, an existing workflow also needs a replacement plan. Run the same task and checks with an available alternative before changing the pinned model. A successful response alone does not establish equivalent coding behavior.
When to reach for Kimi K2
Use a scoped task with a reproducible test result to compare model choices. For a date utility change, include timezone boundaries and invalid inputs rather than judging only whether the patch compiles. If you prefer automatic selection, Factory Router chooses models as work develops under the organization's model controls.
Kimi K2 in headless runs and Missions
The Missions reference documents droid exec --mission, --worker-model, and --validator-model. Headless Missions require the high-autonomy permissions documented in the CLI reference, so approve their execution scope before enabling them. An existing Mission can select --worker-model kimi-k2.5 while that model remains available. Choose the validator against the task's failure modes and test it on incorrect patches, rather than assuming a higher multiplier makes it a better reviewer.
Before pinning any model in unattended work, confirm availability for the execution identity and decide how the job should report a removed or disallowed model. Keep the chosen model and validation results with the run so a catalog change is distinguishable from a code regression.
