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.
This is the full fidelity BF16 MTP MLX with vision. For the benched non-mtp Q6 MLX, go here.
Dagger is ThinkingCap-Qwen3.6-27B in with the Sharp template + terseness prompt baked in.
Backend: MTP tested on latest oMLX. This model can be used on any MLX backend, MTP is ignored on those that don't support it.
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.
All benchmarks on Mac Studio M2 Ultra 64 GB, oMLX, 8bit KV cache, on the 6-bit non-MTP MLX build (this bf16 MTP build is the same recipe).
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 — and this build wants more
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.
On top of that, the weights are ~52 GB at bf16. Full 262k context costs Dagger 38.6 GB at 16-bit KV (31.1 GB at 8-bit, measured on the 6-bit build) — so budget weights + KV and give it a big-memory Mac. On a small machine the marathon argument favours Nail, or use a smaller non-MTP quant.
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 chat_template.jinja.
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) |
| Precision | bf16 (this repo; nextn/MTP head preserved) |
| MTP | nextn draft head preserved for MLX self-speculative decoding |
| 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 — this VLM conversion keeps the vision tower (unlike the old 6-bit MLX, which dropped it) |
| On disk | ~52 GB (bf16). Budget weights + KV for full context |
| Template | froggeric's fixed Qwen template, with Dagger's system prompt force-appended |
| Weights changed | None — MLX conversion of the original weights |
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 |
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.
| 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 |
(*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 6-bit non-MTP MLX build, not on this file. This is the bf16 MTP conversion; the plates were run on the flat 6-bit MLX build without the MTP head. MTP is lossless (the target verifies every draft) and more bits only help, so nothing here should score lower — but we have not re-run the suite on this exact file.
What we did measure, on the 6-bit MLX weights, is baseline decode speed: ~24.5 tok/s on an M2 Ultra (2k prompt, 128 generated, n=3), 8-bit KV free (24.5 either way). bf16 carries more weight bytes and decodes a little slower before MTP — then self-speculation claws it back. On our own box (oMLX, Dagger 4-bit, coding @ 0.7) MTP ran ~1.10× at 84–97% draft acceptance; bf16 wouldn't load on 64 GB to measure directly, but its heavier weights give the batched verify more to amortize, so it should do at least as well.
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 these files.
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. MTP does not change what these settings do — the accepted tokens are exactly the ones the target would have produced. Gains are highest at coding temperatures on structured text; creative prose accepts fewer drafts.
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
# bf16 weights live at the repo root — download the whole repo
hf download peculiar-ragdoll/Dagger-Qwen3.6-27B-MLX-MTP-BF16 --local-dir Dagger-MLX-MTP-BF16
# --- with MTP (self-speculative decoding via the built-in nextn head) ---
# oMLX 0.5.7+ — native MTP; serve, then turn on `mtp_enabled` for the model
omlx serve Dagger-MLX-MTP-BF16
# or mlx-lm PR #990 (feat/mtp-native branch):
mlx_lm.generate --model Dagger-MLX-MTP-BF16 --mtp --prompt "..."
# --- without MTP (any current mlx-lm; the nextn head sits unused) ---
mlx_lm.generate --model Dagger-MLX-MTP-BF16 --prompt "..."
bf16 is native on M3/M4/M5; on M1/M2 (no GPU bf16) load with --dtype float16.
Quantizing to fit smaller systems
This repo is bf16 only. Quantizing it yourself (mlx_lm.convert -q) drops the nextn head — the
MLX converters sanitize mtp.* out — so you'd lose MTP. For smaller builds use the non-MTP sibling
repos (-MLX /
-GGUF). MTP also needs headroom for
the draft/verify buffers on top of the ~52 GB weights.
Limitations and out-of-scope use
- The benchmarks above are not from these files — they're the 6-bit non-MTP MLX build. See What the numbers are, and aren't. Lossless MTP and bf16 should not score lower, but the exact-file suite is unrun.
- MTP needs an MTP-aware runtime.
- The prompt is not removable through the API. It lives in the embedded
chat_template.jinja. Any deployment that needs unmodified base behavior should use bottlecap's original. - Vision is unbenchmarked (but present). This VLM conversion keeps ThinkingCap's vision tower — unlike the old 6-bit MLX build, which dropped it — so images work, but no benchmark on this page covers vision.
- Long context wants RAM. ~86.5 KiB/token at 16-bit KV on top of the ~52 GB weights — bf16 + full context wants a big-memory Mac. On less memory, use a smaller non-MTP quant or a GGUF build.
- 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.
- 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.
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. Those runs were the 6-bit non-MTP MLX build; this file adds the MTP head to the bf16 build.
- The benchmarked build is 6-bit non-MTP. Numbers don't automatically transfer to bf16, but MTP is lossless and more bits only help — read the plates as a floor for this file, not a ceiling.
- 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.
- 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, and the built-in MTP head.
- bottlecap — the ThinkingCap finetune that does the heavy lifting on thinking length, and the weights (with the
nextnhead) this build converts. - froggeric — the fixed Qwen chat template.
- MLX / mlx-lm — the runtime and conversion tooling.
- MTPLX and mlx-lm PR #990 (AirRunner) — the MLX-native MTP speculative-decoding backends this build's
nextnhead is kept for. - jundot — oMLX, which every benchmark here ran on.
- The Pi coding agent team.
Citation
@misc{Dagger-27B-MLX-MTP,
title = {Dagger-Qwen3.6-27B-MLX-MTP},
author = {Saga Ishtardottir},
year = {2026},
url = {https://huggingface.co/peculiar-ragdoll/Dagger-Qwen3.6-27B-MLX-MTP},
note = {bf16 MLX conversion of ThinkingCap-Qwen3.6-27B with a fixed chat template, an always-on terseness prompt, and the multi-token-prediction (nextn) head preserved for MLX MTP speculative decoding}
}
License
Apache-2.0, inherited from ThinkingCap-Qwen3.6-27B and Qwen3.6-27B.
- Downloads last month
- 508
Quantized