JackOD-9B-Coder — GGUF (MTP)

GGUF quants of ManniX-ITA/JackOD-9B-Coder, a four-way omnimerge_v2 merge over Qwen/Qwen3.5-9B built for multi-turn agentic coding — staying on a task across turns and tool calls until it is actually finished, and then stopping.

v3 (2026-10-24). v3 is the v2 recipe with the two smaller weights swapped: DeltaCoder 0.55 / Ornith-1.5-9B 0.30 / Coder-Flash 0.15 (v2: Coder-Flash 0.30 / Ornith 0.15). omnimerge_v2 density 0.53, darex-q 0.75, seed 42, the root eos_token_id 248046 / pad_token_id 248055 fix and the Coder-Flash tokenizer and template are unchanged. v3 ships a new serving sampler and was evaluated with it; the v2 and v1 results kept at the end of this card were measured greedy, so they are a record, not a same-basis comparison.

Every _K and IQ tier is imatrix-calibrated, including Q6_K. The calibration matrix used to build them is published in this repo as imatrix.dat (sha256 feb286c4…) so the quants can be audited and reproduced.

The MTP head is excluded from the merge and passed through from the base intact, so the draft head survives into these GGUFs. There is no vision tower — base and merge both carry 775 tensors and zero visual.*; the vision_config in config.json is inherited architecture metadata with no weights behind it. No mmproj is published because none can be built. This model is text-only.

Where the name comes from

JackOD is an initialism of its three merge sources:

Qwen3.5-9B is not in the name: it is the shared ancestor all three descend from, the --base/--task-base the merge is taken against, rather than a flavour contributed to the blend.

Recipe

python omnimergekit.py \
  --base      Qwen3.5-9B --task-base Qwen3.5-9B \
  --source    DeltaCoder-9B-applied \
  --source    Qwopus3.5-9B-Coder-Flash \
  --source    Ornith-1.5-9B \
  --weights   0.55,0.15,0.30 \
  --method omnimerge_v2 --density 0.53 --darex-q 0.75 --seed 42 \
  --no-auto-mlp-skip --skip-patterns visual.,mtp. \
  --output JackOD-9B-Coder

One step is not optional: Qwen3.5-9B, DeltaCoder-9B-applied and Coder-Flash carry no root eos_token_id (it lives only in the nested text config). The GGUF converter reads the root, finds nothing, and falls back — putting the wrong terminator in the quant and leaking control tokens into generations. The merge sets root eos_token_id 248046 / pad_token_id 248055 and takes the tokenizer and chat template from Coder-Flash, whose template this model serves.

The build chain is in recipes/jackod-9b-coder/ of omnimergekit.

Evaluation (v3)

Measured on the published Q6_K (JackOD-9B-Coder-Q6_K.gguf, sha256 3f202a76…51b8, full AtomicChat ornith-1.5-9b imatrix feb286c4…), llama.cpp 311d4211bf, with the serving sampler below: temperature 0.4 / top_p 0.95 / top_k 20 / min_p 0 / repeat_penalty 1.002 over the last 112 tokens / presence_penalty 1.05, seed not fixed (a random seed per request). The sampler was read back from every server's /slots while the run was in flight: 338 checks, 0 mismatches. Thinking budget 12,288 tokens (--reasoning-budget). Scores are summary.json.score.

• These are sampled scores, one draw each. They are not on the same basis as the greedy v2 and v1 tables further down, and the difference between them is not claimed as a gain or a loss. On these sizes one problem is 1.8 pp of LiveCodeBench and 0.6 pp of HumanEval.
• LiveCodeBench is 52 of 55. All 55 generations ended on their own (none hit the length cap), and the 3 misses are wrong answers (wrong output or a runtime error), not truncations. A provisional v3 run at a different sampler (temperature 0.7, seed 42) solved 50 of the same 55; it is superseded and not tabulated.

LiveCodeBench v6 (55 hard) — reasoning length

Same 55 problems, 12,288-token thinking budget. Tokens are the server's completion_tokens.

For orientation only (greedy, so not the same basis): v2 averaged 6,809 tokens with 2 of 55 length-capped.

