Model Releases
Tested in Coding: Q8_K_XL Qwen3.8 27B vs BF16 Qwen3.6 27B
Further to my last post, https://www.reddit.com/r/LocalLLaMA/comments/1vldngi/tested_in_coding_bf16_muse_glimmer_vs_bf16_qwen36/, I bring this requested comparison of Qwen3.8 27B. Context: Both models
Further to my last post, https://www.reddit.com/r/LocalLLaMA/comments/1vldngi/tested_in_coding_bf16_muse_glimmer_vs_bf16_qwen36/, I bring this requested comparison of Qwen3.8 27B. Context: Both models are running at full FP16 KV-cache. Due to RAM limitations, BF16 Qwen3.6 was running at 150,000, whereas Q8 Qwen3.8 is running with rope-scale 1.4 (using official Qwen guidance) to reach a context of 367,001 - this is equivalent of approx 900 pages of context. Qwen3.6 was on the default reasoning. Qwen3.8 is running on xhigh. Both models have been working on an enterprise-grade web application. Qwen 3.6 was working on tasks when the average context was approximately 120,000. Now the tasks have ballooned to average 280,000 context. Coding work has been 6+ hours per day since the release date of Qwen3.8. TLDR: Muse Glimmer is completely obsolete as a coder. Q8 Qwen3.8 is stronger than BF16 Qwen3.6 in all respects except for one - a critical one - as highlighted below. Instructions Qwen3.8's greatest strength is its ability to read, interpret, recall and follow instructions. With the release of the latest model, I ported 20 pages of feedback improvements from Qwen3.6 to Qwen3.8. Qwen3.6 would often ignore the improvements. Whereas Qwen3.8 remembers every single one, and even cites the improvements it in its thinking. Note however that each round, Qwen3.8 still often fails to follow the improvement for an initial instance, but then self-corrects for the remainder of the round. Diagnostic Qwen3.6 was already strong in diagnostic capability, however it had a major integrity issue of relaxing security controls to perform troubleshooting, and editing Acceptance Criteria to make failed tests pass. Qwen3.8 is even stronger on diagnosis - and has corrected a frontier model (eg. Chat GPT / Opus) on multiple occasions. Both models are genuinely strong at diagnosis, but still share a common issue of not sanity-checking against a known baseline or diagnostic script output before reporting, with this issue being more mitigated in Qwen3.8. Tracing This is the clearest strength for Qwen3.8, with there being substantial evidence. It has found genuine pre-existing bugs that have been missed for months, and even an environmental error that had been causing a QA test to silently fail for months. The weakness of Qwen3.8 is tracing inefficiency - whilst it does ultimately reach the right conclusion in nearly all instances - it does create many initial diagnosis postulations which are off the mark. It does tend make "detours" in the tracing - so that the investigation takes much longer than needed. I have seen other users in this Reddit call this "thinks way too much", but it is indeed very thorough. Coding Even where implementation is tightly scoped, Qwen3.6 would apply regularly fixes too broadly, only for these to be picked up in QA - following which it would generally be able to correct and not repeat the issue. This meant that Qwen3.6 would tend to over-generalise the scope of the coding, leaving the onus to the agentic testing framework to identify the defects. If the framework failed to pick it up, then defects would be riddled throughout the code. This actually occurred quite frequently. Qwen3.8 thinks much more, and even when coding a simple function will make more than 5 independent checks through the codebase. It does take much longer, but it has improved independent-verification discipline, and has far greater reliability of catching defects internally. Reasoning and judgment Biggest difference between the two. Qwen3.6's potential to relax security controls (once it even broke the RLS-enforced database) and editing of Acceptance Criteria meant that it required constant supervision. Qwen3.8 diverges here, as it has not repeated those specific behaviours. However, there is a key failure that is shared both by Qwen3.6 and Qwen3.8 here. Both models are very keen to execute write Git commands - despite instructions to the contrary - which then causes major verification issues. This is real reliability issue and I would strongly suggest that when you configure permissions for your coding harness you limit Qwen to read-only Git commands. Added: Tools calling Also adding this one, as this is another area where Qwen3.8 is significantly more advanced than Qwen3.6. Qwen3.6 executed diagnostic scripts at a very basic level. It also had a tendency to execute web client, servers and other scripts by using arguments to "silence" error codes. Qwen3.8 is heads and shoulders above. It executes with commands that check every error output. It uses advanced diffs and joins for diagnostic script output. Net assessment Qwen3.8 is meaningfully and significantly more capable and more trustworthy than Qwen3.6 on every axis except one: neither should be granted extended Git access. Final note: I have not noticed any degradation in Qwen3.8 working at 367,001 context - which is phenomenal. submitted by /u/PathfinderTactician [link] [comments]
Related
- Tested in Coding: BF16 Muse Glimmer vs BF16 Qwen3.6 27B
- After pushing 1M+ tokens through Qwen 3.8 27B, here is my optimal llama.cpp config for 16GB VRAM (73k Context, Agentic Coding)
Source: r/LocalLLaMA | 2026-08-23