We’re releasing new Qwen3.8-27B GGUFs with 10% higher accuracy.

Unsloth Dynamic V3 outperforms others by >10% on Div-300, KLD & more benchmarks.

We also release 1-bit quants that retain 77% accuracy. Run on 8GB RAM.

Blog: https://unsloth.ai/docs/basics/dynamic-3.0-ggufs

GGUF: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF

I created a small testing rig to evaluate new open source models as they drop, and with the much anticipated release of Qwen3.8-27B, I was eager to see how it cross-compares with frontier and strong local models.

The rig

My test rig is an M5 Max MacBook Pro, 128GB. Locally I ran Qwen3.8-27B on xhigh and medium thinking modes via LM Studio, MLX 8-bit, temp 1.0 / top_p 0.95 / top_k 20, context 131,072 and DeepSeek V4 Flash "0731" 2-bit-imatrix q2-q4, served by antirez's ds4-server at -ctx 400,000, thinking enabled. For cloud I included Opus 5, Sonnet 5, GPT-5.6-sol at xhigh reasoning, and even Haiku. Every model gets the same prompt. The algorithm tasks are executed against fixed-seed differential harnesses, and the repo tasks run against hidden test suites plus a cached baseline of the whole repo. If a fix inadvertently breaks something else it gets caught.

The methodology

The model assessment is broken into 4 batteries:

1. algorithms easy-hard

2. algorithms extremely hard

3. repo work easy

4. repo work hard

The models get run through the algorithm tests 3 times each to derive a mean score whereas the repo work is single pass/fail per task. If a task fails to produce a response, it's retried and time added to total wall clock time for task completion. The total test battery can take anywhere from 12-24 hours of wall time for slower local models. It's a long test.

For the repo batteries I had Fable build a small double-entry ledger CLI and plant bugs that pass the visible test suite while still reproducing a real symptom, then handed each model the repo and a bug report written in a theoretical 'user' voice to simulate how it might be reported in the real world. There's also a subjective code quality assessment that measures the model's ability to not just solve the problem but to conform to the repo's coding style, to fix the actual root cause rather than the symptom, and to keep the diff minimal instead of faffing about and rewriting a bunch of stuff.

I had Opus and GPT blind eval the results and compute a code quality score broken up by 'fixes' and 'features' as these appear to be separable skills for the models. The goal with all of this was to try and create a replicable and automated answer the question: How useful is this model in the real world?

Caveats

This is a home baked assessment and susceptible to bias or less than perfect methodology. It also includes subjective criteria like 'code quality'. I built this for myself as an adjacent tool to on the ground testing. I think the best way to evaluate any model is to test it against your own codebase to see how well it integrates into your workflow.

All that being said, let's move to the scorecard.

Results

Qwen3.8-27B is a very capable model that compares well against frontier models on code quality and correctness. The cost is wall time on Apple silicon. As many have observed, 3.8 has a tendency to over-think, burning up tokens. The time spent earns higher code quality for the most part, but what surprised me is that there are some instances in which less thinking is actually more accurate. On the repo battery, medium went 8/8 while xhigh went 7/8 — the most-thinking configuration failed a task there, and it took four times longer to do it (the wait time with Qwen was tiresome at times).

The caveat is that xhigh excels on extremely hard algorithms, where medium begins to fall apart. Medium didn't even finish the hard algo tasks. There may be some value in matching the thinking to the kind of work you're setting it upon. Lastly Qwen xhigh won outright on quality of surgical fixes and patches to existing code. Interestingly the global trend for locals is that they're competitive along fixes and less so along features where cloud still dominates. This fits anecdotally into my own experience with gravitating to frontier for planning and local for implementing.

GPT 5.6 Sol is the only cloud model with a perfect card on both repo tiers and near perfect algorithms. It's also among the fastest to completion. This all tracks with my own anecdotal experience with this model over the past several months. Highly competent and quick if not a bit stark.

