\*On a real job with hidden checks, letting the expensive model plan and review while a local Qwen typed, cost 72% less and used 85% fewer expensive-model tokens. Day to day, every expensive token the head spends buys 20 to 50 tokens of cheap local work, and the tighter that ratio, the more efficient the split.\*

About \*\*2B tokens\*\* and \*\*27k requests\*\* through Qwen 3.6, then 3.8 (unsloth NVFP4 quants) on one RTX 5090, as a \*worker\* under a paid coding model rather than a replacement for it. Claude Code plans, writes a short brief and reviews. Qwen reads and types. Here is what I found, then the thing I built around it.

[ vLLM's counters on this box across both Qwen versions: about 2B tokens over 27k requests. Handled 4-5 concurrent workers across a max of 262K token context.](https://preview.redd.it/uwzbhhgs06ph1.png?width=3274&format=png&auto=webp&s=ec261207d2e3e77e3020effddd324cb6f0bc8fd4)

\*\*Setup\*\*



\- RTX 5090, 32 GB VRAM, vLLM, 262k context

\- Earlier Qwen 3.6 27B, now Qwen 3.8 27B, both unsloth NVFP4 quants

\- Head: Claude Code. Worker: Qwen.



\*\*What the 27B carries as a worker\*\*



\- Real features across several modules, with their tests. Recent ones on the tool's own codebase: a change to a CLI command's behaviour that ran through the command, its skill text, the docs and the tests; a new dashboard tab with its server endpoint, its renderer and its tests; a client-side retry across two subsystems. Landed first try, checks green. It's capable of doing a lot of coding tasks irl.

\- Questions about a real codebase. "Which module owns retries and where is backoff decided." Accurate, and it can read all day without changing anything.

\- Docs. Give it the wording and it lands it byte for byte.

\- The tool's own end-to-end ladder, from trivial edits to changes on its own source in three languages, passes 100% on Qwen 3.8 NVFP4.



\*\*What needed tuning\*\*



\- Reasoning effort per task. At maximum effort the worker once spent 13 minutes in a single thinking turn, wrote its edit plan a dozen times over, and never touched a file. The same brief at medium effort landed. It was largely a quirk of the FP4 quant at the deepest thinking level; medium for builds, high for reading, and I haven't had a failure since.

\- A thinking model needs a real output budget. Starve it and the answer comes back empty.



\*\*The numbers\*\*



\- One job written to a spec, with the checks hidden from both runs. Claude alone: $0.91. Claude planning and reviewing, Qwen typing: $0.26. Same result, 72% less, 85% fewer expensive-model tokens.

\- Leverage from the tool's own records over the last week: 20 to 50 worker tokens per head token on a typical run, 130 to 150 on a read-only question with a short answer. The head's spend stays flat while the worker does the reading and typing.

\- Last week on this machine: 50 of 52 builds landed first try.

\- Overnight builds from a fixed spec, unattended: all handed-off jobs landed without issues, and the result passed over 98% of its tests.



How it was measured: [https://www.synapse-agents.space/blog/what-inspired-synapse.html](https://www.synapse-agents.space/blog/what-inspired-synapse.html)



\*\*What I built to make this work\*\*



One process on your machine. Your coding tool talks to it, and it runs the workers itself on whatever you point it at: a local vLLM or Ollama endpoint, or your own key for Anthropic, OpenAI, DeepSeek, OpenRouter and the rest, mixed per task, several workers in parallel on different models. A brief is checked against the real code before a token is spent. Work happens inside a fence: read-only jobs can't write a line, builds run in their own git worktree and land only when the checks pass, and the checks are run by something that isn't the worker, so it can't game the system. graphify is built in, so a worker reads a code graph instead of whole files. Briefs, code and worker output never leave your machine. Sign in on more than one machine and you see every machine's runs from any of them.



The part I'm proud of is that it's seamless, and that is where the months went: your coding tool is woken the moment each worker lands, a worker that stops to ask a question wakes you the same way, and a bad brief is refused in a second rather than an hour later. I've been building synapse with synapse for a while now, with Claude Code, Codex CLI and a bit of Claude's Cowork, running Qwen 3.8 and DeepSeek V4 workers side by side. It mostly just works, which took far longer than the parts that look clever.



\*\*Try it\*\*



[https://www.synapse-agents.space](https://www.synapse-agents.space)

Mostly synapse built itself! I used it as a crane to build itself by parts.

\`curl -fsSL [https://www.synapse-agents.space/install.sh](https://www.synapse-agents.space/install.sh) | sh\` on Linux or macOS. 14 days free, no card. It's early: if your coding tool goes quiet after handing off a job, tell it to use \`synapse wait\`. There's a support tool inside, so anything you hit lands on my desk with the run attached, and I'll fix it fast. 



What I want to hear: how it goes with your local model, and whether the "worker gets a brief, head reads a verdict" split holds up outside my setup. What have you had luck with as a worker? Has anyone had a 14B hold up on multi-file edits?



\---



\*\*TL;DR:\*\* 2B tokens through local Qwen 3.6/3.8 NVFP4 as a coding worker under Claude Code. The model carries real multi-module features once the reasoning effort is set per task. Plan-and-review split: 72% less cost, 85% fewer expensive tokens, 20 to 50 cheap tokens per expensive one. Built synapse so this works from your coding tool. Early access, 14 days free:   
\*\*https://www.synapse-agents.space\*\*

2B tokens of local Qwen3.8 as Claude Code's worker: 72% less spend on claude tokens, what a 27B NVFP4 carries, and the tool that makes it all seamless