Qwen 3.8 27B Needs 22,000 Tokens to Draw a Pelican

Alibaba's Qwen 3.8 27B open-weight vision model, released under Apache 2.0, takes 21 minutes and 22,276 reasoning tokens to draw a pelican riding a bicycle as an SVG, according to Simon Willison's testing on an M5 Max MacBook Pro and an NVIDIA DGX Spark. The model defaults to an 'xhigh' reasoning effort, causing excessive deliberation on simple tasks like drawing a circle, despite excelling at bounding-box tasks. Community members on Hugging Face and Willison's newsletter suggest lowering temperature to 0.7 to mitigate overthinking.

Qwen 3.8 27B dropped from Alibaba’s Qwen research lab, Apache 2 licensed, vision-capable, and sized right where a lot of us live: 27B parameters, small enough to run on a well-specced laptop, big enough to be useful. Its predecessor, Qwen 3.6 27B, was already a strong model. The self-reported benchmarks for 3.8 claimed real gains over it – and even over the closed-weight Qwen 3.7-Plus, according to Simon Willison’s writeup https://simonwillison.net/2026/Aug/16/qwen-38-27b/ . That’s the kind of release notice that gets bookmarked immediately. A 27B open-weight model beating a closed-weight sibling on paper is worth your afternoon. Then people actually ran it. 21 minutes for a pelican Willison’s now-standard benchmark for these releases is asking a model to draw a pelican riding a bicycle as an SVG. It’s not a serious capability test, but it’s a good stress test for how a model behaves when given a simple, bounded task. Qwen 3.8 27B took 21 minutes and 22,276 reasoning tokens to produce that SVG. Twenty-two thousand tokens of internal monologue to draw a bird on a bicycle. It gets weirder. Asked for a plain circle – about as low-stakes a graphics request as exists – the model reportedly turned it into an elaborate animated artwork instead of just, you know, drawing a circle. This wasn’t a one-off fluke either; it showed up across the hardware Willison tested on, an M5 Max MacBook Pro and an NVIDIA DGX Spark, which rules out the usual “must be a quantization issue” excuse. The frustrating part is the model is genuinely good underneath the overthinking. Testing found it excels at bounding-box tasks – real spatial reasoning, useful for anyone doing vision pipeline work. The intelligence is there. It’s just buried under a default behavior that treats every prompt like a math olympiad problem, including the ones that are just “draw a circle, please.” Why does it default to this? The model ships with a default reasoning effort setting of “xhigh.” That’s the root of it. Push a thinking model’s effort dial all the way up by default, and it will burn tokens deliberating on tasks that don’t need deliberation. A circle doesn’t need 22,000 tokens of internal debate. Nothing does, honestly, but a circle really doesn’t. One comment on Willison’s newsletter https://open.substack.com/pub/simonw/p/qwen-38-27b-is-excellent-but-it-defaults?comments=true , from a reader named Alec Pritzos, floated a theory worth sitting with: benchmark tables score accuracy, not latency. If you’re optimizing a model release for how it looks on a leaderboard, cranking the reasoning effort to xhigh is exactly what makes the numbers pop – and whoever runs it locally eats the 21 minutes. Nobody’s benchmark table has a latency column. Nobody’s shipping decision gets punished for shipping a model that thinks too long, only for one that thinks too little and gets an answer wrong. Whether or not that’s the actual internal reasoning at Qwen, it’s a plausible incentive structure, and it’s one worth remembering the next time a new “SOTA” open-weight release lands with eye-popping numbers and a reasoning knob nobody mentioned in the README. Another commenter, Barzin Lotfabadi, mentioned hearing that dropping the temperature to 0.7 helps with the overthinking – though by his own admission, he hadn’t tested it himself. Worth trying. Not worth trusting blind. The community already found the knobs Head over to the Hugging Face discussion thread https://huggingface.co/Qwen/Qwen3.8-27B/discussions/97 for this model and you’ll see the same complaint posted independently, multiple times, in almost identical language. A user named xuguowong: “This is a preview model i think, it always thinking and thinking, can it stop?” Another user, TAOTAO777, posted the exact same sentence five days ago. That’s not a coincidence – that’s a model shipping with a default that surprises everyone who touches it. The good news: there are real answers in that thread, not just commiseration. TAOTAO777 points to a --reasoning-budget N flag, where N is the number of thinking tokens you’re willing to spend. That’s the blunt instrument – cap it, and the model stops deliberating once it hits the ceiling, whether or not it’s “done” thinking. A user called vonamakitsune points out something more fundamental: the model ships with three thinking levels for a reason. If xhigh is the default and it’s wrecking your latency, you’re not stuck – you’re supposed to change it. That’s the framing that matters here. This isn’t a broken model. It’s a model shipped with a bad default, which is a very different problem with a very different fix. If you’re running Qwen 3.8 27B locally, that’s your starting checklist: - Drop the reasoning effort off xhigh. Try high or medium first and see if quality holds. - Set an explicit --reasoning-budget if your inference stack supports it, rather than trusting the model’s own sense of when it’s finished thinking. - Try temperature 0.7 if you’re still seeing runaway reasoning chains, with the caveat that this is anecdotal, not verified. - Don’t judge the model on its default config. Judge it on the config you actually ship with. Why this matters beyond one model We’ve been down this road before. If you’ve read our Qwen3-VL Integration Gotchas /posts/qwen3-vl-integration-gotchas-2e027bce post, you know the Qwen family in general ships with a lot of capability and a lot of sharp edges around exactly this – thinking traces, token budgets, and defaults that assume you’re benchmarking rather than serving production traffic. We run qwen3-vl:30b as a vision fallback role in our own pipeline. It’s a solid model for what we ask it to do – open-ended generative vision tasks, not just bounding-box classification – but we learned early that you cannot treat its thinking behavior as a free lunch. We have a setting in our production config, qa vision thinking num predict , capped at 8000 tokens specifically because letting a thinking-capable vision model run unbounded turns a QA check into a coffee break. That number isn’t arbitrary. It’s the result of watching jobs queue up behind a model that decided a straightforward visual QA task deserved a philosophical detour. We also maintain an explicit list of thinking model substrings in our settings – qwen3, qwen3.5, glm-4.7- ASUS ROG Astral RTX 5090 /go/asus-rog-astral-nvidia-geforce-rtx , deepseek-r1 – because our pipeline needs to know, ahead of time, which models are going to emit a <think block before the real output shows up. That list exists because we got burned by it. Reasoning tokens from models like glm-4.7-5090 and gemma4:31b were leaking into final outputs and getting flagged as broken content downstream, even when the underlying QA score was fine. We had to write a function – strip reasoning artifacts – specifically to catch and remove that leakage before it hit our content pipeline. That’s not a hypothetical problem. That’s a real bug we shipped a real fix for, because a thinking model’s internal monologue doesn’t always know where its own boundaries are. None of this means thinking models are bad. It means you can’t treat “reasoning effort” as a marketing checkbox. It’s a production variable, same as max tokens or temperature, and it needs a value someone chose on purpose, not the value the vendor picked to make a leaderboard look good. That’s also why we deliberately route our QA judge roles to qwen3.6 , a thinking model, on purpose. Reasoning quality matters more than speed when you’re scoring output, so we accept the latency cost there because the task justifies it. What we don’t do is let a thinking model default its way into every role in the pipeline. Vision fallback, video scene selection, slideshow prompts – those go to non-reasoning models like phi4:14b and gemma-4-31B-it-qat specifically because we don’t want to pay a reasoning tax on jobs that don’t need one. The lesson from Qwen 3.8 27B’s xhigh default is the same lesson we already learned the hard way: reasoning effort should be a role-by-role decision, not a global default inherited from whatever the model shipped with. The gap between “excellent” and “usable” Here’s the uncomfortable part of this story. Qwen 3.8 27B is, by every account, a genuinely strong model. The benchmark gains over 3.6 27B are real. The bounding-box performance is real. The vision capability at 27B parameters, Apache 2 licensed, running on a laptop, is a genuinely useful thing to have in the world. And none of that matters if the default configuration makes it unusable for anyone who isn’t specifically benchmarking it. That’s the split worth internalizing: “excellent” describes the model’s ceiling. “Usable” describes what you get out of the box. Those are two different questions, and a release announcement will always answer the first one. It’s on you – on us, on anyone actually deploying these things – to answer the second one before you commit a model to a pipeline. We wrote about this exact dynamic in The Offline Revolution /posts/the-offline-revolution-why-local-llms-are-the-back-1a51d7e0 : local models keep getting more capable, and that capability keeps arriving bundled with new categories of operational overhead that never show up in the release notes. Reasoning effort defaults are just the latest version of that pattern. A year ago it was context window management. Before that it was quantization artifacts. The capability curve keeps climbing. The list of things you have to check before trusting a default keeps climbing right alongside it. If you’re evaluating Qwen 3.8 27B for a real workload, don’t run it out of the box and judge it on that. Run it once out of the box to see the failure mode for yourself – it’s instructive, honestly, watching a model turn a circle into an animation – and then go find the reasoning effort knob and the token budget flag before you make any decision about whether this model earns a slot in your stack. The HF thread has already done a chunk of that homework for you. Use it. What we’d actually do If we were slotting Qwen 3.8 27B into our own pipeline today, here’s the order of operations we’d follow, based on what we already know works for thinking models in production: First, don’t trust the shipped default for anything latency-sensitive. Treat xhigh the way we treat any unbounded thinking budget – as something to cap explicitly, not something to inherit. Second, set an actual token ceiling. We already do this for qwen3-vl in our own config, and there’s no reason to expect Qwen 3.8 27B needs different treatment. A ceiling doesn’t make the model dumber. It makes the model finish. Third, check your output pipeline for reasoning leakage before you trust anything downstream of it. If your QA or content pipeline flags outputs as malformed and the underlying content looks fine, check for a stray thinking block first. That’s exactly the bug we found and fixed with strip reasoning artifacts , and it’s a near-certainty with any model that has a <think tag in its vocabulary and a default set to maximum verbosity. Fourth, reserve the high-effort reasoning setting for roles where the latency cost is worth paying – judge roles, QA scoring, anything where getting the answer right matters more than getting it fast. Everywhere else, dial it down or route to a non-thinking model entirely. That’s not a criticism unique to Qwen. It’s the operating manual for every reasoning-capable open-weight model shipping this year. Qwen 3.8 27B just happens to be the one currently making that manual necessary, with a pelican SVG as the proof of concept. The takeaway Qwen 3.8 27B earns the “excellent” in its own headline. The benchmark gains over 3.6 27B are real, the vision performance holds up under independent testing, and a 27B Apache-2 model that competes with closed-weight alternatives is worth paying attention to regardless of what its default config does to your patience. But the default config is the thing you’ll actually experience first, and right now that default is xhigh reasoning effort applied indiscriminately to every prompt, simple or not. Twenty-one minutes and 22,276 tokens to draw a pelican isn’t a fluke of one bad prompt. It’s the shape of the whole model until you go in and change the setting yourself. So change the setting. Cap the reasoning budget, drop the effort level off xhigh, watch your output pipeline for leaked thinking tokens, and reserve the expensive reasoning modes for the roles that actually need them. We’ve had to build exactly this discipline into our own pipeline for other thinking models, and there’s no reason to expect Qwen 3.8 27B is the exception. The model is good. The defaults are the problem. Those are two separate facts, and only one of them is fixed with a flag.