DS4 0731 (a 2-bit quant running on my laptop) is the only local model to get 8/8 on both repo batteries, and one of only two models overall to do it, alongside GPT. It does this all at a respectable wall time. The expense is less elegant code: it sometimes mutates unrelated docstrings and writes dense inline solutions in a codebase that is overtly broken apart and stylistically explicit. Feature code quality is stronger and it's the only model that scored better/equal in the harder repo tier vs the easy one.

Opus 5 is the most reliable model in the set and best code quality of the cloud models. It stumbled only in the hard repo tier where it lost a task by being trying to outsmart the test. A doc string promised one behavior while the code did another, and Opus redesigned the function around what it looked like it should do instead of honoring the documented contract. This also falls inline with my anecdotal experience with Opus 5 where it occasionally ignores your directions completely and just does whatever it wants. The Alaskan Husky of frontier models.

Sonnet 5 is a steady pair of hands that performs reasonably well across tasks for a modest token budget. I think sonnet is kind of underrated as an implementer. Does the same quality of work as the locals cheaply and quickly.

Haiku 4.5 races to the end of the test but has a tendency to fall over and force retries. Worst code quality of all the cloud models.

Conclusion

Hopefully you find these comparisons interesting. For me personally, DS4 has been my goto local, but this test is making me consider trading it out for Qwen3.8-27B. I think they're on equal footing, which is crazy b/c DS4 needs like 90gb of ram. I'd like to try the MTPLX variant of Qwen3.8-27b that's meant to improve tok/s on apple silicon. Slowness to task completion is the real bottleneck for me right now when considering Qwen. Perhaps that'll be my next test.

Curious to know if these results track with your own real world experiences.

TL;DR: On a Strix Halo laptop (Radeon 8060S, 128 GB unified), MTP takes Qwen3.8-27B Q8_0 from 7.1 to 21.9 tok/s. The julianmb/q38rocm FP4 fork gives 26.7 tok/s.

Setup: LlamaStash driving stock llama.cpp b10503 (5112b9738) for ROCm and Vulkan, and the q38rocm fork (server build 246) for ROCmFP4, all built from git today. Greedy, 256 max tokens, wall-clock tok/s from the API usage numbers, best of 2 reps, on AC power. Everything launched through my tool LlamaStash (v0.2.0) so the flags are reproducible.

Qwen3.8-27B decode tok/s (code prompt / prose prompt):

Build and model	MTP off	MTP on	Draft acceptance
ROCm + Q8_0 (29 GB)	7.1	21.9 (draft 5)	73%
Vulkan + Q8_0 (29 GB)	7.4	21.3 (draft 5)	73%
ROCmFP4 FAST (14.6 GB)	12.5	26.7 (draft 6)	86%

Draft length sweep, code prompt tok/s:

draft n	2	3	4	5	6	7	8
Q8_0	15.4	18.4	19.1	21.9	21.2	21.8	20.5
FP4	-	23.3	24.9	25.0	26.7	25.6	-

Observations:

• MTP really makes a difference 2.5x to 3.1x on Q8_0, 2.1x on ROCmFP4, at 73-95% draft acceptance. The model verifies every token, so quality does not change on stock llama.cpp.
• Draft length of 5 works best. The backend default is 3; 5 was best for Q8_0 and 6 for FP4.
• FP4 is a double win if you can live with the quant. Half the memory (29 to 14.6 GB), 1.8x faster raw decode without MTP, and 26.7 tok/s with MTP, which is 3.8x my stock Q8_0 baseline.
• Engine choice barely matters for decode at this size. ROCm, Vulkan and the rocWMMA build all land within about 3%. Vulkan does lose roughly half its prompt processing throughput though, so ROCm stays my default.
• Stuff that did not help: KV cache q8_0 (helps at draft 3, slightly worse at 5), flash attention off (minus 5%).
• One caveat on the ROCmFP4 fork: completion lengths drifted a little across draft settings (152-158 tokens for the same prompt) while stock llama.cpp was stable at 164, so the fork's speculative path is not strictly greedy-identical yet.

