A developer I know pulled up their inference bill last month and couldn’t explain why fixing a typo in a config file cost almost as much as the feature that took all afternoon to build. Both requests went through the same coding agent. Both hit the same model. That’s just how the agent was wired: one model, one API key, one price per token, whether the task in front of it was trivial or genuinely hard.

Nobody sits down and decides this. It happens because picking one model is easy, and building something smarter takes work most teams don’t get around to. So the quick lookups and short summaries end up paying frontier prices for jobs a cheaper model would handle just as well. Run that across an agent making hundreds of tool calls, or a dozen agents running at once, and the waste piles up fast.

Kimi K3, Moonshot AI’s 2.8-trillion-parameter open-weight model that shipped in July 2026, is a good model to put next to Claude here. Not as a rival, but as a partner: they’re strong at different things and priced differently, and that gap is exactly what makes routing worth doing. This post walks through why hand-built routing logic breaks down, what Kimi K3 and Claude are each actually good for, and how to route between them for real using DigitalOcean’s Inference Router.

M.A.R.S. is currently available through an invite-only Private Preview. Request access here.

The problem with hardcoded routing

The obvious fix is to build the routing yourself. An if/else on prompt length. A keyword check. Or an LLM call that reads the request and decides where it should go. That last option is where most teams end up, and it’s also where things get messy.

Say you use a small model like Haiku to classify each request before sending it anywhere. Now you’re paying for two calls instead of one, on every request, forever. And a general-purpose model doing classification as a side job isn’t great at it. It gets less accurate as your traffic shifts or you swap in a new model, and you’re the one who has to notice and fix it. You’ve basically built a second application whose only job is deciding which model handles the first one.

What holds up instead is routing at the infrastructure layer: something that reads the request, decides which model it needs, and sends it there, without your app code having to know or care. That’s a narrow job, and it’s worth handing to a model built specifically for it.

image

Two models, two different jobs

Claude is a closed model. Anthropic builds it, serves it, and tunes it end to end, and you’re paying for that: steady behavior, strong reasoning, solid tool use across long, complicated tasks.

Kimi K3 is a different kind of tool. It’s open-weight, 2.78 trillion total parameters, 896 routed experts, a mix of Kimi Delta Attention and Gated Multi-head Latent Attention layers, and a context window up to 1 million tokens with native vision support. Moonshot built it to run for hours: autonomous coding, multi-step research, agentic work that survives hundreds of tool calls without losing the thread. On coding and agentic benchmarks it beats almost everything else on the market, sitting just behind a couple of true frontier models, and because the weights are open, providers can serve it a lot cheaper than a closed model of similar size.

image

Neither of them are a clear winner. Claude is what you reach for when a task needs real depth and you’re fine paying for it. Kimi K3 is what you reach for when the task is long, tool-heavy, or just high-volume, and frontier pricing would be a waste of money. A router’s job is telling those two apart, one request at a time.

The price gap between them is the whole reason this matters. An open-weight model gets served by whoever wants to compete on price for the same weights. A closed model’s price is set by one vendor. Send enough traffic through an agent, and the difference between routing most of it to the cheaper model versus all of it to the pricier one shows up on your invoice, not just in a benchmark table.

How DigitalOcean’s Inference Router does this

Inference Router sits in front of DigitalOcean’s Model Catalog and sends each request to the best-fit model from a pool you define, based on cost, latency, or whatever policy you set. It’s a small change to your code: instead of naming a model, you name a router, prefixed with router:, and the router picks the model for you.

It’s built on Plano, an open-source proxy made for this kind of work. The part worth paying attention to is that deciding where a request goes doesn’t run through a general-purpose LLM at all. It runs through Plano-Orchestrator, a model DigitalOcean trained just for routing, in a 4B and a 30B version. In DigitalOcean’s own testing across nearly 2,000 messages and 605 conversations, the 30B version scored 87.84% average accuracy, ahead of GPT-5.1 (86.93%) and Claude Sonnet 4.5 (86.11%), and it makes that call in about 200 milliseconds. You aren’t paying frontier rates just to figure out which model should answer.

