Section 1
One setting decides what it costs
Qwen3.8-27B is the most capable local coding model we have measured. Its best run scored 90.7, the highest single coding score in our data from anything that fits on consumer hardware. At IQ3/Q4 it needs just over 13 GB, so that ceiling is reachable on a 16 GB card or any modern Mac. How long you wait for it is decided by a setting you probably never chose.
Reasoning effort is not a server option. It is a variable the model's chat template reads while building the prompt. Qwen3.8 accepts three values: low, medium and xhigh. If you don't supply one, the template fills it in for you:
The default is the expensive one
{%- set resolved_reasoning_effort = reasoning_effort|default('xhigh') %}That line is from Qwen3.8's chat_template.jinja. Install the model, change nothing, and every answer runs at the highest setting it has. Most defaults sit somewhere in the middle. This one sits at the top.
We ran all three levels on one Mac. Everything that machine produced before this week counts as xhigh as well, since it was running on defaults the whole time.
| Effort | Runs | Tokens | Time | Median | Mean | Range |
|---|---|---|---|---|---|---|
| low | 3 | 4,984 | 84 s | 75.8 | 72.2 | 64.9–75.9 |
| medium | 4 | 4,792 | 77 s | 78.2 | 76.3 | 64.7–84.2 |
| xhigh (default) | 17 | 36,188 | 869 s | 78.8 | 77.0 | 54.1–89.2 |
One machine, one model, one quant. Median and mean are LLM-judged coding scores; token and time medians come from the runs made since per-scenario capture shipped.
Start with low and medium. They are not close, they are the same: 4,984 tokens against 4,792, eighty-four seconds against seventy-seven. The template shows why. It only adds an instruction for low and xhigh. The xhigh one tells the model to think carefully and check its assumptions. The low one tells it to keep its thinking brief. The model does the first and ignores the second.
The dial has two positions, not three: xhigh, and everything else.
That leaves what xhigh is worth. It costs eight times the tokens and eleven times the wall clock, fourteen minutes a question instead of seventy-seven seconds. In return the median coding score moves from 78.2 to 78.8, about half a point.
Section 2
What the extra thinking buys
Mostly a wider spread. The best coding answer this machine has produced came from xhigh, an 89.2 that medium never approached. So did the worst ones: xhigh's floor is 54.1, against medium's 64.7.
The pattern behind that lower floor is worth naming: given enough room, the model sometimes plans instead of building. Only the long setting gives it that much room.
xhigh raises the ceiling and drops the floor. It doesn't move the typical answer.
We also checked the judge's sub-scores, hoping to see where the extra tokens went. They don't separate. xhigh leads on correctness and completeness, medium leads on performance, code quality is a tie. With three and four runs at the short settings, none of those gaps means anything yet.
The same prompt, three ways
llm-bench stores what the model wrote, so you can see where one xhigh run's twenty minutes went. These are the opening frames of the three runs in the comparison above.
First frame as rendered in a headless browser, no interaction. All three are playable from their benchmark pages.
That run spent its budget on presentation: a letterspaced title card, a framed play area with corner accents, a keyboard legend, an audio toggle, a running best score. The low and medium runs built the game and stopped.
None of them built a better Breakout. All three are eight columns by four rows of bricks, three lives, one paddle, one ball, same rules. The xhigh run put its extra tokens into the wrapper, though there are real features in that wrapper: a restart key, keyboard control, sound.
One run each, so this is not a pattern, and the sub-scores don't back one up. Treat it as an example of what fifteen extra minutes can look like. The medium run cuts the other way: its HUD renders on top of the brick field, leaving the score and lives unreadable. More thinking might well have caught that.
How much of this is luck
Quite a lot. The four medium runs used one identical setting with nothing changed between them, and scored 64.7, 73.4, 83.0 and 84.2. That is a spread of nearly twenty points. Ask the same model the same question twice and you get materially different programs, so a single run tells you very little on its own.
Half a point sits well inside that. Read it as no measurable difference rather than a narrow win for xhigh. The cost figures need no such hedging, since eight times the tokens and eleven times the wall clock are mechanical.
Fourteen minutes instead of eighty seconds, for half a point.
Section 3
The budget, tested
If effort is the dial, a thinking budget is the backstop: let the model reason, but cap the tokens it may spend doing it. oMLX exposes this (thinking_budget_enabled / thinking_budget_tokens), and llm-bench records it in each run's inference configuration. Nobody had used it: across the 459 runs we checked, not one had a budget enabled. So we ran it ourselves. Three runs at a 12,000-token budget against a matched uncapped control, same Mac (M5 Max), same quant (oQ4e-mtp), same evening.
| Run | Budget | Code | Tokens | Time |
|---|---|---|---|---|
| Uncapped control | off | 76.8 | 42,067 | 16.4 min |
| Capped ×3 (range 67.0–79.6) | 12,000 | 75.0 | ~20,300 | ~7.5 min |
Two of those results are mechanical rather than statistical, so they hold. The cap binds: capped answers land within 400 tokens of each other at about 20,300, against 42,067 uncapped. And it halves the wall clock. Nothing truncated either. All four runs produced complete, playable games with closing tags and a working loop. The budget stops the model deliberating, not writing.
On quality we are not claiming a result. 75.0 against 76.8 is under two points from three runs, well inside the spread we see between runs at a fixed setting. What we can say is that nothing collapsed, and that the cap works as a lever for anyone stuck on a high-effort default.
A budget is not the only lever, and probably not the best one. Everything here is the model unsteered: one fixed prompt, a plain API call, no scaffolding. A real coding harness can ask for brevity, demand a single complete file, close the reasoning block at a threshold, or spot a stalled deliberation and re-prompt. A long run that stalls into planning instead of producing a file is exactly what a harness insisting on the artifact would catch. How much of this a good harness dissolves is untested. We suspect quite a lot.
What to expect on Apple Silicon
Apple Silicon is the natural home for a 27B, since unified memory lets even a 32 GB Mac hold the model comfortably. Generation sits near 34 tok/s on an M2 Ultra and around 42 on an M5 Max. Prompt processing scales further, from about 250 tok/s on the M2 Ultra to roughly 470 on the M5 Max.
Generation is the side that matters for the effort setting, and it is the side that barely moves. At 42 tok/s a 36,000-token answer is a quarter of an hour of your Mac at full tilt, where the short answer lands in about a minute.
Section 4
Where this leaves the board
Ranked by median coding score, Qwen3.8-27B sits at 77, a little behind Tiel-Coder-35B-A3B at 79. That 77 is a number to distrust, though, because it averages two behaviours that differ elevenfold in cost. The other models don't have this problem. None of them produced a single answer over 20,000 tokens, so their medians describe one behaviour.
| Model | Median | Ceiling | Mean tokens | Long runs |
|---|---|---|---|---|
| Qwen3.8-27B (dense, >13 GB) | 77 | 90.7 | 17,300 | 34% |
| Tiel-Coder-35B-A3B (MoE, ~17 GB) | 79 | 86.7 | 10,200 | 0% |
| Qwen3.6-27B (dense, ~14 GB) | 75 | 84.0 | 5,500 | 0% |
| Qwen3.6-35B-A3B (MoE, ~17 GB) | 70 | 84.4 | 5,700 | 0% |
"Long runs" is the share of coding answers over 20,000 tokens, which in practice marks high reasoning effort rather than the model misbehaving.
For agentic work the MoE case is stronger and doesn't depend on any of this. An agent loops for dozens of turns and latency compounds. A model with roughly 3B active parameters per token runs 2–3× faster at generation, and on the same M5 Max it processes prompts at about 1,600 tok/s against the 27B's 470, so it simply completes more turns per hour. A fourteen-minute deliberation inside a tool loop is not a quirk, it is a broken session.
How to read these numbers
Scores come from community benchmark runs on llm-bench.io, graded per scenario by an LLM judge from 0 to 100 and aggregated over all runs rather than best-of. They are directional rather than lab-grade, because the underlying runs vary: the same model at the same setting can produce a strong program one time and a weak one the next. Differences of a point or two, between models or between settings, should not be read as real.
On reasoning effort. The level is resolved from the model’s chat template and stored with each run, so it is recorded rather than inferred. That only covers runs made since capture shipped. For the older ones we rely on the operator’s own account plus output length, which the labelled runs support: no labelled low or medium run exceeded 20,000 tokens, every xhigh run did, and roughly 55,000 tokens separate the two groups with nothing in between. The cost figures are solid. The quality figures are not. Three and four runs at the short settings is too thin to grade anything, and the spread among identically-configured runs is wider than any gap between levels, so treat every per-effort quality number as a direction to test.
Samples are uneven. Qwen3.8-27B has 167 scored coding runs against Tiel-Coder’s 16, so that two-point median gap is thinner than it looks. Quantization matters too: a handful of 2-bit builds scored zero and were left out. One model is deliberately absent. K2-Horizon-MoVA-36B-A4B posted a 90.6, but at around 26 GB it sits above the 24 GB consumer line and has only two scored runs.
Section 5
The take-home
Qwen3.8-27B holds the highest coding ceiling you can reach on consumer hardware. What to know before installing it is that its cost is set by a dial you did not choose, and that the dial has two positions rather than three. Low and medium behave identically, about eighty seconds and a median near 78, so turning it down buys nothing.
xhigh is the position you get by default, and it is a bet on one shot. Fourteen minutes of thinking produces a single answer you either accept or throw away. The same fourteen minutes at medium is eleven answers, and you get to read the first one before asking for the second. That is the better use of the time. Set medium explicitly, look at what comes back, and iterate. Reserve the long setting for the problem you have already failed to solve the short way.
For agentic sessions, where the model is looping through tool calls for dozens of turns, a dense 27B is the wrong shape regardless of the setting. An A3B mixture-of-experts is worth a look: Ornith-1.5-35B-A3B (78.0 coding, 82.8 agent) and Tiel-Coder-35B-A3B (79.0 coding, 85.9 agent) both match the 27B's typical quality while generating 25–35% faster, and neither has produced a twenty-minute answer.
And if you are staying on xhigh, a 12,000-token thinking budget halves the wait without truncating anything. That is the one lever we have actually tested.