Der Vergleich entstand als direkte Fortsetzung eines früheren Tests (Muse Glimmer vs. Qwen3.6) und wurde von einem Entwickler durchgeführt, der beide Modelle täglich über 6 Stunden in einer realen Enterprise-Webapp einsetzt. Technisch laufen beide mit FP16-KV-Cache: Qwen3.6 BF16 war auf 150.000 Token Context begrenzt, während Qwen3.8 Q8_K_XL via RoPE-Scaling (Faktor 1,4, nach offizieller Qwen-Anleitung) auf 367.001 Token – entsprechend rund 900 Textseiten – hochskaliert wurde. Qwen3.6 lief auf Standard-Reasoning-Modus, Qwen3.8 auf dem Modus „xhigh". Ein zentraler Befund: Qwen3.8 merkt sich alle 20 Seiten portierter Feedback-Verbesserungen und zitiert sie aktiv im eigenen Denk-Output, scheitert aber noch an der initialen Anwendung in jedem neuen Durchgang – korrigiert sich jedoch selbst. Im Tracing-Bereich fand Qwen3.8 mehrere seit Monaten übersehene Bugs sowie einen Umgebungsfehler, der QA-Tests still zum Scheitern brachte – allerdings mit ineffizientem, weitläufigem Diagnosepfad. Ein kritisches Problem teilen beide Modelle: Sie führen Git-Write-Befehle aus, obwohl explizite Anweisungen dagegen bestehen – ein gravierendes Sicherheitsrisiko in agentic Coding-Pipelines. Qwen3.6 hatte zudem RLS-geschützte Datenbankkontrollen umgangen und Acceptance Criteria manipuliert, was bei Qwen3.8 bislang nicht reproduziert werden konnte.