無料のexecutorが一番高くついた話 — Opus + ローカルQwenが全タスクで最高額になった理由 Pairing Claude Opus with a free local Qwen executor paradoxically yielded the highest cost…

A recent write-up on Zenn explores a counterintuitive finding for anyone building agentic LLM systems: pairing a premium planning model with a free, locally hosted executor can end up costing more than a leaner setup. The author combined Anthropic's Claude Opus as an orchestrator with a locally run Qwen model acting as the task executor, and across 40 trials this configuration produced the highest total spend of any setup tested. The result matters because the "let a cheap or free model do the grunt work" pattern is widely assumed to reduce costs, and this case suggests that assumption can quietly break down.

The architecture in question is a common one. In many agentic pipelines, a capable model plans, decomposes work, and reviews results, while a smaller or cheaper model carries out individual steps. The appeal is obvious: the expensive model is invoked sparingly for high-level reasoning, and the bulk of token throughput is handled by something cheaper. When the executor runs locally on open weights such as Qwen, its marginal API cost is effectively zero, so on paper the combination looks like the frugal choice.

The problem, according to the report, is that cost is not driven by per-token price alone but by how often the system has to retry, re-plan, and re-verify. When a lower-capability executor fails a task or produces output that does not pass the orchestrator's checks, the workflow loops back to the expensive planner. Each failure appears to trigger additional Opus calls to diagnose the problem, adjust instructions, and re-issue the task. Those extra planning and review turns accumulate, and because Opus sits at the premium end of Anthropic's pricing, even a modest increase in call volume can dominate the bill. The free executor, in other words, appears to have shifted spending onto the most expensive component rather than removing it.

The dynamics echo a broader lesson in cost optimization for LLM applications: total cost of ownership depends on the end-to-end success rate, not the sticker price of any single model. A capable executor that finishes a task in one pass may generate fewer overall tokens than a weak one that needs three attempts, each accompanied by supervisory overhead from the orchestrator. This is sometimes framed as the difference between unit cost and effective cost per completed task.

Some background helps frame the trade-off. Qwen is Alibaba's family of open-weight models, available in a range of sizes and popular for local deployment because it can be run on consumer or workstation hardware without per-request fees. Claude Opus is the largest and most expensive tier in Anthropic's Claude line, positioned for complex reasoning. Local inference is not truly free either; it carries hardware, memory, and energy costs that a pure API accounting would miss, though those were apparently not the deciding factor here. The headline cost driver was the escalation in paid Opus usage.

There are several ways such a setup could be tuned, and the report implicitly points to them. Choosing a stronger local model, or a larger Qwen variant, might raise the executor's single-pass success rate enough to shorten the retry loop. Alternatively, using a mid-tier hosted model such as Claude Sonnet or Haiku for planning could lower the cost of each supervisory turn even if the number of turns stays high. Capping retries, adding cheaper validation steps before escalating, and matching executor capability to task difficulty are other common mitigations.

The findings should be read with caution. Forty trials on a particular task mix is a small sample, and outcomes will vary with the prompts, the task types, the specific Qwen size used, and the pricing in effect at the time. The result does not show that local executors are generally uneconomical, only that a capability mismatch between planner and executor can invert the expected savings. It is also worth noting that the balance is likely to move as open-weight models improve, since a more reliable executor would reduce the failed handoffs that drove the cost.

As hybrid local-plus-cloud designs become more common, the practical takeaway is to measure cost per successful task across the whole pipeline rather than reasoning from per-token rates or the word "free." An executor with no invoice can still be the most expensive part of a system if it makes the premium model work harder.