Qwen3.6-35B writes the code instead of Claude: half the tokens — with a catch

Ran an interesting experiment today. The same spec file as before, for a markdown editor in Rust and GTK. Two different approaches.

1. The whole task done by Opus 5 through Claude Code. To keep the comparison clean, Claude Code spawned a separate subagent with a fresh context.
2. The task done by Opus 5 paired with a locally running Qwen3.6-35B-A3B. Here Opus 5 acts as the orchestrator and the brains, while all the code writing is delegated to Qwen. The orchestrator is a separate subagent with a clean context too, so that both approaches start from the same place.

The spec lists the criteria the app has to meet — interfaces, features, tests — plus validation by external scripts that check whether the thing actually works.

First, I was curious whether two models working together could handle the task at all. Second, I wanted to find out whether there would be any difference in token spend. The results are rather interesting.

Results

Both handled it.

By the formal criterion it is a draw. On tokens the pairing is 1.77× cheaper on output and 2.08× cheaper on cache reads, and that is a real saving: the local model costs nothing against my Claude limits.

But half the cost bought me barely more than a third of the code. The pairing did exactly what I ordered stage by stage — the mandatory core, and not a step further. Opus, entirely unprompted, went on to finish twelve more items the spec marks as optional: syntax highlighting, split view, themes, session restore, watching the file for external changes, HTML export, single-instance mode.

The saving is in limits, not in speed: on the clock the pairing is twice as slow.

One more observation, more about me than about the models. My validation scripts turned out to be weaker than I thought. They check that a window opened, that there are controls, and that clicking them does not crash the app. The main scenario — type some text and save it — is not covered at all. In the paired run Qwen produced code that sailed straight through the scripts, yet edits in the editor never reached the document model: Save wrote an empty file. The orchestrator caught that by reading the code, not by running the scripts, and sent it back to be fixed.

Conclusions

Delegating to a local model is worth it if you need exactly what you specified, and you are willing to slice the task into stages yourself and check every one of them. It saves almost half of your limits.

The orchestrator does have to work from a fresh context. I had a third run where I drove Qwen straight from a long working session — it ate three times more, purely on re-reading the accumulated history on every turn. That swallowed the entire gain.

But you pay for the saving with initiative. The pairing closes the list of requirements; it does not make a product. If you want the latter, not delegating is cheaper.