Qwen 3.8 - Local AI xHigh Thinking is SCARY 🤯

Summary of technological concepts, product features, and findings

What the video tests

• Qwen 3.8 “extra high thinking” mode with “all the prompts,” focusing on how well it generates:
  • Large WebGL/GLSL code
  • Interactive 3D/game UI
  • when run locally.
• The creator uses massive token budgets (e.g., ~20k up to 140k–200k tokens) and compares:
  • Quantization levels: Q4, Q8, Q9, Q10
  • Sampling/temperature: temperature 0 vs 1
  • Different inference backends/engines (and also a base MLX VLM test)
  • “Thinking loops” behavior and how to mitigate them

Key problem: “thinking loops”

• The model sometimes enters a thinking loop, repeating the same thoughts/code many times.
• Effects:
  • Very high token usage (e.g., 100k–200k tokens)
  • Eventual runtime errors or degraded/unchanged output
• The video emphasizes that more tokens doesn’t guarantee better results if the model is looping.

Main feature/solution: “thinking loop detection”

• The creator uses a feature called a “thinking detector” (and mentions “expanded thinking detection”) that:
  • Detects repeated thinking iterations
  • Gracefully exits when a loop is found
• Practical outcomes:
  • Prevents wasted generation tokens during speculative/extra-high thinking
  • Example: a loop scenario that otherwise ran ~200k tokens can be reduced to roughly ~23k tokens with loop detection, while still producing good results

Quantization findings (Q4 vs Q9/Q10)

• Q4
  • Often runs but shows more runtime errors in generated WebGL/GLSL shader/code
  • Example: after ~50k tokens, looping was detected and loop detection exited early
• Q9
  • Generally “luckier” / better quality with fewer visible failures in tested cases
• Q10
  • Can produce impressive output, but at:
    • much higher token cost
    • slower runtime
  • Also saw issues like an error (e.g., “error 17”) where the model might remake the error or avoid/fail to correctly apply fixes later
  • Q10 runtimes were described as extremely expensive on a Mac (multi-hour scale for very large generations)

Temperature/sampling findings

• Temperature 0
  • Described as “database-like” / more deterministic
  • Generally better for code generation
• Temperature 1
  • Caused worse looping behavior (“crazy loop”), even on models/backends tested
• Mitigation suggestion:
  • Don’t rely on temperature randomness to escape loops
  • Use thinking loop detection instead

WebGL/GLSL runtime errors and correction behavior

• The creator repeatedly observes shader/code errors such as:
  • Undeclared identifier
  • GLSL / WebGL shader issues
  • “Null is not an object”
  • “three buffer geometry compute bounding sphere”
  • Nonfinite value at a specific line number (e.g., line 250)
• Important correction behavior:
  • When asked to “fix” errors, the model sometimes claims it fixed them but doesn’t, or it introduces new issues
  • In some experiments, feeding the error back helps, but repeated prompting may be needed

“Thinking limits” / stopping early

• The creator tests restricting thinking via a token limit for thinking.
• Result:
  • The model often stops gracefully around a reasonable thinking token count (e.g., ~8k)
  • Produces fewer total tokens and reduces loop risk compared to fully unconstrained extra-high thinking

Overall evaluation by task type (what worked / didn’t)

• Procedural face / MLX VLM-like UI demos
  • Extra-high thinking sometimes works “out of the box” with good results
  • But visual artifacts appear (e.g., hair/ears/geometry glitches)
• 3D human anatomy UI
  • Low thinking produced a good anatomy viewer
  • Extra-high thinking:
    • used more tokens (~67k)
    • avoided loops
    • but still had UI/logic bugs (e.g., organs appearing/disappearing; missing connections)
• Game prototypes (3D platformers, GTA-like, Red Dead style, Final Fantasy-like, Mario-like, Outrun-like)
  • Low thinking can be buggy/broken or have runtime errors
  • Extra-high thinking can improve breadth/scale, but:
    • risks loops and errors
    • may require detectors and/or multiple correction prompts
  • The model can generate impressive starter UI and interactive scenes, but is not reliably complete for full gameplay loops

Performance/compute observations

• Very large token runs can take hours locally (on a Mac).
• Reported throughput:
  • ~27 tokens/sec with MTP (possibly higher/lower depending on debug settings)

---

Main speakers / sources

• Main speaker: the video creator (“Hey guys… welcome to the show”), running local experiments with Qwen 3.8 and testing quantizations Q4/Q8/Q9/Q10, plus MLX VLM and different engines.
• Model tested: Qwen 3.8 (local), including a base MLX VLM comparison in one test.