qwen3-coder

qwen3-coder-regrilled (qwen3-coder-regrilled.md)

Run 2026-08-09, vllm/grill-qwen3-coder-20260809.sh, 7 minutes, 18 suite

runs, 0 failed. Same protocol and same jsonl as

[[regrill-20260808-four-model-trust]], driven through llama-swap on :8090 (the

production path) rather than a hand-launched vLLM.

| | rep1 | rep2 | spread |

|---|---|---|---|

| R1 | 7/8 | 6/8 | 1 |

| R2 / R3 / R4 | 5/5, 5/5, 4/5 | same | 0 |

| R5 agentic | 6/6 | 6/6 | 0 |

| R1-R5 total | 27/29 | 26/29 | 1 |

| klayout from memory | 0/8 | 1/8 | |

| klayout + API ref | 4/8 | 4/8 | 0 |

| office (non-vision) | 2/6 | 6/6 | 4 |

| office + ref | 4/6 | 4/6 | 0 |

Its recorded 20/23 was a bad single sample. Real R1-R4 is 21/23 then 20/23.

On R1-R5 it is second of five, behind only fable-711-gptq (28/29 twice) and

ahead of glm-flash-awq (26/29, 27/29) — at 141 tok/s vs fable's 28.

THE HEADLINE IS TOKEN EFFICIENCY, not the score. Median output per task:

qwen3-coder 323 tok max 1171 ZERO cap-hits anywhere

glm-flash-awq 2564 tok max 16000

8x leaner for one point more. It is an Instruct model with no reasoning

block; glm-flash is a reasoner (glm47 parser) that spends thousands of tokens

thinking. Combined with 141 vs 82 tok/s that is ~13x less wall clock: this whole

grill took 7 min where glm-flash's identical suite set took 43. Same pattern as

[[coder-agentic-default-driver]] on the llama.cpp side — the lean model wins on

everything except raw ceiling.

But it is the WEAKEST KLayout model of the five: 8/16 with the API reference,

against fable 14/16, glm-flash 13/16, qwen3-vision 12/16, qwen3-vl-thinking

12/16. A recurring failure is NameError: name 'db' is not defined — it omits

the import even though grill_klayout.py says "including its imports". That is

a genuine model failure, NOT the prompt gap found in the vision grill

([[closed-loop-works-with-api-ref]]).

The office "inversion" is dead — it was noise. The 2026-08-04 record showed

office 8/14 WITHOUT the reference but 4/10 WITH it, the only model that appeared

to get worse when handed the API. Two repeats: the unassisted arm swung **2/6

then 6/6 (spread 4)** while the assisted arm sat at 4/6 twice, and both arms

land at exactly 8/12 combined (denominators corrected 2026-08-09, see

[[office-loop-denominator-fix]]). The reference

neither helps nor hurts this model; the anomaly was an unstable unassisted score

sampled once. Another entry for [[single-run-scores-are-unreliable]].

Where it sits. Text-only, like glm-flash-awq, so it brings no vision either.

For general coding it is faster, leaner and marginally stronger than glm-flash;

for KLayout it is the worst option on the box. It stays in the config regardless

because kimi-code / pi / omp reference this exact id

([[vllm-office-server-client-wiring]]).

PROMOTED 2026-08-09 to everyday driver, replacing glm-flash-awq in every

default: open-webui DEFAULT_MODELS, omp modelRoles (all except vision, which

stays qwen3-vl-thinking), kimi-code default_model, opencode model +

small_model, and claude-llm's claude-code-x2 + fallback. Weights moved from

ssk500 back to the NVMe, since the driver should not pay a 50s cold-load

penalty. The DEFAULT_MODELS line and the resident model MUST match — under

llama-swap the default model is the one a new chat LOADS.

The promotion is a deliberate KLayout regression. qwen3-coder is 8/16 with

the API reference against glm-flash-awq's 13/16 — the worst of the five. Select

glm-flash-awq by name for KLayout codegen, or qwen3-vl-thinking for anything

needing the closed loop. Both remain served and both are on the NVMe.