Claude and Qwen: expensive planning, cheaper implementation
ClaudeCodexQwenAI-разработка
A strong model designs, a cheaper one writes the code
I would split the work this way: Claude or Codex analyzes requirements, creates a plan, and reviews the result, while Qwen handles most of the edits. This is not a universal replacement for a premium model; it is task routing based on complexity.
The public claude-qwen-hybrid project describes a very similar pipeline. Claude Code produces a structured JSON plan, then a local model executes the steps, works with the repository, and runs checks.
The savings do not come from preventing the stronger model from seeing context. They come from reducing its expensive output tokens and tool-use cycles. In the published example, the planner used 540 output tokens and 10,666 cached input tokens, with an estimated cost of $0.0113 at the time of reporting. That is one report, not a promise of the same price for every repository.
The key artifact is neither the prompt nor a long chat history, but the task handoff contract. It should define the change scope, interfaces, invariants, acceptance criteria, validation commands, and conditions for returning to planning.
- Claude or Codex: architecture, decomposition, risks, and final review.
- Qwen: bounded edits, tests, repetitive changes, and fixes based on specific review comments.
- Automated gate: formatting, type checks, tests, security checks, and changed-file controls.
Benchmarks offer only indirect support for this setup. On the official Qwen3.7 page, the Qwen team reported 80.4% for Qwen3.7-Max on SWE-Verified versus 80.8% for the listed Opus 4.6 Max. Those are vendor-reported figures, and they do not measure the architectural integrity of a large project.
Context handoff quality determines the savings
The hybrid approach works best on modular tasks with solid tests, but quickly falls apart when architectural decisions must be made at every step. The most dangerous failure looks harmless: the implementer satisfies local criteria while gradually moving the code away from the overall design.
I would track repeat review cycles, the share of accepted changes, and post-merge defects before focusing on token cost. If Claude or Codex regularly rewrites Qwen's implementation, the savings exist only in a spreadsheet.
There is also an operational cost: patch isolation, allowed commands, timeouts, secret filtering, and rollback after a failed check. Without these controls, a local implementer is cheaper only until the first expensive incident.
This pipeline looks less like a competition between models and more like a compiler with an expensive frontend and low-cost execution. One question remains unresolved: how compact can the plan become before it loses the very context that justified involving the stronger model?