Kimi K3 + Claude Fable 5: The Practical Art of Model Routing

The bill shows up before the answer does

There’s a particular kind of frustration that only happens when you run “agentic” work: a task starts confidently, the assistant keeps making progress, and then—quietly—the token meter starts climbing like it’s late for an appointment. Long loops (debugging a repo, investigating a security issue, iterating through a plan) can turn a small experiment into a surprisingly expensive run.

That’s why the idea behind model routing feels so practical: don’t ask one model to do everything. Send each task to the model most likely to finish it with the best quality-for-cost tradeoff.

In a recent set of experiments, Kimi K3 (open) and Claude Fable 5 (closed) are evaluated as a pair, with per-task routing achieving very high overall solve rates while cutting cost dramatically compared to using Fable alone. (docs.fireworks.ai)

What “model routing” means (without the buzzwords)

Model routing is the system logic that chooses which language model to run for a given request.

That choice matters because models differ in at least four ways:

• Quality on a task type (code vs. terminal work vs. math-style problems).
• Efficiency (how many tokens they tend to consume to finish).
• Failure modes (some models “get stuck” on long-horizon steps more often).
• Pricing mechanics (input vs. output token rates; caching discounts).

Even if two models look neck-and-neck on a headline benchmark, they can behave very differently inside real agent loops.

Why Kimi K3 and Fable complement each other

A beginner-friendly way to picture the K3/Fable setup: imagine two coworkers.

• One is great at doing careful, structured work and tends to be steady on certain coding sub-skills.
• The other is a powerhouse for long-horizon reasoning and tends to finish certain “hard tail” problems with fewer catastrophic misses.

Kimi K3 is described as a high-capability open-weight model with a large context window (marketing materials cite a “1-million-token context window” and a ~2.8T parameter scale). (k3-intro.vercel.app)
Claude Fable 5 is positioned as Anthropic’s top general-purpose model, and its published API pricing is $10 per million input tokens and $50 per million output tokens. (anthropic.com)

When you route tasks, you’re not forcing a single “best” model to carry the whole workload. You’re letting each model’s strengths cover the other model’s weak spots.

Oracle routing vs. a real router

One subtle but important measurement idea is oracle routing.

Oracle routing means: for evaluation only, you run the task through each candidate model (or otherwise know which would succeed cheapest), then pick the best outcome among them. It’s a “ceiling” on what a perfect router could do.

A practical router doesn’t get to try every model ahead of time. It makes a prediction based on what it knows at request time—task signals, estimated difficulty, expected loop length, and similar heuristics.

In the experiments, oracle routing suggested Kimi K3 would be selected for most traffic (roughly the majority of tasks) most of the time, implying a near-perfect router might be possible with enough task-routing data.

Measuring on agentic reality, not one-shot benchmarks

A common mistake is to evaluate models in a way that hides the thing you care about: the multi-turn loop.

Agentic tasks don’t just require “the right first answer.” They require:

1. Planning steps that lead somewhere.
2. Tool use (or at least faithful iterations).
3. Recovery when a step goes slightly wrong.
4. Termination at the right moment.

So the evaluation breaks tasks into different families—not just one benchmark number—so you can see specialization and routing opportunities. The tested families included things like:

• SWE-style repo bug-fixes (realistic coding changes inside a project)
• Terminal-style long-horizon operations (security/crypto/reverse-engineering/sysadmin-like flows)
• Algorithmic problems (LeetCode/AtCoder-style)
• Multi-language implementations
• Legal-agent grading (work graded by a “lawyer-like” rubric)

What matters is the pattern: even when overall solve rates are close, each model can dominate different categories.

“Two models is better than one” looks like this

Suppose K3 and Fable are both strong. If you naïvely pick one model for everything, you get a world where every task pays the “wrong model tax” whenever that model isn’t the best fit.

Routing turns that into a different outcome:

• For the easy-to-medium majority, choose the cheaper model that still solves reliably.
• For the long-horizon hard tail, fall back to the model that is less likely to stall or fail.

