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.<\/p>\n
The short version: Qwen 3.8 27B ships with its reasoning effort defaulted to If you haven’t tried this since the early Llama days, the bar has moved. I’m running the model through LM Studio<\/a> 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.<\/p>\n 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.<\/p>\n Simon Willison documented the same problem<\/a> the same weekend I ran into it: Qwen’s own documentation describes the model as defaulting to This matters more locally than it does against a hosted API, because you feel the cost directly as latency. On the DGX Spark, a Qwen 3.8 27B supports That single field is the whole fix. I now default new sessions to Once I noticed it in Qwen, I started checking for it everywhere. OpenAI’s o-series and GPT-5 family expose a 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.<\/p>\n 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 The failure mode isn’t using 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 Qwen 3.8 27B defaults to maximum reasoning effort on every prompt, even simple ones. Here’s how to run it locally, spot the setting, and control costs.<\/p>\n","protected":false},"author":2,"featured_media":590,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Qwen 3.8 27B defaults to maximum reasoning effort on every prompt, even simple ones. Here's how to run it locally, spot the setting, and control costs.","rank_math_focus_keyword":"run llm locally","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[4],"tags":[33,5,646,313,394],"class_list":["post-591","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","tag-ai-engineering-2","tag-llm","tag-lm-studio","tag-local-llm-2","tag-qwen"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/591","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=591"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/591\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/590"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=591"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=591"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=591"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}xhigh<\/code>, 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.<\/p>\nWhat “run an LLM locally” means in mid-2026<\/h2>\n
The default that was quietly burning my afternoon<\/h2>\n
xhigh<\/code> for reasoning effort, and the LM Studio build he tested preserved that default. xhigh<\/code> 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.<\/p>\nxhigh<\/code> response to a trivial prompt took noticeably longer than a low<\/code> 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.<\/p>\nTurning the dial down, in practice<\/h2>\n
reasoning_effort<\/code> 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:<\/p>\n# Before: defaults to whatever the model ships with (xhigh, in this case)\nimport requests\n\nresponse = requests.post(\n "http:\/\/localhost:1234\/v1\/chat\/completions",\n json={\n "model": "qwen3.8-27b",\n "messages": [{"role": "user", "content": "What's 15% of 340?"}],\n },\n)\n<\/code><\/pre>\n# After: explicit reasoning effort, matched to the actual task\nresponse = requests.post(\n "http:\/\/localhost:1234\/v1\/chat\/completions",\n json={\n "model": "qwen3.8-27b",\n "messages": [{"role": "user", "content": "What's 15% of 340?"}],\n "reasoning_effort": "low",\n },\n)\n<\/code><\/pre>\nmedium<\/code> and only bump to high<\/code> or xhigh<\/code> 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<\/a> exposes the same idea for Gemini 3.7 Flash through his llm<\/code> CLI tool: llm -m gemini-3.7-flash -o reasoning_effort low<\/code>. 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.<\/p>\nThis isn’t just a Qwen thing<\/h2>\n
reasoning_effort<\/code> 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<\/code> tool, takes a similar -o reasoning_effort<\/code> 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.<\/p>\nWhen you actually want the expensive setting<\/h2>\n
xhigh<\/code> trace caught something a low<\/code> 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<\/a>. 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.<\/p>\nxhigh<\/code>. 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.”<\/p>\nTry this on your own local setup this week<\/h2>\n
low<\/code> 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.<\/p>\n","protected":false},"excerpt":{"rendered":"