Qwen3.8-Flash-Next (local) vs Claude

Reddit r/LocalLLaMA News

Summary

A developer compares running Qwen3.8-Flash-Next locally (UD-Q4_K_XL on llama-server with ROCm) against Claude Opus in Claude Code for reviewing a real Swift commit: Qwen produced 8 findings with zero false positives and caught 2 issues Claude missed, but missed 5 others, making it a solid private first-pass reviewer rather than a final authority.

I am seriously impressed and want to share my experience. Qwen3.8-Flash-Next (local) vs Claude in Claude Code: reviewing one real commit I ran the same code review twice on one commit in my repo https://github.com/leok7v/ChatOKF (Swift, on-device LLM chat app, about 48 files changed, +1048/-102: a module move plus a new 783-line search harness). Setup: Qwen3.8-Flash-Next UD-Q4_K_XL (unsloth) on llama-server, ROCm, AMD Strix Halo 128 GB, 262K context, MTP draft head, driven headless by Claude Code itself (claude -p pointed at the local server, read-only tools). The comparison reviewer was Claude (Opus) in Claude Code, which reviewed blind first and then judged Qwen's review against the code. Yes, Claude judging its own competitor is a bias; every finding below was checked against the source, and the main one with a small Swift repro. Result: Qwen produced 8 findings, all real, zero false positives. It caught 2 things Claude missed (a test harness that does not follow the app's recall path, and a markdown ingest that takes the frontmatter "---" as a description). It missed 5 that Claude found, including the most important one: a stop-word filter that compares stemmed words with an unstemmed list, so "this" and "does" leak through as search terms. It also got two details wrong (the exact fallback behavior of a failable init, and column counts off by a few). Severity calibration and the "checked and fine" section were good. It read whole files and chased module boundaries like a careful human. Cost: 53 turns, 41 minutes, context grew to about 110K tokens. Decode was about 21 t/s at 4K context and about 14 t/s at 128K; prefill 520 t/s falling to 230 t/s. MTP gives about 1.5x up to 64K and turns into a loss past about 100K. Gotchas: Use --lazy-mode on. Otherwise the 27 GiB n-gram embedding table loads into RAM instead of staying mmapped. unsloth's MTP heads crash llama.cpp (GGML_ASSERT in set_input_k_idxs) because the MTP layer's compress ratio is 0 in the GGUF. Fix branch: https://github.com/leok7v/llama.cpp/tree/qwen4exp/mtp-dense-no-indexer Claude Code sends a system message mid-conversation and the Qwen chat template raises on it. Override the template so it renders as a system turn. Verdict: a trustworthy first-pass reviewer you can run privately overnight, but verify its mechanisms before acting, and don't treat it as the final word on subtle logic. One commit, one run, so treat it as an anecdote, not a benchmark.
Original Article

Similar Articles

Story time: Qwen3.8-Flash-Next on my Strix Halo laptop vs Claude Opus 5.5 on the same feature

Reddit r/LocalLLaMA

A developer benchmarked local Qwen3.8-Flash-Next running on a 128GB Strix Halo laptop against Claude Opus 5.5 in Claude Code on the same complex Rust coding task, finding the local model produced a better PR (merged over Opus's) at zero API cost, though Opus remained 2-10x faster. The post highlights that local open-weight models can now genuinely challenge frontier cloud models for real coding work.

Qwen3.8-Flash-Next Strata pi beat Claude-code Opus 5.5 on a 5090

Reddit r/LocalLLaMA

A user shows that a locally-run, IQ3_S-quantized Qwen3.8-Flash-Next served via Strata and driven by the pi harness on an RTX 5090 matched (and slightly beat in speed) Claude Code Opus 5.5 on the AirBench everyday-tasks benchmark, with full reproduction steps.