Dagger-Qwen3.6-27B-GGUF

<div align="center"> <img src="assets/dagger_banner_eyebrow.png" alt="Dagger — ThinkingCap-Qwen3.6-27b, sharpened, battle tested" width="100%"> </div>

Straight to the point

Dagger thinks in a quarter of the tokens stock Qwen3.6-27b needs - less than ThinkingCap - and answers in less than half the words, at accuracy and quality that is statistically within noise.

This is the 27b that doesn't waste your time on filler, goes the furthest before it runs out of context, and doesn't lose the thread.

MTP version here

Dagger is ThinkingCap's finetune of Qwen-27b at Q6_K quant with a fixed and improved chat template with a force-appended system prompt that sharpens behaviour. llama.cpp applies it automatically — no --jinja, no --chat-template-file.

If you have a Mac, use the MLX build instead. This exists for everyone who doesn't.

<div align="center"> Long-form stamina — how far it gets before the context ceiling <img src="assets/card_marathon.png" alt="GPQA-Diamond questions chained before the 256k native context ceiling" width="100%"> Reasoning and knowledge <img src="assets/card_mmlu_pro.png" alt="MMLU-Pro: 100 questions, n=3 seeds" width="100%"> Multi turn conversations, capped at 6 turns <img src="assets/card_official_score.png" alt="Claw-Eval multi_turn: 38 tasks, n=3 seeds" width="100%"> </div>

Dagger handles 110 hard questions chained inside one context window, against 63 for ThinkingCap and 24 for stock Qwen. Fewest tokens per correct answer of any model we benched, 59% shorter prose than the finetune underneath it at a higher judge score, and a full 3/3 on every agentic problem in our solvable band.

Which one. One long agentic session that has to stay coherent inside a single context, on a machine with RAM to spare → Dagger. Many independent tasks, or you'd rather solve 3 problems in the time this takes to solve one → Nail-35b-a3b, its MoE sibling at the same ~22 GB on disk.

All benchmarks on Mac Studio M2 Ultra 64 GB, oMLX, 8bit KV cache.

The marathon

Long form stamina is context ceiling ÷ tokens-per-question, and it is the one axis where Dagger wins outright.

Every model here declares the same 262,144-token native context — what differs is how fast each model fills it. On GPQA-Diamond Dagger spends 2,380 tokens per question against ThinkingCap's 4,137 and Nail's 5,777:

• Hard questions chained inside the native context: Dagger 110 · ThinkingCap 63 · Nail 45 · stock Qwen 24.

Nobody sat through a 110-step session — it matters for autonomous thinking, agentic work, and conversations you keep coming back to.

The catch: it wants the RAM

Dagger's context is expensive to hold. Measured at full 16-bit KV, a token of context costs 86.5 KiB against Nail's 21.9 — about 4× — because a dense 27B runs 16 full-attention layers with 4 KV heads where the MoE runs 10 with 2.

<div align="center"> <img src="assets/card_memory_turns.png" alt="Claw-Eval Multi Turn memory usage until the 256k native context ceiling" width="100%"> </div>

Full 262k context costs Dagger 38.6 GB at 16-bit KV, or 31.1 GB with the 8-bit cache we recommend — both measured on the Q6_K build at -c 262144, not extrapolated. The other quants differ only in weight bytes, so subtract the file-size difference. On a 64 GB machine that is comfortable and the marathon is Dagger's. On a 32 GB machine it is not: inside the RAM that fits Nail's entire context, Dagger holds 73k tokens and taps out at 42 conversation turns where Nail runs to 92.

So the honest version: Dagger wins the marathon on a big machine. Nail wins it on a small one. Match the model to your RAM before you match it to a benchmark.

The secret sauce

The system prompt ships inside the chat template and applies on every call. If you send your own system prompt, yours is emitted first and Dagger's is appended after it — verbatim:

