This is Unsloth's UD-Q4_K_S quantization (edit -- on llama.cpp, via the Vulkan backend, on an RX 7900 XT, with Unsloth's recommended sampler config), for "as replicable as LLMs can be" disclosure, done through llama.cpp's web UI. In another thread, via Open WebUI (both with no custom prompt, so whatever the "default" system prompt is), a reasoning block opens as such:
We need answer user's request: write complete short story scene 2000-3000 words, third-person limited with Rowan, no outline preamble analysis. Need satisfy plot elements: raccoon, Milo returns, storm power failure, elderly customer knocks, thermos somewhere. End scene feels finished. Need produce only story. Need think in English (user English). Need craft 2000-3000 words. Need no meta. Let's plan.
Now, I will add that when I use Qwen3.8 in a coding harness, the reasoning tends to NOT look like this, and instead looks more Qwen3.6-ish.
But when I give short prompts to Qwen3.8 with no system prompt or previous instructions, it seems to strongly gravitate towards grug-talk.
I just tried to reproduce in Llama-cpp's webui: with the following (reverse-engineered) prompt:
“Write a complete short story scene of 2000-3000 words. Use a third-person limited perspective focused on a character named Rowan. The scene must include the following plot elements: a raccoon, Milo returns, a storm power failure, an elderly customer knocks, and a thermos somewhere. Make sure the scene ends feeling finished. Output only the story; do not include any outline, preamble, analysis, or meta-commentary.”
And here's Qwen's thinking trace:
> The user is asking for a short story scene of 2000–3000 words. Third-person limited POV, Rowan. Plot elements: a raccoon, Milo returns, a storm causing a power outage, an elderly customer knocks on the door, a thermos. End with a sense of closure. Output only the story.
> Let me plan carefully. I need to count words in my head—roughly 2400–2600 words would be safely in range. Let me draft.
> Setting: a small-town shop or a gas station/diner where Rowan works the night shift. Milo returns—Milo is probably Rowan's partner, brother, or ex. Let me make Milo Rowan's brother who's been away (military? a road trip? rehab?). Better: Milo is the younger brother who disappeared/went away after a fight. He comes back in the middle of a storm.
While at the very beginning it rephrases the prompt in very short sentence, it's nowhere near close to the above GPT thinking trace and it quickly moves to plain sentences.
Yeah, I dunno. For me it does "talk normally" for the most part when used in an actual coding harness.
One thing though, the actual prompt I used was pretty long (844 words), and ... generated by GPT-5.6 Sol (lol), with the intent of "benchmarking" model performance in being able to write stories where the model avoids explicitly stating every detail in the prompt.
I wonder if the GPT-produced stream could steer the generation into GPT-think territory. That's all I've got, though.
Then there's the actual geometry problem from the stolen thoughts paper:
Let ABCDE be a convex pentagon with AB=14, BC=7, CD=24, DE=13, EA=26, and ∠B=∠E=60◦. For f(X)=AX+BX+CX+DX+EX, the least value of f(X) is m+n√p (p squarefree). Find m+n+p.
I think it is clear that medium reasoning has more 'loopy' results like the older Qwens, but I actually think the low effort results are usually more appropriate.
If you plan to one-shot and vibe code AI slop to meet benchmarks, maybe xhigh makes sense. But if you want a responsive agentic coding assistant it is, to me, quite evidently the wrong choice, especially on modest hardware.
I have seen xhigh radically distract itself with rabbitholes and write considerably worse code than low.
It is my own opinion only, but I think much of the fuss about squeezing Qwen 3.8 27B into small local hardware setups, Macs etc., is a bit misguided.
There's too much focus on its benchmark scores, its one-shot capability, canned demos etc.
For my own needs Muse Glimmer (again on reasoning strength: low) is shaping up to being the more practical agentic tool. It is considerably faster than Qwen at solving real coding tasks.
IMHO, xhigh makes sense if you want a slower Opus4.6 at home. It is able to complete tasks autonomously in a way that I've never seen another local model do.
But yes, for simpler tasks or more hands coding sessions, it's simply not the best model out there as its verbosity makes unbearably slow.
Muse Glimmer has some interesting and it seems reasonably daring trade-offs in its architecture (that I wish I understood better) that seem to favour longer agentic “dialogue”, and it is just much more nimble all round, even though it’s a larger model.
Don’t get me wrong, I have spent time speccing out a box that I could use to run Qwen 3.8 27B better, and I am very glad it exists, as I am with the Gemma series. We have really an embarrassment of riches at the 32GB VRAM level already.
I just think maybe Meta have the more appropriate strategy (can’t believe I am saying this) for desktop AI.
The person evaluating and noticing similar reasoning traces to gpt is because they are using a coding harness which probably has a different system prompt to llama webui which primarly serves as a chat interface
You can, it's kind of cool to have this capability on something gaming at such a low price tag. Its not optimal for your time but beats nothing by a LOT. And that model is pretty reliable.
It just depends how far through the eye of the needle we already went, and how far we have to go. I don't want to go backwards. Humans are adapting, always locally, and never uniformly.
Although it can be annoying to step into someone else's situational language/definitions/grammar, it can be a good rhetorical trick to shed the preexisting cultural context of a preexisting term such as depth.
Absolutely. I have an independent audit pass to verify claims.
My methodology consists of launching a 242 cell parallel code review matrix and committing all Fable/Sol max effort agent prompts and their full reports to a private orphan branch on the repository. This is the part that is taking me months to complete. This thing can kill my $100 subscription in about 12 hours.
When done, these raw findings will be semantically deduplicated and merged into a list of findings per model. This list will then be audited for hallucinated or otherwise made up findings. This will refine the list, and hallucination rate is its own data point. I'm also counting things like cybersecurity refusals and downgrades.
When all this is done, I'll analyse the final results and publish them on my website.
Some preliminary analysis:
Which code review lenses were the most valuable, where value is defined as number of serious issues identified? Rigor, followed by tests, robustness, correctness, and so on. I was able to create a tier list of reviewer personas using evidence! I can now run focused code reviews using the highest value lenses.
What's the most expensive code review? Correctness and rigor, of the lone lisp machine specifically.
API costs per finding? $0.91 to $3.77. API costs per serious finding? $8.94 to $28.51. All Fable.
How long did it take? 28.2 calendar days, 66.3 agent-hours.
Is it worth it to run the code review multiple times? If a review matrix's defect capture probability is 57%, then a second run captures 81% of the estimated/extrapolated defect population, a third run captures 92%, a fourth run captures 97%, and further runs yield severely diminishing returns. Probably worth it to code review important stuff three times.
What's the impact and cost of the safety classifier? Out of the 52 Fable review cells that triggered the safety classifier, 35 died without producing any output whatsoever, so 67.3% of the cells were a complete waste of tokens. 25% produced at least some output.
Does the safety classifier trigger most often on the important code that actually needs SOTA models? For the most part, yes. Fable was most often barred from reviewing the most important and complex files in the codebase, such as the virtual machine, the parser and I/O layer. These files also have the most CRITICAL+HIGH severity findings. Only a couple outliers broke this pattern.
LLMs are set to.increase hardware demands a lot. Although I don't necessarily think this is related to the program change.
I know this comment is deep in a thread, but to me it looks like they simply prefer to own the whole apple device payment cycle and not use partners.
BNPL has been a huge bubble outside the traditional credit bubble, this is the same. It doesn't seem like a big divergence excepting that it gives them a contact point and a stick with which to prod customer into a new phone sooner.