In the reported run, routing between the two models reached about 93% accuracy across ~1,000 agentic tasks, while also landing in a far lower cost range than using Fable alone.

The headline lesson isn’t “always use two models.” It’s that per-task routing beats any single model run, because the “best model” depends on the task’s shape.

Why cost drops so much: tokens, turns, and caching

A router can’t win on cost unless the accounting matches reality. Most of the time, the cost story is a triangle of:

• Tokens: tokenization is the model’s unit of text processing; more tokens usually means more compute.
• Turns: a turn is one model interaction step in a multi-step agent loop.
• Caching: prompt caching discounts repeated input tokens by reusing a previously processed prefix.

Fireworks’ documentation describes that cached input tokens are discounted (with a default discount for text/vision models unless a provider lists a different cached rate). (docs.fireworks.ai)

That single feature can dramatically change which model “wins” financially in long loops.

Turns vs. tokens: the non-obvious part

Here’s where the intuition often breaks.

A model might use more tokens on some task types but still be cheaper overall because caching hits are frequent and expensive output generation is less.

In the experiments, the effort profile differed by category:

• For SWE-style tasks, Kimi K3 used far more turns/tokens on average than Fable.
• For terminal-style long-horizon work, the situation flipped, with Fable consuming more turns/tokens and sometimes approaching timeouts.

So routing benefits aren’t theoretical. They align with how agent loops actually burn compute.

What prompt caching changes in agent workflows

Prompt caching matters because agent loops tend to reuse:

• a system prompt
• task framing instructions
• tool/function definitions
• the early parts of the conversation that remain unchanged

On a practical serving stack, this is often implemented with a session affinity concept: requests that belong to the same workflow keep hitting the same cached prefix.

On Fireworks, the serverless docs describe prompt caching behavior and how it discounts cached input tokens. (docs.fireworks.ai)

The key mental model: caching reduces the “re-read cost” of your fixed scaffolding so the bill focuses on the “new work,” like new observations and new actions.

A practical way to build a router (that won’t collapse in production)

A full ML router can be great, but many teams start with something simpler that’s still effective.

Step 1: Route on task shape, not task name

Instead of mapping “SWE” → K3 and “Terminal” → Fable directly, route on signals that correlate with expected loop behavior:

• expected number of agent turns
• likelihood of tool usage / iterative edits
• risk level (where failure is expensive)
• response length expectations (output-heavy tasks cost more)

A “task shape” view prevents brittle routing when the same label hides different difficulty.

Step 2: Calibrate the decision with a shadow evaluation

Before you let the router affect live user outcomes, run it in “shadow mode”:

• the router chooses a model
• the system also logs what would have happened with alternative models
• you track solve rate and cost, category by category

This turns routing into an engineering system with observability rather than a one-shot experiment.

Step 3: Keep the router conservative for the hard tail

A router that’s too eager to pick the cheapest model will drag overall quality down.

The safest approach is often:

• default to the cost-efficient model when confidence is high
• add a fallback rule when the model is predicted to get stuck (long loops, high-risk categories)

It’s the difference between “optimize the average” and “protect the long tail.” Routing is mostly about the long tail.

The bigger takeaway: cost optimization is a systems problem

Model routing isn’t a novelty. It’s a way to treat LLM selection like any other systems optimization.

You measure on agentic tasks, not one-shot scores. You understand where tokens and turns explode. You use prompt caching so the fixed scaffolding doesn’t dominate your bill. And you let a router coordinate multiple models instead of forcing a single “generalist” to be the hero everywhere.

That’s how Kimi K3 and Claude Fable 5 move from “two strong options” to a combined system that performs better than either model alone—while keeping costs far more controlled than sending every request to the most expensive model.

Closing thought

The best routing strategy won’t feel dramatic. It feels like relief: fewer token surprises, fewer stalled agent loops, and solve rates that finally reflect how work is actually done. The interesting part isn’t that two models exist. It’s that an agentic workflow can make them cooperate—task by task.