You are Dagger-27b, a variant of ThinkingCap-Qwen3.6-27b. Answer directly, after thinking. Lead with the answer, then only what it needs to be correct and usable.
Never: open with preamble or pleasantries; restate the question; add filler transitions; hedge with niceties; or repeat a point you've already made.
Always: keep essential steps, caveats, uncertainties, and specifics — never drop correctness or a needed warning for brevity. Keep the final answer lean. Use the least structure that conveys it (plain prose when short; lists or code only when they earn their place). If genuinely uncertain, say so and explain why — never omit uncertainty for the sake of brevity.
If a user request is genuinely ambiguous, ask a sharp question, don't guess.

Byte-identical to Nail's, apart from the name. It is concise about conciseness — long concision instructions don't survive a reasoning model.

The prompt is always on and lives in the template, not the API — disabling it means editing the GGUF's embedded tokenizer.chat_template.

Froggeric's chat template that I used as a base implements many tricks that drastically improve multi-turn agentic workflows with tool calling.

The composition of our battle tested prompt with the improved template, on top of bottlecap's terse-thinking finetune, is what makes Dagger so effective. Three levers, and we measured what each one buys — see Attribution.

What it is

The 6-bit quant was chosen for benchmarking and shipped because it fits with full context on more consumer systems than 8bit quants, and it's the smallest quant that is lossless on IKP.

<div align="center"> <img src="assets/qwen36-ikp-quant-vs-scaling-law.png" alt="IKP" width="100%"> </div>

Agentic coding

Dagger solves problems that ThinkingCap misses, and solves in fewer turns and fewer tokens than stock Qwen.

Where both solve 3/3 tries on the real-repo SWE Bench Live problems:

<div align="center"> The difference shows up on real world repository scale problems, not on self-contained coding tasks. Note that the y axis is log scaled. <img src="assets/card_se_speed.png" alt="Per-problem wall clock across the ten problems" width="100%"> Averages over both self-contained tasks and full-repo tasks: <img src="assets/card_se_sprint.png" alt="10 agentic software-engineering problems, n=3 seeds" width="100%"> </div>

Ten problems — 2 SWE-bench Live instances and 8 self-contained multi-round tasks — driven by a real coding agent, n=3. This is a solvable band: a set of problems every local model solves at least once.

On problems all models fail, Dagger fails fast instead of burning the budget: on NemoClaw-330 stock hit the 1,201 s cap on every attempt while Dagger finished (wrong) in 439 s. On kube-vip-1505, 351 s against 502 s.

What Dagger buys on coding is leaner turns, less thrashing.

The wall

Trying to find where Dagger fails, we found vueuse-5336 from SWE-bench Live: Dagger goes 0/3 while stock, ThinkingCap and Nail solved it. Dagger produced a fix that passed the target test, but broke the 1,375-test regression suite.

Practical reading: Dagger is in a hurry to ship. Give it a regression suite and it stays honest.

Since ThinkingCap and our Nail-35b-a3b solve it, the failure is in stacking the fine-tune with our prompt. Nail carries the same terseness prompt and template and solves it 3/3 where stock 35b-a3b does not, so the problem is not the template or prompt in themselves: they improve correctness and performance in isolation. Our hypothesis: the prompt compresses thinking on top of a finetune that already compresses thinking, and on this problem Dagger emitted ~1.9k tokens per attempt where ThinkingCap used ~2.2k and stock ~4.0k.

We are not "fixing" this. The double compression is exactly what wins both the sprint and the marathon everywhere else; tuning thinking back toward ThinkingCap's length hands back both to patch one class of issues that can be guarded with regression tests.

Reasoning and knowledge

Dagger answers at a 70-80% token discount, at accuracy within seed noise variance on MMLU-Pro and GPQA-Diamond.

MMLU-Pro is at the top of the page. Below is GPQA-Diamond: graduate-level multiple-choice questions in biology, chemistry, and physics, designed to test deep domain knowledge and reasoning.

We didn't lead with this one, because we didn't bench stock qwen3.6-27b ourselves: We relied on ThinkingCap's numbers (lossless quant with unquantized KV), and estimated s/correct from our own on-box tok/s rate for Qwen3.6-27b 6bit, because running it ourselves would burn GPU for days.

