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
GPQA-Diamond questions chained before the 256k native context ceiling
Reasoning and knowledge
MMLU-Pro: 100 questions, n=3 seeds
Multi turn conversations, capped at 6 turns
Claw-Eval multi_turn: 38 tasks, n=3 seeds
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.
Claw-Eval Multi Turn memory usage until the 256k native context ceiling
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:
text
1You 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.
2Never: open with preamble or pleasantries; restate the question; add filler transitions; hedge with niceties; or repeat a point you've already made.
3Always: 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.
4If 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)
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.
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:
instance
Qwen3.6-27b
Dagger-27b
delta
http-proxy-middleware-1163
214 s · 1,779 tok
130 s · 1,036 tok
−39% wall, −42% tokens
defuddle-243
478 s · 4,000 tok
391 s · 2,703 tok
−18% wall, −32% tokens
The difference shows up on real world repository scale problems, not on self-contained coding tasks. Note that the y axis is log scaled.
Per-problem wall clock across the ten problems
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: 198 questions, n=3 seeds
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.
answer tokens/conv
score
seconds per conversation
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
Claw-Eval multi_turn chained turns 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):
bash
1# this repo ships an MTP-preserved ladder (Q3/Q4/Q5/Q8); Q4_K_M (~16.8 GB) is the default2hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF-MTP --include "*MTP-Q4_K_M.gguf" --local-dir Dagger-MTP
34llama-cli -m Dagger-MTP/Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf -ngl 995llama-server -m Dagger-MTP/Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf -ngl 99 --port 810067# MTP speculative decoding — llama.cpp built from source (b10362+); tune n-max / p-min8llama-server -m Dagger-MTP/Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf -ngl 99\9 --spec-type draft-mtp --spec-draft-p-min 0.61011# vision — the mmproj isn't in this repo; pull it from the standard GGUF repo12hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-GGUF --include "mmproj-*.gguf" --local-dir Dagger-MTP
13llama-mtmd-cli -m Dagger-MTP/Dagger-Qwen3.6-27B-MTP-Q4_K_M.gguf \14 --mmproj Dagger-MTP/mmproj-ThinkingCap-Qwen3.6-27B-f16.gguf \15 -ngl 99 --image photo.jpg -p "What is in this image?"
Which file
file
size
source
notes
Dagger-Qwen3.6-27B-MTP-Q3_K_M.gguf
13.5 GB
protoLabsAI, MTP-preserved
smallest — for tighter VRAM
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
Dagger-Qwen3.6-27B-MTP-Q5_K_M.gguf
19.5 GB
protoLabsAI, MTP-preserved
more bits if you have the RAM
Dagger-Qwen3.6-27B-MTP-Q6_K.gguf
22.4 GB
protoLabsAI, MTP-preserved
near-lossless sweet spot
Dagger-Qwen3.6-27B-MTP-Q8_0.gguf
29.0 GB
protoLabsAI, MTP-preserved
highest fidelity — 8-bit everything, smallest quantization gap
Dagger-Qwen3.6-27B-MTP-BF16.gguf
~51 GB
protoLabsAI, MTP-preserved
full precision — unquantized BF16, no quantization gap at all; wants a big-memory machine
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.
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.
