My Laptop Just Sat There Thinking
How Qwen 3.8's default settings produced 21 minutes of nothing

Opening
Reader, last weekend I downloaded an open model onto my laptop. It was Qwen 3.8 27B, which Alibaba released on the 14th. The file was 17GB. It struck me as remarkable that a model capable of coding, reading images, and calling tools could run in less space than a modern video game, so I grabbed it right away.
But I typed in a question and waited, and waited, and no answer came. The screen just kept spinning with a “thinking” indicator. Running it as a gguf, running it as an mlx build on my Mac — same result either way. It sat there in some ambiguous state where I couldn’t tell if it had crashed or simply timed out.
As I dug into the cause, I realized the model itself wasn’t broken. The default settings simply hadn’t been calibrated for someone like me. Let me tell you where this is going. Today’s story isn’t a bug report on one particular model. It’s a story about who AI products’ defaults are actually set for.
The article is well-translated with accurate numbers and no issues found.
I Asked It to Draw One Circle. It Sent Me an Art Piece.
Let’s start with the symptoms. I wasn’t the only one who ran into this.
Developer Simon Willison published a record on the 16th of running the same model on two different machines — a 128GB MacBook Pro and an Nvidia DGX Spark, both running the same 17GB 4-bit quantized1 build.
The first prompt he threw at it was a classic: draw a pelican riding a bicycle, in SVG. The result, he said, was the best he’d ever gotten out of a local model. The bike frame was proportioned correctly, there was a leg on each side, and the wings reached all the way to the handlebars.
The problem was that it took 21 minutes to produce that result. It burned through 22,276 tokens of reasoning to output just 3,223 tokens — the thinking was seven times longer than the output. Running the same prompt with reasoning turned off finished in 137 seconds. The quality dropped, but by his own assessment, not by 21 minutes’ worth.
The next experiment was even more telling. This time he made an intentionally simple request: draw a single circle, in SVG. The model’s chain of thought opened like this:
This is a simple request, but I want to go beyond a bare circle tag and make something crafted — a kind of geometric study, with subtle animation, layered rings, and a distinctive color palette.
A few minutes later, out came an animated figure with concentric guide lines, tick marks, gradients, and a slowly rotating dashed ring. It was beautiful. It was not what had been asked for.
The same tendency showed up in coding tasks too. When he asked for a simple web tool that draws a coordinate box over a photo, the model tacked on features nobody had requested. For users without a test photo on hand, it had gone ahead and drawn its own sample image so the tool would have something to demo. Its chain of thought includes the line: “this would be fun since it’s self-contained and demoable.” An unsolicited kindness.
This is also where the freeze I experienced branches off from his. Willison wrote that he hit a wall almost immediately at LM Studio’s default context limit of 8,192 tokens — the model would burn through that entire budget on pure thinking, even for the most trivial question. Once he raised the limit to 262,144 tokens, the problem disappeared. It wasn’t that the model couldn’t produce an answer. It was that there was no room left to produce one.
This default isn’t a mistake
Most articles move on from here to “the Chinese model’s polish problem.” I think that reading is wrong. This isn’t a mistake — it’s the result of a rational choice.
Qwen 3.8 officially supports a setting that controls reasoning depth. There are three levels — xhigh, medium, low — and the default is the highest, xhigh. The documentation even states it’s meant for thorough analysis on complex tasks.
Why would they set this as the default? The answer becomes clear once you look at the benchmark testing conditions.
The model card for the previous generation, Qwen 3.6, discloses its evaluation conditions in detail. The terminal-task benchmark ran with a 3-hour timeout, 32 CPUs, 48GB of RAM, a maximum output of 80,000 tokens, and a context window of 256,000 tokens, averaged over 5 runs. The software engineering benchmark used a proprietary agent harness2 with a 200,000-token context.
Under these conditions, the optimal strategy is obvious: think as long and as deep as possible. There’s no reason to finish in 3 minutes when you’re given 3 hours. The grader isn’t looking at how much time you took — only whether you got it right.
And that strategy worked. By Qwen’s own published figures, 3.8 improved over the previous generation by 10 points on the terminal benchmark, 20 points on computer-operation evaluation, 16 points on web tasks, and 12 points on Android tasks. These are self-reported numbers measured on a single harness, so some caution is warranted, but the direction is clear.
Now let’s set the user’s conditions side by side. A single laptop, a default context of 8,192 tokens, one attempt, and at most a few minutes of patience. The same setting is optimal on one side and a disaster on the other.
What’s interesting is the community’s reaction. Even though 3.8 leads on benchmarks, local users still call 3.6 — released 4 months earlier — their daily driver. The reason: 3.6 is calmer and doesn’t spiral off into tangents. In fact, 3.6 has racked up over 7 million downloads in those 4 months. The scoreboard’s winner and the real-world winner are diverging.
The Trade-off Vendors Left in Knowingly
There’s one more piece of evidence that the defaults point toward the scoreboard. This time, it’s written right into the documentation.
The Qwen 3.8 model card includes this note: if you run into endless repetition, try raising the repetition penalty3 to somewhere between 0 and 2. And in the very next sentence, it warns that raising this value can intermittently cause language mixing and a slight drop in performance.
I think these two sentences sitting side by side capture the character of this release more precisely than anything else. It means the vendor knew that the fix for looping creates a different symptom—and shipped it anyway.
In practice, I’ve seen Japanese and Arabic words bleed into answers when I asked questions in Korean. There’s research worth citing on why this happens. A paper quantifying language mixing in bilingual reasoning found that when a reasoning model was asked math problems in Chinese, 77.4% of its answers showed language mixing, switching languages an average of 7.22 times per problem. When asked in English, that figure was 0.6%. This tells you the dominant language of thought for this model family is English.
Put differently, Korean-language users are structurally positioned to hit this failure mode more often. Yet this failure has no column on any benchmark table. If it isn’t measured, there’s no reason for it to shape default design either.
And there’s another layer stacked on top of this. The default problem isn’t confined to the model itself.
One user’s log of running the same model in various configurations all day showed a tenfold-plus spread on a single RTX 5090—from 12 tokens per second up to 137. And in setups where a feature that speculatively predicts multiple tokens ahead to speed things up4 was enabled, every run timed out. The user themselves noted this was a runtime-environment compatibility issue, not the model’s fault. By contrast, Simon Willison attached the same feature and got results 72% faster than the base build.
The same feature is a 72% boost for one person and a total standstill for another. There’s a good chance the freezes I ran into on both GGUF and MLX trace back to exactly this. The real-world performance of an open-weight model isn’t determined by the weights alone—it’s determined by the runtime stack layered on top of them, and the party that sets that stack’s defaults is yet another separate entity. The team that built the model, the team that uploaded the quantized build, and the team that built the inference tool are all different groups. None of them set their configuration with my laptop in mind.
If you happen to be running this model yourself right now, here’s the order I’d recommend: raise the context limit generously first, lower the reasoning level to curb overthinking, and explicitly set the top-k sampling parameter5 to 20. Save the repetition penalty as a last resort for stopping loops—because that’s exactly the value that triggers language mixing.
In fairness, though, I should add something. Overthinking isn’t unique to this model. In community experiments, Google’s Gemma 4 26B actually used even more tokens on the same questions. And on Hugging Face, there’s an ongoing, unresolved argument between people claiming this is a structural flaw in the weights themselves and others rebutting that the analysis behind that claim was fabricated—no conclusion yet. And this despite the fact that the weights are fully open.
Oswald’s Perspective
I’ve sat through more than a few meetings where a GTM strategy hinged on fighting over a product’s default settings. And every time, the same pattern shows up.
Two pressures always converge on the room where defaults get decided. One side argues for “let’s make sure a first-time user succeeds.” The other argues for “let’s keep ourselves looking as good as possible.” The second side wins more often than you’d think. The configuration that looks best in a demo, the one a reviewer will boot up, the one that wins the comparison chart — that becomes the shipped default.
The problem is that this choice leaves no trace. Nothing was removed, no performance number was faked. It’s just a matter of where one setting gets placed. But from a user’s standpoint, the default is effectively the product itself. Most people never open the settings screen.
So I’ve come to read the default as the most honest signal of who a product was actually built for. Marketing copy is written for everyone, but a default can only pick one person.
What makes this case interesting is how unusually sharp that signal is. For an open-weight model, the benchmark table is practically the only competitive lever available. With no sales force, no distribution deals, no user data to lean on, it has to prove its existence with a single leaderboard. For a company in that position, choosing a default tuned to the scoring conditions isn’t strange at all — it’s practically what the structure demands.
But understanding that structure and simply going along with it are two different things. This week, I learned exactly that — through 21 minutes and a handful of pauses.
Closing
Three lines to sum it up:
- Qwen 3.8 27B’s default reasoning setting is the highest tier available. Ask it to draw a single circle, and it produces a whole composition; in a narrow context window, it leaves no room to actually deliver an answer.
- This isn’t a mistake — it’s a choice calibrated to grading conditions. In a benchmark that allows a 3-hour timeout and 80,000 tokens of output, thinking longer wins.
- A user’s constraints are the opposite. That’s why the leaderboard winner and the real-world winner diverge, and why a model from four months ago is still someone’s daily driver.
This one question is useful well beyond this particular model. Open whatever AI tool you’re using right now and take a look at its settings screen. Was this default set for me, or for whoever is evaluating this product? More tools than you’d expect will give you two different answers.
Reader, have you ever taken a hit from using an AI tool on its default settings? Tell me in the comments which tool, which setting, and what changed once you switched it. If enough cases come in, I’ll pull them together in a future issue.
💬 Tell me in the comments about something that happened to you because of a default setting · 📨 If you know a colleague evaluating local models, forward them this piece
Looking at the fragment, I’ll compare it against the Korean source for accuracy.
References & Further Reading
Primary sources
- Simon Willison, “Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things”, Simon Willison’s Weblog, August 16, 2026. Link ··· This is the source for the 21 minutes and 22,276 tokens. The full chain-of-thought log from the circle-drawing case is linked here — even if you read nothing else, open that.
- Qwen, “Qwen3.8-27B Model Card”, Hugging Face, August 14, 2026. Link ··· The original text where the reasoning-step default and the presence-penalty warning appear. A good way to check what the vendor actually knew.
- Qwen, “Qwen3.6-27B Model Card”, Hugging Face, April 2026. Link ··· The 3-hour timeout and the 80,000-token benchmark condition are documented here. This is the core evidence behind today’s piece.
- “Why Qwen3.8-27B overthinks? Here the reason”, Hugging Face Community Discussion #76, August 2026. Link ··· A thread where claims of a structural flaw and rebuttals go back and forth. It’s also a case study showing that even when the weights are public, there’s no consensus on the behavior.
Background
- Yihao Wang et al., “The Impact of Language Mixing on Bilingual LLM Reasoning”, arXiv:2507.15849, 2025. Link ··· The source for the 77.4% and 0.6% language-mixing rates. It explains why non-English users end up with a different experience.
Related past issues worth reading together
- A Perfect Score at the Math Olympiad, But No AI Referee ··· That piece argued you should look at the grading process, not the score. Today’s piece sits right next to it, on the topic of measurement conditions.
- Google Shrank the Invoice Instead of the Price Tag ··· That piece covered why how many tokens a single task burns through has started to matter. If you’re curious what those 21 minutes really amount to, read it alongside this one.
📝 Glossary
Footnotes
-
Quantization: The process of reducing a model’s numbers to lower precision to shrink file size and memory usage. It’s similar to saving a high-resolution photo at slightly lower quality. This is how a 27B model shrinks down to 17GB and fits on a laptop. ↩
-
Harness: The outer shell that wraps a model during evaluation or execution. It decides which tools the model can use, how many attempts it gets, and when to stop. The same model can score differently under a different harness. ↩
-
Presence penalty: A setting that lowers the probability of an expression reappearing once it has already been used. It reduces the symptom of a model repeating the same phrase over and over, but if set too high, the model avoids its usual word choices and sometimes picks words from an entirely different language instead. ↩
-
MTP (Multi-Token Prediction): A method where a lightweight component pre-guesses several upcoming words and the main model just quickly checks whether the guesses were right. When it works well, speed improves dramatically — but if the runtime environment doesn’t properly support this feature, it can instead cause the model to stall. ↩
-
top_k: A value that determines how many candidates, ranked by probability, are kept when choosing the next word. If this isn’t limited, even extremely low-probability, rare words remain in the candidate pool — which occasionally causes an unexpected character to pop out. ↩



Your take shapes the next issue
What resonated most in this issue, or where has your experience been different?