<div align="center"> <img src="assets/card_gpqa_diamond.png" alt="GPQA-Diamond: 198 questions, n=3 seeds" width="100%"> </div>

GPQA-Diamond ran the full 198-question set × 3 seeds — 594 graded answers per model, 0 truncations.

Against ThinkingCap, Dagger cuts thinking roughly in half again, on top of a finetune that already cut it by 2.7×, and we cannot detect an accuracy cost: Dagger scores 2 points under on MMLU-Pro and 0.5 under on GPQA — inside seed noise for n=3. On 100 paired MMLU-Pro questions, McNemar gives p = 0.125 at one seed, six discordant pairs against and one for: under-powered, not equal. Read it as no accuracy cost we can detect at this sample size, and if there is one it is small.

The stock Qwen row carries a dagger because we did not run it: three seeds was 3-4 days of GPU for a baseline bottlecap already published. That number is near-full-precision where our three arms are 4/6-bit quantized with 8bit KV cache, and ThinkingCap's token numbers count only thinking tokens where ours are totals. Treat it as an estimate; the ThinkingCap comparison is the measured one.

Efficiency buys correctness. This is the one result here that doesn't depend on n=3. Give both models an 8,192-token budget and stock Qwen truncates mid-thought on 11 of 100 MMLU-Pro questions and scores them wrong; Dagger truncates 0. Every real deployment has a token budget, and a verbose model pays in accuracy. (Separate experiment — greedy decoding, 8,192-token cap, not the temp-1.0 runs in the plates, where stock had budget to spare.)

Conversation

Dagger says it in 59% fewer words than the finetune underneath it, and the blind judge Opus liked it better.

<div align="center"> Long-form stamina — how far it gets before the context ceiling <img src="assets/card_context_runway.png" alt="Claw-Eval multi_turn chained turns before the context ceiling" width="100%"> </div>

(*at the limited multi_turn subset of ClawEval we limited rounds to 6 instead of the default 8, to save some days of GPU burn, so scores are not comparable to official ClawEval scores, only internally comparable to the models we benched)

We ran Claw-Eval multi_turn — 38 multi-turn advice and clarification tasks, 5.3 turns on average, simulated user, scored on the project's own rubric formula. The result card is at the top of the page.

Terseness was the open risk here — advice is exactly where cutting words could cut substance. It didn't: per task, Dagger's worst deficit against ThinkingCap was 1.5 points, across both the English and Chinese task sets, and on our own 0–10 judge it scores 7.4 against ThinkingCap's 5.7.

The gain is the prompt, not the finetune. Base Qwen3.6-27b scores 55.4% and ThinkingCap 55.0% — level, and level again on the answer component carrying 80% of the rubric (59.0% vs 59.3%). The finetune buys speed at no quality cost, exactly as advertised. Everything above that line is the terseness prompt: Dagger's answer component is 66.7%, +7.4 points over ThinkingCap and +7.8 over the base model, in 65% fewer answer tokens than the base.

Dagger's weakest sub-score is clarify (27.3%, lowest of the four): it asks fewer clarifying questions before answering. If your use case is elicitation rather than answering, that's the number to watch.

Attribution: which lever did what

Dagger stacks three changes.

The prompt's thinking-token effect is tail-concentrated: it flattens the long ramblings and barely moves the median question compared to ThinkingCap.

What the numbers are, and aren't

Every benchmark above was taken on the MLX build, not on this file. They are not the same artifact: MLX flat-6-bit and GGUF Q6_K are different quantization schemes at a similar size, and llama.cpp and oMLX are different runtimes.

What we did measure on these exact weights is speed. Same 2k-token prompt, 128 tokens generated, n=3, one M2 Ultra — mlx_lm generate against llama-bench, both bare generation with no server in the way:

llama.cpp prefills ~1.5× faster; MLX decodes 8–14% faster. Which one wins depends on your shape of work: long contexts re-read each turn favour this build, long generations favour the MLX one.

One asymmetry worth knowing: the 8-bit KV cache is free on MLX and isn't here. MLX decodes at 24.5 tok/s either way; llama.cpp drops from 22.6 to 21.5. On this build the 8-bit cache is purely a memory trade, not a speed win.