A router is made of tasks. Each task has a name, a plain-language description that the routing model matches against the conversation, a pool of models it’s allowed to pick from, and a policy: cheapest, fastest, or a fixed order you set yourself. Anything that doesn’t match falls to whatever fallback models you’ve configured, tried in order, so a request never gets stuck.

image

Building a router that pools Kimi K3 and Claude

Here’s a router with two tasks: one for short, high-volume work that doesn’t need much reasoning, and one for the multi-step coding and analysis work both models can handle, where you’d rather let the router pick the faster or cheaper option than hardcode a winner.

curl -X POST "https://api.digitalocean.com/v2/gen-ai/models/routers" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "kimi-claude-router",
    "description": "Routes quick lookups and long-running agentic coding work across Kimi K3 and Claude",
    "policies": [
      {
        "custom_task": {
          "name": "quick_turnaround",
          "description": "Short questions, summaries, quick lookups, or single-step answers"
        },
        "models": ["kimi-k3", "anthropic-claude-sonnet-4.6"],
        "selection_policy": { "prefer": "cheapest" }
      },
      {
        "custom_task": {
          "name": "agentic_coding",
          "description": "Multi-step coding tasks, long-horizon tool use, or deep codebase analysis"
        },
        "models": ["anthropic-claude-opus-4.6", "kimi-k3"],
        "selection_policy": { "prefer": "fastest" }
      }
    ],
    "fallback_models": ["kimi-k3"]
}'

The task name and description aren’t just labels, they’re what the routing model reads to decide where a request belongs. Write one too broad, like “handle coding stuff,” and it’ll catch everything. Too narrow, and it misses requests it should catch. Keep descriptions specific enough to tell tasks apart, and you’ll get better routing than the defaults out of the box.

Once the router exists, using it is a one-line change to any call you’re already making:

curl https://inference.do-ai.run/v1/chat/completions \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "router:kimi-claude-router",
    "messages": [
      {"role": "user", "content": "What does a KeyError mean in Python?"}
    ]
  }'

That question is short and single-step, so it should land in quick_turnaround and go to whichever of Kimi K3 or Claude Sonnet is cheaper right then, since cost gets checked live, not set once. The response tells you exactly what happened: the model field shows which model answered, and the x-model-router-selected-route header shows which task it matched.

For multi-turn agent sessions, you usually want the same model handling a task from start to finish. Providers like Anthropic cache the earlier parts of a conversation so repeat requests are cheaper and faster to process, but that cache is tied to the specific model that built it. Switch models mid-conversation and you throw that cache away, so you want the router sticking with one model instead of reconsidering on every turn. A stable X-Model-Affinity header, a session or task ID your app already tracks, keeps that work on one model. If you still want the router able to switch mid-session when the numbers clearly favor it, X-Routing-Max-Switch-Spend-Pct caps how much extra it’s allowed to spend to make that switch. By default that’s capped at 20% above the cost of staying put.

Checking that it’s actually working

Before you trust this in production, use DigitalOcean’s Playground to compare the router against a single model on the same prompts. It shows cost and latency for each, side by side. Evals goes a step further: run the router against a labeled dataset and get correctness and completeness scores, so you know routing is holding up on quality before it’s live, not after.

Once it’s live, the Analyze dashboard shows you what’s really happening: how often requests actually match one of your tasks versus falling to a fallback model, how traffic splits between Kimi K3 and Claude, how often cached context gets reused, and latency broken down by model and task. If agentic_coding requests keep landing on Claude 90% of the time even though Kimi K3 is in the pool, you’ll see it in the model distribution chart. That’s usually a sign your task description needs work, not that Kimi K3 can’t do the job.

Give it a week or two before calling it done. Pricing and latency move: a provider’s response time can swing two or three times over in a single day depending on load, which is why the router checks live data instead of running off a rule you set once. A router can fall out of balance as your traffic changes, and a rising fallback rate is usually the first clue.

Conclusion

So this was never really a Kimi K3 versus Claude question. Pick either one alone and you’re back to paying one price for every task, just a different price. Pool them behind a router instead, and you get Claude when a task needs the depth, and Kimi K3 for the volume of work that doesn’t need it. As pricing shifts or new models ship, you update the router’s config, not your application code. That’s the actual win here: not which model is better, but never having to choose just one again.

References