Why we use 3 models instead of 1 for every coding task

The cheapest model in Kimchi's routing stack costs $0.75/1M output tokens. The most expensive costs $4.50. The difference maps to what each model is actually doing.

Most coding agents route everything through a single endpoint. One model reads your codebase, plans the task, writes the code, reviews it, and evaluates whether it worked. That's like assigning your best systems designer to write boilerplate all day because they're the most qualified person in the room.

Kimchi uses seven model roles: orchestrator, planner, builder, reviewer, explorer, researcher, and judge. Each maps to a different class of task. Each uses a model suited to it.

Why this matters

A reasoning model is designed to think. It's good at decomposing ambiguous tasks, planning sequences of steps, and catching subtle logic errors. It's also slow and expensive per token.

A fast execution model is designed to generate. It's good at writing code to a spec, handling bulk file operations, and completing well-defined tasks quickly. It's cheaper and faster than a reasoning model on the same work.

If you send bulk generation to a reasoning model, you're paying a reasoning premium for work that doesn't need it. It's like using a torque wrench to drive screws. It works. It's just wrong for most of the job.

The reverse is also true. Send a complex planning task to a fast execution model and you get shallow plans that break at step 3.

The current routing

Kimi K2.7 covers four roles: orchestrator, planner, reviewer, and judge. 262k context window, $4.50/1M output tokens. These are the roles where reasoning quality matters most - decomposing ambiguous tasks, sequencing work, catching logic errors, and evaluating milestone output.

MiniMax M3 covers two roles: builder and researcher. 1M context window, $1.20/1M output tokens. Builder is where most tokens are spent - writing code to spec across many files. Researcher handles information retrieval and synthesis during exploration phases.

M3 scores 59.0% on SWE-bench Pro - ahead of GPT-5.5 and Gemini 3.1 Pro on the same benchmark. SWE-bench Pro uses real GitHub issues rather than toy problems, which is why it's a better signal for actual coding work.

It also ran a CUDA optimization task for 24 hours, made 147 benchmark submissions, and kept improving after long performance plateaus. That long-horizon stability matters for /ferment sessions where a task runs across many milestones.

Nemotron-3-Ultra handles the explorer role. 1M context window, $0.75/1M output tokens. Reading files, indexing structure, surfacing relevant context - this doesn't need the same model as planning or execution.

The average proprietary model costs $12.10/1M output tokens. At full Kimchi routing, you're spending a fraction of that on work that doesn't need frontier reasoning, and spending appropriately on the work that does.

What the evaluator does

After each milestone, a high-reasoning model scores the output against the original intent. It checks for regressions, half-done work, and silent failures - the things that look correct until you run them.

The judge role uses Kimi K2.7 by default. You're not grading a milestone with the same model that built it - the builder is MiniMax M3, the judge is Kimi K2.7.

evaluator kimi-k2.7      milestone 3 of 4
spec match      9.2 / 10
regressions     0 found
edge cases      2 flagged
milestone passed - proceeding to milestone 4

Multi-model vs. single-model

You can turn multi-model off and lock Kimchi to a single provider. We built that option deliberately - some teams need it for compliance, some want to evaluate a specific model in isolation.

But the default routing makes a strong case for itself. The cost difference between sending everything to a reasoning model and routing properly across the task stack can range between 40–60%. For long-running /ferment sessions, that gap compounds across every milestone.

Where this is going

The routing stack isn't static. We add models when they're meaningfully better or cheaper for a specific role. M3 replaced an earlier execution model when its SWE-bench scores and context handling made it the better fit for the builder role.

The OSS model landscape moves fast. The Kimchi routing layer is designed to take advantage of that - swap a better model in without changing anything downstream.

To see it in action: install Kimchi, run a /ferment session, watch the model switcher. You'll see which model handles which phase in real time. The visibility is the point.

Get started for free at kimchi.dev.