The right model for the job

Yesterday I burned through my OpenAI and Anthropic quota faster than usual. The reason was simple: everything went right.

Every deliverable that day came through an agent. Code reviews, task updates, PR descriptions, Linear ticket syncs, a few refactors. The kind of work that used to take me hours now takes minutes. But there's a catch: when every agent call defaults to your most expensive model, the bill climbs fast.

I've heard this advice a hundred times and nodded along. Didn't act on it. The advice is simple: not every task needs a flagship model.

The Linear ticket problem

Take a concrete example. I have an MCP that connects my assistant to Linear. When I finish a task, the agent updates the ticket status, adds a comment with the commit hash, and moves on. That's it. Three API calls, a bit of text formatting, done.

For months I let Opus handle that.

Opus is brilliant at reasoning through ambiguous requirements, untangling legacy code, and catching edge cases in architecture decisions. Updating a Linear ticket is none of those things. It's a structured operation with a known schema and zero ambiguity. Sending Opus to do it is like using a surgical robot to open a can of beans.

Kimi K2.6 can do the exact same Linear update. Same output, same reliability, roughly 1/20th the cost.

Two editors, two jobs

So I changed the setup. Now I keep two editors open:

  • Claude Code for the heavy stuff. Architecture decisions, complex refactors, anything where the wrong call costs real money or real time.
  • Open Code with Kimi K2.6 for everything else. MCP tool calls, simple file edits, ticket updates, formatting, boilerplate.

The split is not about quality. Kimi is a solid model. The split is about matching the tool to the task.

This is not a new idea. We do it with everything else already. You don't rent a truck to buy groceries. You don't spin up a GPU cluster to serve a static landing page. But with LLMs, the default is still "use the best model for everything" because the cost per call feels invisible until the bill arrives.

What actually changed

The first day with this setup, I caught myself reaching for Claude Code out of habit three times. Each time I stopped and asked: is this task hard, or is it just familiar?

Two of those three times, Kimi handled it fine. The third was a database migration script where I genuinely wanted the stronger reasoning. That one went to Claude.

The mental shift is small but real: before every agent call, a half-second check. Does this need a brain, or does it need hands?

Most of what agents do during a workday is hands.

The cost difference is not subtle

I don't have exact numbers from one day, but the pattern is clear enough. A typical workday for me involves maybe 20-30 agent interactions. If even 70% of those are simple tool calls, ticket updates, and formatting tasks, moving them from Opus to Kimi cuts the per-task cost by an order of magnitude.

Over a month, that's the difference between "AI is a business expense I monitor" and "AI is a utility I don't think about."

The goal is the second one.

Tomorrow: shared memory across agents

There's a next step to this setup that I haven't solved yet. If I'm using two different editors with two different models, they don't share context. Claude Code doesn't know what Kimi just did. Kimi doesn't know what Claude is working on.

Tomorrow I'll write about how we're wiring both editors to the same memory layer using Engram Cloud, with shared MCPs so the handoff between models is not a context dump but a real shared workspace.

Because the right model for the job only works if the models can pass the job between them.

← Back to Blog