Confession: I downloaded Qwen 3.8 27B on Friday night expecting a quick benchmark and instead spent forty-five minutes watching a single reasoning trace scroll past before I got an answer to “what’s 15% of 340.” Fifteen percent of 340 is 51. I did not need six paragraphs of the model second-guessing itself to get there. I closed LM Studio, made tea, and came back annoyed enough to actually figure out why.
The short version: Qwen 3.8 27B ships with its reasoning effort defaulted to xhigh, and if you don’t know that setting exists, you’re paying for it in tokens and wall-clock time on every single request, including the ones that don’t need it. Here’s what running an LLM locally actually looks like right now, and the one setting that determines whether it’s usable or maddening.
What “run an LLM locally” means in mid-2026
If you haven’t tried this since the early Llama days, the bar has moved. I’m running the model through LM Studio on two machines: a 128GB M5 Max MacBook Pro and an NVIDIA DGX Spark, using the 17GB Q4_K_M quantized build. Both handle it fine. You don’t need a rack of GPUs for a 27B model anymore. A well-specced laptop from the last two years gets you there, especially with a quantized build instead of the full-precision weights.
The workflow is genuinely simple now: download LM Studio, search for the model in its catalog, pick a quantization level, and load it. No Python environment, no CUDA driver archaeology. That’s the part that’s improved the most since I last wrote about local models. The part that hasn’t improved is that every model ships with its own opinions about how hard it should think before answering, and those opinions are not always yours.
The default that was quietly burning my afternoon
Simon Willison documented the same problem the same weekend I ran into it: Qwen’s own documentation describes the model as defaulting to xhigh for reasoning effort, and the LM Studio build he tested preserved that default. xhigh means the model deliberates at maximum depth on every prompt, whether you asked it to summarize a paragraph or solve a genuinely hard problem. For a simple arithmetic question, that’s the equivalent of hiring a consultant to write a full report before telling you the answer to a yes-or-no question.
This matters more locally than it does against a hosted API, because you feel the cost directly as latency. On the DGX Spark, a xhigh response to a trivial prompt took noticeably longer than a low one for the exact same question, with no meaningful difference in correctness. On a laptop under battery power, that difference is your fan spinning up and your afternoon disappearing.
Turning the dial down, in practice
Qwen 3.8 27B supports reasoning_effort as an explicit parameter, and most local tooling exposes it the same way the big hosted APIs do. Here’s the difference between the request I was sending without thinking about it, and the one I send now:
# Before: defaults to whatever the model ships with (xhigh, in this case)
import requests
response = requests.post(
"http://localhost:1234/v1/chat/completions",
json={
"model": "qwen3.8-27b",
"messages": [{"role": "user", "content": "What's 15% of 340?"}],
},
)
# After: explicit reasoning effort, matched to the actual task
response = requests.post(
"http://localhost:1234/v1/chat/completions",
json={
"model": "qwen3.8-27b",
"messages": [{"role": "user", "content": "What's 15% of 340?"}],
"reasoning_effort": "low",
},
)
That single field is the whole fix. I now default new sessions to medium and only bump to high or xhigh for problems where I actually want the model to show its work: debugging a gnarly regex, checking a proof, that kind of thing. Simon Willison’s llm-gemini plugin update exposes the same idea for Gemini 3.7 Flash through his llm CLI tool: llm -m gemini-3.7-flash -o reasoning_effort low. Different vendor, same underlying knob, and it’s becoming a fairly standard part of the API surface for reasoning models. If you’re scripting against any of them, check for it before you assume the default is the right one.
This isn’t just a Qwen thing
Once I noticed it in Qwen, I started checking for it everywhere. OpenAI’s o-series and GPT-5 family expose a reasoning_effort parameter with roughly the same low/medium/high shape. Anthropic’s extended thinking uses a token budget instead of a named tier, but the effect is identical: you’re paying for deliberation whether or not the question needed it. Google’s Gemini 3.7 Flash, through Simon Willison’s llm tool, takes a similar -o reasoning_effort flag now that reasoning traces are exposed. None of these vendors default to the cheap setting, because a wrong answer generates a worse headline than a slow one.
That’s a reasonable choice for a vendor shipping a general-purpose API to millions of people who never read the docs. It’s a bad default for you, specifically, once you know your own workload. A support-ticket triage prompt and a “debug this race condition” prompt are not the same task, and they shouldn’t cost the same number of tokens. If you’re building anything that fires off more than a handful of LLM calls a day, spend the ten minutes to check whether the model you’re using exposes this knob, and set it per call site instead of accepting whatever the SDK defaults to.
When you actually want the expensive setting
I don’t want this to read as “always turn reasoning down,” because that’s not true either. When I gave Qwen a genuinely hard task, finding a race condition in a chunk of Go code I fed it, the xhigh trace caught something a low response missed twice. The reasoning tokens weren’t wasted there; they were the entire value of running a 27B reasoning model instead of a smaller, faster one. I wrote more about that trade-off when comparing small models against full-size LLMs. The short version is that the right model size and the right reasoning depth are two separate decisions, and defaults rarely get both right for your specific workload.
The failure mode isn’t using xhigh. It’s not knowing it’s on, and paying the same tax for “summarize this email” that you’d pay for “find the bug in this concurrency code.”
Try this on your own local setup this week
If you’re running any reasoning model locally, whether it’s Qwen, DeepSeek, or one of the Gemini Flash variants through an API, go check what its default reasoning effort actually is. Run the same trivial prompt at low and at whatever the default happens to be, and time both. If you can’t tell the difference in output quality but you can absolutely tell the difference in wait time, that’s your answer: the default was never for you, it was a safe-but-expensive setting the model vendor picked so nobody complains about wrong answers. Set it explicitly per request instead of trusting the factory setting, and you’ll get most of your afternoon back.