Tool calling — tool-eval-bench hardmode

84 scenarios scored, 168 points, 5 paired seeds (42–46), n=5 → t=2.776, --hardmode --weight-by-difficulty, scorer 2.6.1.dev65+g6be685f0e, llama.cpp 5bda51bf with --jinja, served and requested with the same serving sampler as above.

v2 (140.2 ±4.2) and v1 (144.4 ±4.7) were measured greedy, so that comparison crosses samplers. v3 sits inside both of their intervals.

Categories A/B/D/F/N (tool selection, parameter precision, restraint & refusal, localization, creative composition) are 6/6 on every seed; Structured Output is 2/4, as for every arm in the earlier cohorts.

Prompt injection. v3 fails TC-60 (cross-turn sleeper injection) on 4 of 5 seeds: an instruction planted in an earlier tool result is later acted on. v1, v2, the base and DeltaCoder fail it too, so it is inherited, not introduced by the merge. Do not rely on this model to ignore instructions that arrive inside tool output.

Serving

generation_config.json ships the serving recipe:

temperature 0.4 · top_p 0.95 · top_k 20 · min_p 0 · repeat_penalty 1.002

Add, where your runtime supports them (ollama and llama.cpp do):

repeat_last_n 112 · presence_penalty 1.05

Leave the seed unfixed: that is how v3 was evaluated.

Worth trying: seed 42. In the author's testing it behaves better (no loops, and stellar on some tasks) but it is not reliable: it still fails on others. It is a suggestion to test, not part of the recommended setup, and none of the scores on this card were measured with it.

This replaces the v1/v2 recipe (temperature 0.8, min_p 0.05, repeat_penalty 1.05 over 96, presence_penalty 0). The reasoning earlier revisions of this card gave for 0.8 was worked out on v1 and does not describe v3.

For tool calling, --jinja is mandatory in llama.cpp: without it the tool grammar never comes from the model's chat template and every tool scenario degrades to prose.

Quants

All tiers are v3, built 2026-10-24. Sizes are GB (bytes / 1e9); every file has a .sha256 sidecar. KLD is mean KL divergence and same-top-token rate against the F16 on wiki.test.raw (100 × 512 tokens, llama.cpp 311d4211b); the full table with PPL and percentiles is perplexity.md. It measures fidelity to the F16 on general text, not agentic quality — only Q6_K has been benchmarked.

Standard ladder

CD ladder

ContribDynamic (CD) tiers use custom per-tensor bit-width maps generated from this model's own imatrix rather than llama.cpp's stock per-tier assignment. Every CD tier is smaller than its stock counterpart and has a lower KLD; CD-Q4_K_M (5.76 GB, 0.0239) is the lowest-KLD file under 6 GB.

