OptiQ Code vs opencode
We put two coding agents on the same local model, a 4-bit Qwen3.6-35B-A3B under optiq serve, and ran both through an open benchmark built to test coding agents. They solve the same tasks. The difference is cost: OptiQ Code gets the same work done with about five times fewer tokens. On a laptop those tokens are your own compute and your own battery, so the gap costs real time.
We had wanted to test one claim properly for a while. The claim is that an agent built for local models does better than a general one when both run the same local model. The claim is easy to make. Testing it fairly is harder, because most agent benchmarks vary the model and hold the tool constant. openbench does the reverse.
openbench is a benchmark for coding-agent harnesses. It holds the model and the tasks fixed and measures how much the scaffolding around the model changes the result. Each task is a small repo with an instruction and a grading script, and it only counts as solved when that script exits zero. The agent's own word does not count, so an agent that claims it fixed the bug but did not still scores a zero.
The setup
Every request in this test hits one model. We loaded mlx-community/Qwen3.6-35B-A3B-OptiQ-4bit once under optiq serve: a 35B sparse MoE with about 3B active parameters per token, quantized to 4-bit, sitting resident on a 36 GB M3 Max. It exposes an OpenAI-compatible endpoint, and both agents point at it. The model, the quantization, and the KV cache do not change between runs.
| Held fixed | Value |
|---|---|
| Model | Qwen3.6-35B-A3B-OptiQ-4bit (3B active) |
| Server | optiq serve · 64k context · mixed-precision KV |
| Hardware | M3 Max, 36 GB, no cloud |
| Tasks | openbench core set, 8 tasks, 1 trial |
| Grading | checker.sh exit code, not self-report |
The two agents are OptiQ Code, our terminal agent for local models, and opencode, a general-purpose coding agent that plenty of people use. OptiQ Code runs through openbench's bring-your-own-harness manifest, headless, approving its own edits. opencode runs through its own openbench adapter, pointed at the same endpoint.
Measuring tokens the same way
opencode reports its own token counts. OptiQ Code runs as a black-box CLI and reports none to openbench. Rather than compare one agent's self-reported numbers against nothing, we dropped a small proxy between both agents and optiq serve. It passes every request through untouched and reads the usage field back out of each response. Both agents end up counted the same way, at the server, with the token and turn counts coming from one place.
Both solve the same tasks
On correctness the two agents are hard to tell apart, which is roughly what openbench's own results lead you to expect once the model is good enough. Both go six for six on the standard tasks. Both also solve taskflow, a 7,800-line codebase. They only come apart on webcore, the other large task, where both hit the 600-second cap before finishing. When the clock ran out, OptiQ Code had gotten about twice as far, 0.74 against 0.38.
| Tasks | OptiQ Code | opencode |
|---|---|---|
| 6 standard tasks | 6 / 6 | 6 / 6 |
| taskflow (7.8k lines) | 1.00 | 1.00 |
| webcore (7.1k lines, capped) | 0.74 | 0.38 |
Stop there and it is a tie. The question worth asking, once both agents finish the task, is what each one spent to do it.
The cost of a solve
Here are the six tasks both agents solve, with every figure read off the same proxy: prompt tokens sent, output tokens generated, round-trips to the model, and wall-clock time.
| Task | Prompt tok | Output tok | Turns | Time |
|---|---|---|---|---|
| fix-failing-test | 7.2k vs 40.8k | 250 vs 373 | 5 vs 5 | 10.9s vs 30.5s |
| make-it-run | 7.7k vs 40.5k | 491 vs 628 | 5 vs 5 | 15.5s vs 36.7s |
| misleading-error | 12.3k vs 44.2k | 457 vs 679 | 7 vs 5 | 15.6s vs 40.3s |
| build-a-cli | 13.5k vs 49.4k | 719 vs 532 | 7 vs 6 | 21.0s vs 34.2s |
| add-feature | 28.5k vs 180.0k | 1.2k vs 7.8k | 8 vs 14 | 33.5s vs 268.8s |
| make-ci-green | 26.9k vs 127.7k | 1.5k vs 2.9k | 6 vs 9 | 40.4s vs 142.7s |
Bold is OptiQ Code. Dim is opencode. Both drove the same Qwen3.6-35B-A3B.
Averaged over those six tasks:
| Metric | OptiQ Code | opencode | Advantage |
|---|---|---|---|
| Prompt tokens | 16.0k | 80.4k | 5.0× leaner |
| Output tokens | 770 | 2,140 | 2.8× fewer |
| Total tokens | 16.8k | 82.6k | 4.9× fewer |
| Turns | 6.3 | 7.3 | fewer |
| Wall time | 23s | 92s | 4.0× faster |
Where the tokens go
Almost all of the gap is in what each agent sends up. opencode ships a large general-purpose system prompt, around 7,600 tokens of instructions and tool schemas, and re-sends the growing conversation every turn. OptiQ Code is built for one job against one kind of model, so its prompts are shorter and it holds down how much context it resends. Same task, but opencode gives the model a lot more to read on every step.
On a laptop those tokens are compute you pay for directly. There is no invoice, but every prompt token is the model re-reading context, and on local hardware that is real prefill time and real battery. Five times fewer tokens is about five times less of that work, and it is most of why the wall-clock gap is as wide as it is.
What this means on a Mac
So: a 4-bit 35B model, running entirely on a laptop, gets real coding tasks done, including a 7,800-line refactor, graded by an outside checker, with no cloud and no API key. Which agent you wrap around it decides whether a task costs 17k tokens or 83k.
On a hosted model that overhead is someone else's server and a line on your invoice. On a local model it is your own hardware. A leaner agent finishes sooner and leaves more of the context window for the actual code. That is the argument for a local-first agent over a general one, at least on a Mac.
Reproduce it
All of this runs on hardware you already own. Serve the model, then point OptiQ Code at it.
# serve the model once
optiq serve --model mlx-community/Qwen3.6-35B-A3B-OptiQ-4bit --port 8099
# drive it with the local coding agent
export OPTIQ_BASE_URL=http://localhost:8099/v1
optiq code launch .The openbench manifest, the proxy, and the raw per-task numbers are small enough to rerun on any 36 GB Apple Silicon Mac. Both agents reached the same result; OptiQ Code used far fewer tokens to get there.