LlamsStash defaults were used for all runs. The only flags set were to enable disable MTP ( --spec-type draft-mtp), set draft length (--spec-draft-n-max N) and the --fit-ctx 16384 flag was used to ensure the GPU layers were fully utilized.

The below are the default flags that was applied. Some sent by LlamaStash and others are llamacpp defaults.

Flag	Value	Set by
--host	127.0.0.1	LlamaStash (loopback policy)
--port	41100	LlamaStash (auto-assigned)
-m	<model>.gguf absolute path	LlamaStash (resolves the name ref)
--mmproj	mmproj-F16.gguf	LlamaStash (auto-paired sidecar; Q8_0 rows only, FP4 has none)
--jinja	on	LlamaStash (chat template handling)
--spec-type	draft-mtp	LlamaStash (translated from --mtp on)
--spec-draft-n-max	5 (Q8_0) / 6 (FP4 best) / omitted on default rows	LlamaStash (--mtp-draft-n); llama.cpp default 3 when omitted
--fit-ctx	16384	LlamaStash (ctx knob = auto, fit hint)
--cache-type-k / -v	f16 (q8_0 on kvq8 variant rows)	llama.cpp default except for kvq8 runs
--flash-attn	on (off on the fa-off variant row only)	llama.cpp default except for fa-off runs
--n_ctx (final)	262144 per slot (native 256K)	llama.cpp fitter
--n_parallel	4, kv_unified true	llama.cpp (auto)
--n_gpu_layers	all (-1)	llama.cpp fitter (llamastash knob was auto)
--cache-type-k/v (final)	f16 / f16	llama.cpp default
--n_threads	16 (of 32 logical)	llama.cpp default
--n_batch / --n_ubatch	server defaults, not overridden	llama.cpp
spec internals (fork only)	n_min=0, p_min=0.75, backend_sampling=1	llama.cpp (q38rocm fork defaults)
draft context (fork only)	all GPU layers, f16 KV	llama.cpp (fork)

Just got Qwen3.8-27B (FP8) running on rented GPUs from Trooper AI. FP8 fits on 64 GB VRAM with decent results.

Stack:

- GPU: 2× RTX 4080 Super Pro (64 GB VRAM total)

- CPU: 12 P-cores, 76 GB RAM

- SSD: 900 GB NVMe

- Price: 1.06 EUR/h

Served it via vLLM → KServe → Envoy AI Gateway, TLS + token metering + rate limiting on top ( I already have a running Kubernetes cluster, I attached to trooper GPU node), or you can it serve it directly with compose if you are a single user.

Runned load tests: (10 concurrent requests, 32768 context)

- TTFT: ~0.9s

- Per-stream decode: ~28 tok/s

- Aggregate: 152 tok/s

Full deploy guide if you want to deploy it: https://github.com/redaER7/qwen3.8-27b-self-hosted

Now, looking to deploy the full model FP16 on RTX 6000 Pro

I previously reported a result of 74% on BU bench v1, with the open-source BrowserAgent harness, but I forgot to set the temperature to the default specified in the model card... Now the model performs neck to neck with GPT 5.6 Luna (xhigh) and beats all other affordable models that I tested.

Qwen3.8 27B is insanely good value!

Used Gemini for the comic. Prompt:

create an image for this comic.

