Skip to main content

​
What This Guide Gives You

You’ve probably already heard the idea of “plan with an expensive model, execute with a cheap one” to save money. This guide doesn’t rehash the theory — it solves three more practical things:
  1. All five mainstream tools covered — Claude Code, Hermes, pi, Kilo Code, Cline. For each tool, we give you a copy-paste config for this division of labor, plus one ready-to-use integration guide.
  2. A bill you can verify yourself — not “trust us, we saved you X,” but teaching you to read the cache_read field in the API response and confirm for yourself whether the cache actually hit and how much you saved.
  3. The pitfalls we hit in real testing — the five tools each authenticate differently (copy the wrong one and you get a 401), and some toggles fail silently if left off. All of this comes from running the tools for real.

​
1. What This Division of Labor Actually Is

In one sentence: hand “figuring out how to do it” and “actually doing it” to different models.
  • Planning (figuring out how to do it) — architecture design, breaking down tasks, reviewing approaches. Use the most capable Claude Fable 5. This part is few tokens but demands the most from the model.
  • Execution (actually doing it) — editing files per the plan, batch edits, running tools. Use the cheaper Haiku / Sonnet. This part is many tokens but doesn’t need a top-tier model.
Most programming work is “a little hard reasoning wrapped in a lot of mechanical execution.” Move the mechanical execution off the expensive model and the bill comes down.
Anthropic officially endorses this approach too — Claude Code’s built-in /model opusplan plans with the expensive model and automatically downgrades for execution. This guide extends that: plan with Fable 5, execute with any cheaper model, and reproduce this division of labor in four tools beyond Claude Code as well.

​
2. Five Tools, One Division of Labor

This is the core of the guide. The five tools implement the division of labor in different forms, but the goal is the same: use Fable 5 for the main/planning role, cheaper models for execution/auxiliary roles. The full integration steps for each tool are in its own integration guide (that is the single source of truth for configuration); this section only covers what’s essential to each tool’s division of labor.

​
Claude Code — The Finest-Grained Division of Labor

Claude Code uses the native Anthropic line (https://direct.evolink.ai) and offers several ways to divide the labor, from simplest to most flexible: ① Environment variables (fastest)
② settings.json persistence (global or per-project — one division of labor per project)
③ Subagent division of labor (finest-grained) — under .claude/agents/, assign a cheaper model to your execution subagents. The main loop (Fable 5) plans and dispatches subagents to execute, so the bulk of the tokens lands on the cheap model:
The most common configuration mistake: setting only the main model and assuming subagents will use the cheap one automatically. Subagents inherit the main model by default — if you don’t explicitly write model: in .claude/agents/*.md, every subagent tool call is billed at Fable 5 prices. For the division of labor to actually save money, this line cannot be omitted.
Other ways: switch anytime in-session with /model, turn on the official hybrid mode with /model opusplan, or specify at launch with claude --model claude-fable-5.

​
Hermes Agent — Main Model + 14 Auxiliary Slots

Configure the main model in config.yaml’s model.default, then point the 14 auxiliary slots (context compression, session titles, web extraction, etc.) at cheaper models one by one, so lightweight tasks don’t run up the main-model cost.

​
pi — A Multi-Model List with Prices

Set up a priced multi-model list in ~/.pi/agent/models.json, then switch planning/execution models in-session with /model.

​
Kilo Code — Switch Between Configuration Profiles

Create multiple OpenAI Compatible profiles (default = Fable 5 for planning / budget = Haiku for execution) and switch profiles to switch models.

​
Cline — Plan/Act Dual-Model Toggle

Plan (planning) uses Fable 5, Act (execution) uses a cheaper model — the most intuitive form of the division of labor. We recommend the “single gateway + multiple Model IDs” approach to avoid the dual-mode silent-fallback issue.
Why does every tool’s config point to a separate doc page? Because configuration details (base_url, model IDs, authentication) should have exactly one authoritative source. This guide covers “how to divide the labor to save money”; every concrete step defers to the respective integration guide — so you never see inconsistent configs in different places and get tripped up.

​
⚠️ The Five Tools Authenticate Differently (Copy the Wrong One and You Get a 401)

This is a detail we hit in real testing that most guides won’t tell you. Don’t copy one tool’s key format into another: The most counterintuitive point: pi requires you to manually enable Bearer (authHeader: true), whereas Kilo / Cline take a raw key and add Bearer for you — exactly the opposite.

​
3. The Bill Adds Up (and You Can Verify It Yourself)

​
Actual Prices (EvoLink’s Flat 10% Discount)

Unit: USD per million tokens. The savings come from two stacked levers: division of labor (landing most tokens on the cheaper model) + cache hits (input billed at roughly 0.1× when it hits). The first lever is stable; the second — depends on the hit rate, which is where this guide is most committed to being honest.

​
Others Just Give You a Conclusion; We Teach You to Verify It

Plenty of articles online throw out a stunning number (“save 80%,” “25downto25 down to 1.40”). The problem: you have no way to confirm whether your particular setup actually saved anything. This is especially true of the cache lever — it only kicks in on a hit. So this guide gives you an actionable verification method: look at the cache_read field in the API response. When the cache hits, this field has a real value; when it doesn’t, it’s 0. Run it once yourself and you’ll know the truth, without having to trust anyone’s marketing.
On caching, we’ll tell you the whole story: the hit rate is not stable. Testing found that in small-context planning scenarios, the cache hits reliably after warm-up and you get the 0.1× discount; but the larger the context (tens of K, big-repo scenarios), the more the hit rate visibly drops, and this discount gets diluted. So:
  • Don’t treat “cache 0.1×” as an unconditional across-the-board discount.
  • What saves money reliably is the division of labor lever; caching is a bonus, and only when it hits.
  • Use the cache_read method above to verify your own real scenario, rather than copying someone else’s numbers.

​
An Honest Caveat: The Division of Labor Isn’t a Cure-All

The division of labor pays off most on tasks that are cleanly decomposable, highly ambiguous, or long-running; for simple, direct tasks, running the whole thing on a single cheap model may be more economical, and an extra planning layer is over-engineering. Some benchmarks (like Fabio Akita’s three-round comparison) found that on certain tasks, the quality/cost of a single strong model actually beats the hybrid approach. Bottom line: the division of labor is a tool, not a creed. Use it on tasks that decompose cleanly and carry real workload; don’t force it onto trivial ones. This is exactly why we teach you to verify rather than take it on faith.

​
A Concrete Bill

Place a copy-paste-able cost comparison here, with every number sourced and the cache portion stated conditionally; avoid numbers that mirror competitors, and use our own real-tested scenario.

​
4. Just Want to Save Money Without Fussing Over the Division of Labor?

If you don’t want to set up the division of labor for now, EvoLink’s full Claude lineup is still a 10%-off entry point — configure one base_url and you’re using the same official models at a discount. You can come back to this guide anytime and set up the division of labor to cut costs further.
The full integration steps for each tool are in the integration guides. This guide covers the “save money by dividing the labor” workflow; the concrete config defers to each integration guide (the doc is the single source of truth).