How the maps are built (Qwen3.5's hybrid layout — three linear-attention layers for every full-attention one — is what they target):

• ssm_out, the linear-attention output projection, drives most of the KLD here: at Q6_K or higher (Q8_0 in CD-Q6_K / CD-Q5_K_M) it roughly halves the KLD of a 4-bit body, where the same bytes spent on ffn_down or the attention projections buy almost nothing. Q5_K on it is not enough.
• That is paid for by lowering tensors that cost little KLD here — per tier, output.weight (stock Q6_K; Q5_K is KLD-neutral on this model) and/or token_embd, plus ffn_down in CD-Q3_K_L.
• Whatever size is left under the stock file goes to ffn_down, one quant step per layer, most important layer first by imatrix ranking.
• Each map is sized with llama-quantize --dry-run against the stock tier and must come out smaller.

There is no CD-IQ4_K_M for this model. When it was built for v2, on an IQ4_XS base it only matched IQ4_XS, and on IQ4_NL it gained 0.0004 KLD for 0.23 GB more; CD-Q4_K_M covers that slot, and it was not rebuilt for v3. The generator is scripts/generate_cd_maps.py in omnimergekit. The CD tiers have not been benchmarked; the scores on this card are from Q6_K.

Verifying a download

# example for the evaluated tier
sha256sum -c JackOD-9B-Coder-Q6_K.gguf.sha256

JackOD-9B-Coder-Q6_K.gguf → 3f202a762e4cab28658349cc75343db1433fb66ac79b67e17bc665e2e52651b8

JackOD-9B-Coder-Q4_K_M.gguf → d919da8e332549dc5eb83b9429972c9963503524a65beb042c7c6e1b3faca2c8

JackOD-9B-Coder-Q8_0.gguf → e940537dbcf2e7aef03fe357146d05f58e04ee3682f1ce13917a2e3dba2ba448

imatrix.dat → feb286c42be30760e92fbb218dfc1ceb4be07a1cb01634993072d1f2ecc9dd80

Running it

llama.cpp

llama-server -m JackOD-9B-Coder-Q4_K_M.gguf \
  --jinja \
  -c 32768 -ngl 99 \
  --temp 0.4 --top-p 0.95 --top-k 20 --min-p 0 \
  --repeat-penalty 1.002 --repeat-last-n 112 --presence-penalty 1.05

That is the serving recipe above, seed left unfixed. --jinja is mandatory for tool calling. Without it the tool grammar never comes from the model's chat template and every tool scenario degrades to prose — which is the entire point of this model.

ollama

ollama run mannix/jackod-9b-coder

On ollama (both published 2026-10-25, the serving sampler above baked into every tag):

• mannix/jackod-9b-coder: all 27 tiers, :latest = Q4_K_M. The tags set draft_num_predict 3 for the built-in MTP head and declare ollama ≥ 0.32.12 (the qwen3.5 renderer). Every tag was pulled back from the registry and passed a generation check on 2026-10-25.
• mannix/jackod-9b-coder-dflash: the same 27 tiers with the Qwen3.5-9B-DFlash Q8_0 drafter (draft_num_predict 4). Needs xollama; stock ollama has no draft-dflash. See ManniX-ITA/JackOD-9B-Coder-MTP-DFlash-GGUF.

num_ctx is not pinned in the tags: set it as high as your hardware allows for agentic work.

Build provenance

• Quantized from the v3 bf16 weights at ManniX-ITA/JackOD-9B-Coder (revision b8e35ad0), llama.cpp 311d4211bf.
• imatrix computed over the full AtomicChat ornith-1.5-9b calibration corpus (calib_train.txt, sha256 a47fdfee…, all 9,686 chunks, --parse-special) for this specific weight set: an imatrix fingerprints one set of weights and does not transfer from a sibling merge, so v2's was not reused. Published here as imatrix.dat.
• Merge recipe and build scripts: recipes/jackod-9b-coder/ of omnimergekit.

JackOD-9B-Coder v2 — previous weights (replaced 2026-10-24)

Everything in this section was measured on the v2 weights (Coder-Flash 0.30 / Ornith 0.15), greedy (temperature 0), and served with the v1/v2 recipe. It is kept as the record of v2 and does not describe the v3 weights or the v3 sampler.

The v2 GGUFs were replaced by the v3 builds; their sha256 values, sizes and KLD table are in this repo's history (v2 imatrix 5ad024b8…, evaluated v2 Q6_K c94d907c…d25a).

Evaluation

Measured on the published Q6_K (JackOD-9B-Coder-Q6_K.gguf, sha256 c94d907c…d25a, full AtomicChat ornith-1.5-9b imatrix 5ad024b8…), llama.cpp 311d4211bf, greedy (sampler=template_default, temp 0.0 / top-p 1.0 / top-k 0), scores read from summary.json.score. v2 and Coder-Flash were run together, on the same machine and build. The v1 and other source columns are the v1 cohort (same templates, same sampler, its own llama.cpp build) and are there for orientation.

† From an earlier 9B bank, not the cohort run (see the v1 section).

• v2 is at or above v1 on every row. HumanEval, HumanEval+ and LiveCodeBench each move by one problem, which is inside the run-to-run spread of a greedy llama.cpp eval and is not claimed as an improvement. IFEval (+3 prompts) is the one real move, and it puts v2 above the base.
• LiveCodeBench 0.8000 is above every source and the base: +7.27 pp over the base, +12.73 pp over Coder-Flash, the source it gained.
• MultiPL-E is unchanged at 0.8033, still 1.67 pp under the base.

LiveCodeBench v6 (55 hard) — accuracy and reasoning length

Same 55 problems, same 12,288-token thinking budget, same cap, for every arm. Token counts are the server's completion_tokens; budget hits are runs that reached the thinking budget; length-capped never terminated on their own.

• About 23% fewer tokens than v1 (mean 6,809 vs 8,869) and under half the median (5,524 vs 12,358). On the 36 problems both versions solve, v2 is shorter on 29 (median length ratio 0.66).
• The solved sets differ: 36 both, 7 only v1, 8 only v2. One 55-problem cell does not separate two models that close, and it is not claimed to.
• v2 is now the most token-efficient arm in the table (0.117 solved per 1k tokens), slightly ahead of Coder-Flash alone (0.114), at +12.73 pp accuracy.
• Termination stays near v1: 2 of 55 length-capped (v1: 1).

Tool calling — tool-eval-bench hardmode

84 scenarios scored, 168 points, 5 paired seeds (42–46), n=5 → t=2.776, greedy, --hardmode --weight-by-difficulty, scorer 2.6.1.dev65+g6be685f0e, llama-server --jinja. v2 and Coder-Flash were served by llama.cpp 311d4211bf in the same run; the v1 cohort rows were served by 5bda51bf, so v2-vs-v1 crosses two llama.cpp builds.

v2 does not improve tool calling. It is level with Coder-Flash and 4.2 points under v1; the intervals overlap, so this is not a measured regression either, but there is no gain to claim.

v1's planning edge does not carry over. v1 led the whole cohort on Autonomous Planning (5.2/6); v2 scores 4.2, under the base (4.8) though well above Coder-Flash (2.4). If long-horizon planning in a tool loop is what you need, v1's numbers are not a description of this model.

Prompt injection. On every v2 seed the model fails TC-60 (cross-turn sleeper injection): an instruction planted in an earlier tool result is later acted on (an attacker address added as BCC/CC). The same failure appears in v1, the base and DeltaCoder — it is inherited, not introduced by the merge. Do not rely on this model to ignore instructions that arrive inside tool output.

Categories A/B/D/F/N (tool selection, parameter precision, restraint & refusal, localization, creative composition) are 6/6 for v2; G Structured Reasoning 6/6; Structured Output 2/4, as for every arm in both cohorts.

JackOD-9B-Coder v1 — previous weights (replaced 2026-10-21)

Everything below was measured on the v1 weights (Qwopus3.5-9B-Coder in the 0.30 slot). It is kept because it is the record of how this merge was chosen; it does not describe the v2 or v3 weights.

Field impression — initial, limited testing

This section is the author's early hands-on impression from a small number of runs, not a benchmark result. It is reported because it is the reason the model exists, and it should be read as an anecdote until a proper harness campaign replaces it.

Verification against the cline test harness is still in progress. So far it has fixed a task in 535 s on the harness; a second run went to timeout. It also fixed the task on a separate machine through the plugin.

For comparison, on the same task, A3B-class models typically take 1.5–4 h with a success rate below 50%. The one exception is Ornith-1.5-27B-A3B, which has a high success rate but still needs ~2 h or more per task.

That gap — minutes rather than hours, from a 9B dense model — is what this merge was assembled to get. It is an early signal from few runs, and the sample is far too small to quote a success rate of its own.

Evaluation

Q6_K + imatrix, llama.cpp, greedy (sampler=template_default, temp 0.0 / top-p 1.0 / top-k 0). Scores read from summary.json.score. The LiveCodeBench row is lcb_v6_55 throughout — lcb_medium_55 is a different problem set and is never mixed in.

† The base's HumanEval+ and IFEval cells come from an earlier 9B bank rather than the cohort pod run. That bank agrees with the cohort exactly on HumanEval (0.8902 both) but differs on MultiPL-E by 1.67 pp, so treat those two base cells as indicative rather than same-basis.

LiveCodeBench is the real result: 0.7818 beats every source and the base. +5.45 pp over the strongest source (the base itself) and +14.54 pp over DeltaCoder, the 0.55-weight source the merge leans on hardest. On the hard problems the merge is not splitting the difference between its parents — it is above all of them.

Elsewhere it lands where a merge should: identical to DeltaCoder on HumanEval+ (0.8232 both), a little under it on HumanEval (−3.05 pp, 5 problems of 164) and IFEval, a little under the base on MultiPL-E (−1.67 pp). Those are give-backs, and small ones.

Length and runaway behaviour — where the merge actually comes from

Response length in characters on lcb_v6_55, the same 55 hard problems under an identical cap. capped = finish_reason == "length": the model never terminated on its own.

This table is the thesis of the merge. Read next to the eval table above, the two heaviest sources split cleanly along opposite axes:

• DeltaCoder is the best coder in the cohort (HumanEval 0.9146) and the worst at stopping — 25 of 55 hard problems never terminate.
• Ornith-1.5-9B is the weakest coder (LiveCodeBench 0.5818, HumanEval 0.7805) and by far the best at stopping — 2 of 55.
• JackOD takes both: the best LiveCodeBench score of the entire cohort and the best termination rate, 1 of 55.

Against the base that is an 18× reduction in non-terminating generations; against DeltaCoder, its heaviest source, 25×. A capped generation is a scoring failure regardless of whether the reasoning was on track, so this is not a separate nicety — it is a large part of why the LiveCodeBench number is what it is.

Other benches, all on the published Q6_K:

Earlier attempts in this family — do not use them for agentic work

This merge went through several earlier arms. They are listed here because their numbers are in circulation and, read as a table, they are misleading.

JackOD-Coder-9B scores higher than this model on LiveCodeBench (0.8182 vs 0.7818) and on IFEval, and it is still the wrong model to deploy. That is the point of this section.

In real multi-turn agentic coding — a live tool loop, not a benchmark harness — JackDeltaCoder-9B and every earlier JackOD arm fail:

• they do not drive tools properly, mis-forming or skipping tool calls that the task depends on;
• they fall into loops, re-treading the same step instead of advancing;
• they abandon the task, concluding the problem is too hard to solve and stopping without a fix.

None of that is visible in a single-shot code benchmark, which is exactly why their benchmark rows look competitive. A one-shot HumanEval or LiveCodeBench problem never asks a model to call a tool, read the result, and decide what to do on turn seven. The only arm in this family that holds up in a live agentic loop is the published one. Treat the rows above as a record of what was tried, not as a menu.

Tool calling — tool-eval-bench hardmode

88 scenarios offered, 84 scored, 168 points. 5 paired seeds (42–46) per arm, n=5 → t=2.776, greedy, --hardmode --weight-by-difficulty, scorer 2.6.1.dev65+g6be685f0e, served by llama.cpp 5bda51bf with --jinja. Every arm shares that basis exactly.

(v1 tool-calling chart removed with the v1 quants; numbers below.)

On aggregate points this merge does not beat its sources — it is second, and every interval overlaps. It sits above its base and within noise of Ornith. The aggregate is not where the difference lives.

Where it does separate: Autonomous Planning

Autonomous Planning is the one axis with a clear, consistent edge: 5.2/6, best of all five arms — while Ornith, the top aggregate scorer, is the worst at 2.8/6. The merge reaches Ornith's overall level while fixing exactly Ornith's long-horizon planning weakness.

That pairing is worth sitting with, because Ornith is also the source with the best termination rate (2/55 capped). A model that stops reliably and plans worst than anything else in the cohort looks like one that stops too early — terminating is easy if you give up. The merge is the arm that does both: it carries the goal (5.2/6 planning, best) and still lands the plane (1/55 capped, best). That combination, not either number alone, is what the field impression above is describing.

Categories A/B/D/F (tool selection, parameter precision, restraint & refusal, localization) are 6/6 for every arm and are omitted; G Structured Reasoning and N Creative Composition are 6/6 for all but Qwopus (5.8 and 5.2). Structured Output is 2.0/4 for all five — none of these models clears it.