it should be a single image. no text, no baloon dialogues (i'll add that later).

use a simple, minimal style. mostly blank (white), with black lines. some accent colors here and there.

there are two women, friends, sitting on a couch. they're talking, facing each other. one is silent (listening), and the other one is talking (venting), holding a lit cig.

What will the rest of this year bring? 27b class scoring over 60?

I'm pretty emotional right now haha. I've been checking App Store Connect for the last 2 weeks religiously, and today I was afk all day and didn't realize I was approved this morning!

Anyway, I built Koko, a fully offline conversation practice for language learners. You can listen and speak as much as you want, everything scaled to your level. Best of all your voice and info stays on your device.

Check it out if this is up your alley! https://apps.apple.com/us/app/koko-language-learning/id6794011726

I asked Shuai Bai, co-author and prominent AI developer for Qwen, about this model. Not the answer I was hoping for, but let's see what comes next. In the meantime, I guess all we can do is speculate!

X-link

New Row-Bot demo: turning your inbox into an action plan.

​

Row-Bot checks important emails, finds action items, drafts replies, creates calendar events, and schedules reminders, with approvals for sensitive actions.

​

Not just chat. Real workflow automation.

​

[https://github.com/siddsachar/row-bot\](https://github.com/siddsachar/row-bot)

I'm the developer, and this is my project, so read it with that in mind.

The part I think is actually interesting is a refusal, so I'll start there. My app can run AI-generated shell commands and Python inside a Windows sandbox using AppContainer. Before it treats a sandbox level as available, it tests on your machine that Windows is actually enforcing that boundary, and it fails closed when a sandbox level you chose can't be established: the command is refused rather than run with weaker protection. The UI always shows which isolation level actually ran, because "sandboxed" is a claim and the app should have to prove it.

The app is Nyx AI, a Windows desktop workspace built around an AI agent. It does documents, spreadsheets with live formulas, slide decks, PDFs, web research and data analysis as well as code editing and shell work. You bring your own model: Ollama running on your PC with no API key stored in the app, or your own OpenAI, Anthropic or Ollama Cloud account. It ships no models and no inference runtime, so local means installing Ollama yourself first.

Honest qualifier on "local-first", because you'd catch it anyway: a local Ollama model keeps ordinary prompts on your PC, and small background helper calls can use a local model when one is available. On the Auto routing setting, though, heavier coding, reasoning and planning work normally prefers a cloud route you've configured. Local-first is a supported way to run it, not a guarantee that nothing ever leaves the machine. The docs say exactly that.

There are four isolation levels: Automatic, Standard, Sandbox + internet, and Sandbox · no internet. They use two Windows mechanisms: AppContainer for the two Sandbox levels and a Job Object for Standard. Standard is documented as not being a filesystem or network jail.
At the no-internet level, the sandbox is created without internet capability, so the operating system itself refuses outbound traffic from AI-run code. That still isn't an air gap for the whole app: chat still goes to whichever model provider you chose, and the update check, dependency installs you approve, and one-time component downloads can still touch the network. The threat model lists all of it.
Approvals come in two kinds. Ordinary ones are cards inside the app. Higher-risk model actions and certain sensitive operations can require a native Windows confirmation dialog outside the model-controlled interface. Nothing sent from the chat window can mark an action pre-approved, and if the dialog can't be shown the action is refused.

A smaller set of prohibited actions is refused outright in every mode and never offered for approval at all.
There's also an audit trail: a plaintext action log, plus an encrypted, hash-chained forensic log of approvals, denials and sandbox blocks. If a recorded entry is later altered, verification can show it. The docs also state plainly that this cannot prove nothing is missing.
Now the parts you'd find out anyway, so here they are first.
Windows 10/11 x64 only, because the sandbox is built on Windows-specific isolation. There is no macOS, Linux or Windows-on-ARM build.
It is proprietary and closed-source, free for personal non-commercial use, with a separate licence required for commercial use.

Because the source is not public, I have tried to make the externally verifiable parts unusually transparent. The full threat model is public, including trust boundaries, network paths and residual risks, and you can independently monitor its network behaviour.
It's beta software. It has not been independently audited. Prompt injection is documented as not solved, and the app itself ships the line "no sandbox is 100%".
Nyx AI sends no usage analytics, telemetry or crash reports of its own. Automatic update checks are on by default and can be disabled. A check sends the installed version, and the connection necessarily exposes the requesting IP to the update host. Installing from the Microsoft Store also means Microsoft's own platform diagnostics apply under Microsoft's terms, not the app's.
Site and threat model:
https://nyxai.uk

Install is through the Microsoft Store. The website does not host the installer.

Two things I'd genuinely like opinions on.
Where would you draw the line between approvals that deserve a hard OS dialog and ones where an in-app card is enough?
And if you read the threat model, what's missing from it?