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.

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.

This is the MTP build of Dagger. It ships protoLabsAI's multi-token-prediction GGUF of ThinkingCap-Qwen3.6-27B with the same Dagger template + force-appended terseness prompt as the standard Dagger GGUF, only this build keeps the nextn/MTP draft head for speculative decoding. Accuracy is identical either way — speculative decoding is lossless.

Speedup depends on your runtime. ~1.5–2× is reported in vLLM/SGLang. In llama.cpp it needs a recent source build (b10362+) run with --spec-type draft-mtp; current llama.cpp releases don't ship MTP yet, so there it's parity with the standard GGUF. We measured ~1.11× on code generation tuned (--spec-draft-n-max 4 --spec-draft-p-min 0.6, M2 Ultra, Q4) — the dense 27B's full-block MTP draft head barely pays off in llama.cpp, unlike the cheaper draft on the MoE sibling Nail (~1.35×).

The benchmarks below were run on the non-MTP models. Don't need MTP? Use the standard GGUF.

Long-form stamina — how far it gets before the context ceiling

Reasoning and knowledge

Multi turn conversations, capped at 6 turns

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.

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

| | |

|---|---|

| Base | bottlecapai/ThinkingCap-Qwen3.6-27B (a Qwen3.6-27B finetune that shortens thinking) |

| Quant | GGUF Q6_K (from bottlecapai/ThinkingCap-Qwen3.6-27B-GGUF) |

| Architecture | Dense — 26.90B total, 25.62B active/token |

| Compute | 51.25 GFLOP/token (the 35B-A3B MoE costs 6.79) |

| Context KV | 86.5 KiB/token at 16-bit, measured on the MLX build |

| Modality | Text and vision — pair any quant with the shipped mmproj-ThinkingCap-Qwen3.6-27B-f16.gguf |

| On disk | 22.43 GB. Budget 31.1 GB RAM for full context at 8-bit KV (measured) |

| Template | froggeric's fixed Qwen template, with Dagger's system prompt force-appended |

| Weights changed | None |

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.

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:

|---|---|---|---|

The difference shows up on real world repository scale problems, not on self-contained coding tasks. Note that the y axis is log scaled.

Averages over both self-contained tasks and full-repo tasks:

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.

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.

|---|--:|--:|--:|

| Dagger-27b | 2,217 | 58.8%\* | 522 |

| ThinkingCap-27b | 5,393 | 55.0%* | 651 |

| Qwen3.6-27b (base) | 6,274 | 55.4%* | 912 |

Long-form stamina — how far it gets before the context ceiling

**(\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.

| lever | what it buys | evidence |

|---|---|---|

| ThinkingCap finetune | ~2.7× shorter thinking | MMLU think tokens 3,639 → 1,342, measured |

| froggeric template | tool-call correctness, thinking retention | isolated on Nail, not on Dagger |

| our terseness prompt | 2.4× on prose out; ~1.3× further on thinking | Claw-Eval 5,393 → 2,217 answer tokens |

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:

| Dagger-27b, 2k prompt | prefill | decode |

|---|--:|--:|

| MLX 6-bit · fp16 KV | 172 tok/s | 24.5 tok/s |

| MLX 6-bit · 8-bit KV | 174 tok/s | 24.5 tok/s |

| GGUF Q6_K · f16 KV | 265 tok/s | 22.6 tok/s |

| GGUF Q6_K · 8-bit KV | 262 tok/s | 21.5 tok/s |

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 (:Q4_K_M is the default, ~16.8 GB); llama.cpp

auto-downloads to its own cache.

llama-server -hf peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF-MTP:Q4_K_M -ngl 99          # text; or llama-cli

Prefer to keep the files yourself? (also the path for the MTP speculative-decoding and vision setups below):

# this repo ships an MTP-preserved ladder (Q3/Q4/Q5/Q8); Q4_K_M (~16.8 GB) is the default
hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF-MTP --include "*MTP-Q4_K_M.gguf" --local-dir Dagger-MTP

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

# MTP speculative decoding — llama.cpp built from source (b10362+); tune n-max / p-min
llama-server -m Dagger-MTP/Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf -ngl 99 \
             --spec-type draft-mtp --spec-draft-p-min 0.6

# vision — the mmproj isn't in this repo; pull it from the standard GGUF repo
hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF --include "mmproj-*.gguf" --local-dir Dagger-MTP
llama-mtmd-cli -m Dagger-MTP/Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf \
               --mmproj Dagger-MTP/mmproj-ThinkingCap-Qwen3.6-27B-f16.gguf \
               -ngl 99 --image photo.jpg -p "What is in this image?"

Which file

|---|--:|---|---|

| Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf | 16.8 GB | protoLabsAI, MTP-preserved | start here — ThinkingCap Q4_K_M with the nextn/MTP draft head kept, plus the Dagger template |

All six carry the nextn/MTP draft head and the identical Dagger template; the

standard GGUF repo has the full

Q4→Q8 ladder without MTP. -hf tag, e.g.: llama-cli -hf peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF-MTP:MTP-Q4_K_M.

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.
protoLabsAI — the MTP-preserved ThinkingCap GGUF quantizations this repo redistributes (the nextn draft head that makes the MTP speedup possible).
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-MTP,
  title  = {Dagger-Qwen3.6-27B-GGUF-MTP},
  author = {Saga Ishtardottir},
  year   = {2026},
  url    = {https://huggingface.co/peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF-MTP},
  note   = {protoLabsAI's MTP-preserved Q4_K_M quant of ThinkingCap-Qwen3.6-27B with a fixed chat template and an always-on terseness prompt; MTP draft head preserved}
}

License

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