(MLX's prompt is 2,180 tokens against llama-bench's 2,048 — MLX's includes the chat template and the terseness prompt — so it is doing ~6% more prefill work. If anything that understates MLX.)

Quality is the part we have not measured here. Treat the plates as evidence about the recipe — this finetune, this template, this prompt — not as a measurement of this file.

Recommended sampling

temperature 1.0 · top_p 0.95 · top_k 20 · min_p 0

For agentic coding drop to temperature 0.7 (steadier tool use, everything else unchanged) — that's what our SWE runs used. Thinking budget up to 32,768, max output 32,768.

Unlike the MLX build there is no generation_config.json here — GGUF carries no such file, so llama.cpp will use its own defaults unless you pass these explicitly. Set them yourself. We also recommend no repetition or presence penalties: Dagger's concision comes from the prompt, and penalizing tokens distorts thinking in ways we haven't tested.

---

Use

Let llama.cpp fetch it — pass a :quant tag. Tag-addressable quants: :Q4_K_M, :Q6_K, :Q8_0 (the _L variants Q5_K_L / Q6_K_L aren't tag-addressable — grab those with the explicit download below). The mmproj rides along in the manifest, so vision works from the same tag.

llama-server   -hf peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF:Q6_K -ngl 99                    # text, auto-download
llama-mtmd-cli -hf peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF:Q6_K -ngl 99 --image photo.jpg  # vision (mmproj auto)

Prefer to keep the files yourself? (and the only way to get the size-sweet-spot Q5_K_L):

# pick one file — a bare download with no --include pulls all five (~115 GB)
hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF --include "*Q5_K_L.gguf" --local-dir Dagger-GGUF

llama-cli    -m Dagger-GGUF/Dagger-Qwen3.6-27B-Q5_K_L.gguf -ngl 99
llama-server -m Dagger-GGUF/Dagger-Qwen3.6-27B-Q5_K_L.gguf -ngl 99 --port 8100

# vision — add the mmproj (one copy works with every quant here)
hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF --include "mmproj-*.gguf" --local-dir Dagger-GGUF
llama-mtmd-cli -m Dagger-GGUF/Dagger-Qwen3.6-27B-Q5_K_L.gguf \
               --mmproj Dagger-GGUF/mmproj-ThinkingCap-Qwen3.6-27B-f16.gguf \
               -ngl 99 --image photo.jpg -p "What is in this image?"

Which file

The bartowski builds are quantized with an importance matrix and spend their bits differently: they keep the gated-delta path (ssm_alpha, ssm_beta) at F32 and the embeddings and output tensor at Q8_0, all of which the flat Q6_K quantizes. That is why the 21.5 GB Q5_K_L is not a downgrade from the 22.4 GB Q6_K — it gives attn_qkv the same Q6_K width while spending less overall.

Q5_K_L has no -hf tag (HuggingFace's tag allowlist rejects it), so pull it by filename. The others work as llama-cli -hf peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF:Q6_K_L.

The template is embedded, so there is nothing to pass — no --jinja, no --chat-template-file. For agentic use add -c 262144 (or as much as your RAM allows) and -ctk q8_0 -ctv q8_0 -fa on for the 8-bit KV cache the memory figures above assume.

A harness with a large system prompt of its own will get Dagger's instructions last, which is usually what you want. Override the concision directives explicitly and you have a 6-bit ThinkingCap, not a Dagger.

---

Limitations and out-of-scope use

• The numbers above are not from this file. See What the numbers are, and aren't. This is the honest caveat, not a formality.
• The prompt is not removable through the API. It lives in the GGUF's embedded tokenizer.chat_template. Any deployment that needs unmodified base behavior should use bottlecap's original.
• Vision is unbenchmarked. ThinkingCap's vision tower ships here as mmproj-ThinkingCap-Qwen3.6-27B-f16.gguf (bottlecap's own, 0.93 GB) and we verified it works — reading text, counting shapes and naming colours correctly through llama-mtmd-cli, with the terseness prompt still applied. But no benchmark on this page covers vision, and the MLX build has none at all: its 6-bit conversion drops the vision tensors entirely. So GGUF sees images and MLX does not — the one capability where the two builds differ.
• We did not quantize this. Quality is entirely bottlecap's Q6_K; we changed one metadata string. Any quantization loss is theirs to characterize.
• Safety and refusal behavior were not re-evaluated. We added an instruction that suppresses hedging and preamble; we did not measure what that does to refusals, safety caveats, or tone in sensitive domains. The prompt explicitly protects warnings and uncertainty, but we have no data on whether it succeeds.
• It under-verifies on real-world codebase scale. See The wall. Give it a regression suite.
• It asks fewer clarifying questions than the finetune underneath it — the lowest clarify sub-score of the four arms.
• Context is expensive. 86.5 KiB/token at 16-bit KV. If your machine is RAM-constrained, the marathon argument inverts and you want Nail.
• Quantization loss is unquantified. We never ran a full-precision arm; every number here is 6-bit against 6-bit for 27b models.

---

Method and honest caveats

We ran this campaign the way these models think: cheap pilot first, pivot before the expensive run, n=1 where the effect is robust and n=3 where the judge is noisy, n=100 paired where the delta is small enough to matter. Same guardrail as the prompt itself — shorten the path, never the rigor.

Everything ran on one Mac Studio M2 Ultra 64 GB through oMLX: n=3 seeds, temp 1.0 (0.7 for agentic coding), top_p 0.95, top_k 20, 8-bit KV cache, 131k operational context, 32,768 thinking budget. Agentic work used the Pi coding agent.

• 6-bit is the product, not a handicap. Benchmarks at 8- or 16-bit don't transfer to people running open weights on consumer hardware. Nail's cells are 4-bit — each family member at its own practical quant on the same RAM budget. That's also why we report seconds rather than tokens.
• Not leaderboard numbers. GPQA-Diamond ran the full 198-question set. MMLU-Pro ran our own 100-question subset. Both used minimal-prompt extraction rather than the official harness at full precision, so neither is board-comparable — they're internally consistent and validated against the published base-model number.
• Contamination. The SWE-bench instances predate Qwen3.6's release and may be in training data. The deltas between models are robust to that; absolute pass rates aren't.
• Judge. Claw-Eval scores used the project's real grading formula and rubrics, with Opus as judge rather than their default model. Valid for relative comparison, not an official number.
• Blinding. Judged runs used one identical name-free persona across all conditions, so the judge scored behavior, not a label. The benched persona line read "ThinkingCap" rather than "Dagger-27b"; same instructions, different label.
• Statistics. Seed-level n=3 is low power for small accuracy deltas; accuracy claims are framed as not-detectable, not as wins.

Why this isn't a frontier-lab product

Intelligence per token is an open-source-native optimization. Providers are paid per token and market on maximum capability; nobody pays more per token for equal intelligence, so tokens-per-correct-answer never reaches a commercial roadmap. It's not that it's hard — a fixed template plus a well-written prompt is a weekend. The incentive gradient just points the other way.

Big labs could have done this. They have no reason to.

---

Credits

• Qwen at Alibaba — the Qwen3.6-27B base model.
• bottlecap — the ThinkingCap finetune that does the heavy lifting on thinking length, and the Q6_K quantization this repo redistributes.
• froggeric — the fixed Qwen chat template.
• llama.cpp — the runtime.
• jundot — oMLX, which every benchmark here ran on.
• The Pi coding agent team.

Citation

@misc{Dagger-27B-GGUF,
  title  = {Dagger-Qwen3.6-27B-GGUF},
  author = {Saga Ishtardottir},
  year   = {2026},
  url    = {https://huggingface.co/peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF},
  note   = {bottlecap's Q6_K quant of ThinkingCap-Qwen3.6-27B with a fixed chat template and an always-on terseness prompt}
}

License

Apache-2.0, inherited from ThinkingCap-Qwen3.6-27B and Qwen3.6-27B.