Five Qwen3.8-27B models match Fable 5 Using GVS5H Harness

> No comparison to astra/6.1 sol/fable 5.1/opus 5.5

I mean, should a 27B model beat Fable 5 but not Fable 5.1 that would still be an incredible achievement.

The tool that implements this is the harness. An LLM by itself cannot "go off" and "do things" - it can only complete text blocks. A harness bridges this to real world actions or just a chat box interface.

It's really interesting to see the progress in the 27-30B range, they have gotten quite good but still make noticeably more hallucinations or bad assumptions (ime).

I'm currently using the Pi harness as well, it's closer to OpenCode v1 with a few plugins. However, I have zero faith in their security or maturity after several communications with the CEO. Pi is also developed by an Israeli team, if that is something that matters to you, re: Mossad concerns or Palestinians rights.

I'm going to go back to my own custom harness and do a full rewrite, now that I have seen what 6+ other harnesses offer.

But it's not optimized for coding specifically. It can edit files fine using Aider style edits. I've used it to write to do lists as a test. But I more designed it with the idea to be my personal debugging tool if I ran into any weird things while using Linux on a laptop.

github.com/patrickjh/ssa

llama-server --model Qwen3.8-27B-UD-Q4_K_XL.gguf --ctx-size 131072 --parallel 1 --cache-type-k q8_0 --cache-type-v q8_0 --host 0.0.0.0 --port 8080 --spec-type draft-dflash --spec-draft-model dflash-Qwen3.8-27B-Q4_0.gguf --spec-draft-n-max 3 --spec-draft-type-k q8_0 --spec-draft-type-v q8_0 --mmproj mmproj-BF16.gguf --no-mmproj-offload --image-min-tokens 2048 --reasoning-preserve

It just barely fits in my RX 7900 XTX's 24GB of VRAM (TBH i'm not sure if dflash is much better than MTP - which is included as part of the GGUF - and MTP saves ~1GB of VRAM). I'm using Linux with Xorg/Window Maker as my DE so it uses no VRAM at all (Qt-based stuff - and i guess modern Gtk too - tend to use some VRAM for themselves, even opening Kate shows up in amdgpu_top :-P). The above gives me on average ~50 tokens/sec generation (drops to about 35 when the context is close to full) and ~700 tokens/sec prompt processing, which while not particularly speedy is fine for agentic stuff as i just give the AI a task and leave it in the background doing things. To save some VRAM i run the multimodal projector for vision on the CPU (the --no-mmproj-offload) and only one task is ever executed at the same time (--parallel 1). Also the kvcache is quantized to q8_0 - supposedly this makes the model a bit dumber, though the extra VRAM needed for the full f16 kvcache makes it more than ten times slower :-P (and AFAIK dense models like the 27B aren't as affected by it as MoE models are).

I'm using Pi[1] (a slightly older version that i've had remain offline and disabled the telemetry) for now (will replace it at some point since i'm not a fan of the ~500MB dependency tree, the almost-dark patterns for online access/telemetry and the increasingly worrying push for the devs' services, but i do like how it approaches compaction and that for the most part it doesn't need any handholding when some error happens - which is ideal for "let the AI do something and check it some time later").

It is running inside a container so it doesn't get any access to my real stuff (mainly to avoid the LLM making any mess - of which it sometimes does in the container, but well, it is contained :-P). In the container Pi gives the LLM some basic tools - read, write, edit and bash - and the last one is basically used to do most of the work (i've also made a bunch of tools the LLM can use via the CLI).

[0] https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/blob/main/Qw...

[1] https://pi.dev/

If someone has one or two 32GB GPUs with decent bandwidth (faster than the Strix Halo or DGX Spark), the dense model is the obviously better choice, and I think that case is more common for the average developer.

https://inference-docs.cerebras.ai/models/qwen-3.8-27b

I am routinely using swarms of agents, with complex sequencing between them and agents watching other agents, and then triggering forks and/or new design cycles. My normal flow is to have a few design tasks open per codebase during the day, with each design agent aware of the other sessions, and having an unattended nightly build which sometimes takes 8hrs and also requires coordination for tests, merges, and so on.

I experienced a regression some days ago, where Claude Code with Opus 5.5 wouldn't progress as expected, getting stuck on steps. So I had to repeatedly ask it what the status was and to proceed with X, and so on.

But that was just one day, the days before and after it has done lots of fairly autonomous work, including spinning off multiple subagents to run conformance tests which take 30-50 mins and work on other stuff in the meantime, then acting on the results autonomously.

I use Copilot CLI at work, and Claude Code at home, and all harnesses are pretty good these days.

Secondly yeah, all models have issues with foreground vs background subagents. So I just modified my harness to delete foreground subagents. No more confusion. If they need the subagent's output tokens they can read it from the session transcript.

"Take away tools" is often the best solution for model-gets-confused problems. Narrow down your toolset until there's only one way to do things, and then make it the maximally-powerful way.