---

license: apache-2.0

base_model:

• ManniX-ITA/JackOD-9B-Coder

base_model_relation: quantized

library_name: gguf

pipeline_tag: text-generation

language:

• en

tags:

• agentic
• code
• gguf
• imatrix
• merge
• qwen3.5
• tool-calling

model_name: JackOD-9B-Coder-MTP-GGUF

author: ManniX-ITA

architecture: Qwen3.5

parameters: 9.65B

format: GGUF

quantizations:

• CD-IQ4_K_M
• CD-Q2_K
• CD-Q3_K_L
• CD-Q4_K_M
• CD-Q5_K_M
• CD-Q6_K
• F16
• IQ2_M
• IQ2_S
• IQ2_XS
• IQ3_M
• IQ3_XS
• IQ3_XXS
• IQ4_NL
• IQ4_XS
• Q2_K_L
• Q3_K_L
• Q3_K_M
• Q3_K_S
• Q3_K_XL
• Q4_K_L
• Q4_K_M
• Q4_K_S
• Q5_K_L
• Q5_K_M
• Q5_K_S
• Q6_K
• Q6_K_L
• Q8_0

features:

• MTP
• code
• imatrix
• reasoning
• vision

---

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.

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 so the quants can be audited and reproduced.

| role | model | weight |

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

| base / task-base | Qwen/Qwen3.5-9B | — (shared ancestor) |

| source | danielcherubini/Qwen3.5-DeltaCoder-9B | 0.55 |

| source | Jackrong/Qwopus3.5-9B-coder | 0.30 |

| source | ornith-ai/Ornith-1.5-9B | 0.15 |

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:

| letter | source |

|---|---|

| Jack | Jackrong/Qwopus3.5-9B-coder — JackRong's Qwopus 9B |

| O | ornith-ai/Ornith-1.5-9B |

| D | danielcherubini/Qwen3.5-DeltaCoder-9B |

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.

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.

Recipe

Full reproducible chain, including the scripts that built it:

recipes/jackod-9b-coder/

in omnimergekit.

python omnimergekit.py \
  --base      Qwen3.5-9B --task-base Qwen3.5-9B \
  --source    DeltaCoder-9B-applied \
  --source    Qwopus3.5-9B-Coder \
  --source    Ornith-1.5-9B \
  --weights   0.55,0.30,0.15 \
  --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 and DeltaCoder-9B-applied 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.

patch_jackod.py copies the root EOS, tokenizer and chat template from Qwopus,

whose chat template this model serves.

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.

| Benchmark | JackOD-9B-Coder | Qwen3.5-9B (base) | DeltaCoder-9B (0.55) | Qwopus3.5-9B-Coder (0.30) | Ornith-1.5-9B (0.15) |

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

| HumanEval (164) | 0.8841 | 0.8902 | 0.9146 | 0.8537 | 0.7805 |

| HumanEval+ (164) | 0.8232 | 0.8049 † | 0.8232 | 0.7988 | 0.7073 |

| LiveCodeBench v6 (55 hard) | 0.7818 | 0.7273 | 0.6364 | 0.6000 | 0.5818 |

| MultiPL-E (300) | 0.8033 | 0.8200 | 0.8000 | 0.8200 | 0.7267 |

| IFEval (100) | 0.9100 | 0.9300 † | 0.9200 | 0.8800 | 0.8200 |

† 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.

| model | capped / 55 | p50 | p90 | max | >20k |

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

| DeltaCoder-9B (0.55) | 25 | 37,524 | 50,555 | 77,590 | 54 |

| Qwen3.5-9B (base) | 18 | 37,984 | 49,376 | 53,564 | 53 |

| Qwopus3.5-9B-Coder (0.30) | 8 | 29,261 | 43,261 | 59,633 | 41 |

| Ornith-1.5-9B (0.15) | 2 | 28,722 | 50,278 | 56,571 | 28 |

| JackOD-9B-Coder | 1 | 29,282 | 45,749 | 89,324 | 37 |

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:

| Benchmark | p50 | p90 | max | >20k |

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

| HumanEval (164) | 590 | 1,192 | 60,219 | 1 |

| HumanEval+ (164) | 590 | 1,182 | 5,961 | 0 |

| MultiPL-E (300) | 257 | 539 | 1,007 | 0 |

| IFEval (100) | 791 | 3,160 | 11,660 | 0 |

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.

| arm | HumanEval | HumanEval+ | LCB v6 (55) | MultiPL-E | IFEval | capped / 55 |

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

| JackOD-Coder-9B | 0.8232 | 0.7683 | 0.8182 | 0.7933 | 0.9300 | 3 |

| JackOD3.5-9B | 0.8659 | — | 0.7455 | — | — | 7 |

| JackDeltaCoder-9B | 0.8415 | 0.7683 | 0.6364 | 0.8067 | 0.9200 | 8 |

| JackOD-9B-Coder (this model) | 0.8841 | 0.8232 | 0.7818 | 0.8033 | 0.9100 | 1 |

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

!Tool-calling benchmark

| model | role | total points (mean, 5 seeds) | 95% CI |

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

| Ornith-1.5-9B | source | 145.6 ±4.2 | [141.4, 149.8] |

| JackOD-9B-Coder | merge | 144.4 ±4.7 | [139.7, 149.1] |

| Qwen3.5-9B | base | 142.0 ±3.9 | [138.1, 145.9] |

| DeltaCoder-9B | source | 139.6 ±5.7 | [133.9, 145.3] |

| Qwopus3.5-9B-Coder | source | 132.6 ±3.6 | [129.0, 136.2] |

**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

| category | JackOD | Ornith | base | DeltaCoder | Qwopus |

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

| M Autonomous Planning (6) | 5.2 | 2.8 | 4.8 | 4.0 | 3.6 |

| H Instruction Following (10) | 9.6 | 9.2 | 9.2 | 8.8 | 8.0 |

| I Context & State (20) | 17.0 | 17.2 | 16.4 | 16.2 | 15.2 |

| P Hard Mode (38) | 29.8 | 30.2 | 29.8 | 28.2 | 26.0 |

| C Multi-Step Chains (8) | 7.4 | 8.0 | 6.6 | 7.2 | 5.2 |

| K Safety & Boundaries (26) | 20.2 | 21.4 | 19.2 | 19.6 | 21.4 |

| L Toolset Scale (8) | 6.8 | 7.8 | 7.2 | 7.2 | 6.8 |

| E Error Recovery (6) | 4.6 | 5.0 | 5.0 | 5.0 | 3.4 |

| J Code Patterns (6) | 5.8 | 6.0 | 5.8 | 5.4 | 6.0 |

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

Serving

generation_config.json ships the serving recipe:

temperature 0.8 · top_p 0.95 · top_k 20 · min_p 0.05 · repeat_penalty 1.05

Add, where your runtime supports them (ollama and llama.cpp do; HF

GenerationConfig has neither field):

repeat_last_n 96 · presence_penalty 0

The published mannix/JackOD-9B-Coder ollama tags carry exactly this set.

Temperature is not a free parameter here

0.8 is a deliberate middle, because the failure modes sit on both sides of

it and they are different failures:

• Lower degrades coding ability first. Push it further down and

hallucinations and erratic behaviour follow.

• Higher makes the model less willing to use its tools — it drifts

toward writing its own scratch scripts instead of calling what it already has.

Neither symptom announces itself as a sampler problem, which is why the value is

stated rather than left to taste.

On the repetition controls

Earlier revisions of this card recommended presence_penalty 1.5. That has been

replaced by repeat_penalty 1.05 over a repeat_last_n 96 window, with

presence_penalty back at 0. The job is the same — discouraging the model from

re-treading a tool call it already made — but a bounded recent-token window does

it without the broad, unbounded pressure a large presence penalty puts on every

token the model has ever emitted.

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 sizes are GB (bytes / 1e9). Every file has a .sha256 sidecar next to it in

this repo. Every _K and IQ tier here is imatrix-calibrated — including

Q6_K, which is often shipped uncalibrated elsewhere.

Standard ladder

| tier | size | notes |

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

| Q8_0 | 9.79 GB | near-lossless; reference for comparing the lower tiers |

| Q6_K_L | 8.05 GB | Q6_K with the output/embedding tensors at Q8_0 |

| Q6_K | 7.56 GB | the evaluated tier — every score on this card was measured on this file |

| Q5_K_L | 7.27 GB | |

| Q5_K_M | 6.64 GB | |

| Q5_K_S | 6.47 GB | |

| Q4_K_L | 6.53 GB | |

| Q4_K_M | 5.78 GB | the practical default — fits 8 GB VRAM with room for a usable agentic context |

| Q4_K_S | 5.49 GB | |

| Q3_K_XL | 5.63 GB | |

| IQ4_NL | 5.56 GB | |

| IQ4_XS | 5.33 GB | best quality under 5.5 GB |

| Q3_K_L | 5.05 GB | |

| Q2_K_L | 4.91 GB | |

| Q3_K_M | 4.74 GB | |

| IQ3_M | 4.52 GB | |

| IQ3_XS | 4.38 GB | |

| Q3_K_S | 4.36 GB | |

| IQ3_XXS | 4.08 GB | |

| IQ2_M | 3.74 GB | |

| IQ2_S | 3.56 GB | |

| IQ2_XS | 3.42 GB | smallest; expect real quality loss on agentic work |

| F16 | 18.41 GB | unquantized source for the ladder; no imatrix applies |

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 — the same idea as Unsloth's UD quants, built from our own imatrix.

The map spends extra bits on the tensors the imatrix flags as most sensitive, so

a CD- file is slightly larger than its stock namesake and should hold up

better at the same nominal tier.

| tier | size | stock counterpart |

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

| CD-Q6_K | 7.72 GB | 7.56 GB |

| CD-Q5_K_M | 6.79 GB | 6.64 GB |

| CD-IQ4_K_M | 6.04 GB | — |

| CD-Q4_K_M | 5.91 GB | 5.78 GB |

| CD-Q3_K_L | 5.63 GB | 5.05 GB |

| CD-Q2_K | 4.91 GB | — |

These are not separately benchmarked — the eval table above is Q6_K. The

CD ladder is offered as a better-shaped quant at a given size, not as a measured

improvement.

Verifying a download

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

JackOD-9B-Coder-Q6_K.gguf

→ abd45a375a1e19193a586bde088c1960f51935f9e7acb0a83e9c3321a031b248

JackOD-9B-Coder-Q4_K_M.gguf

→ 791af3acafeb26348d7e5784f6cdec9357d8020b43207df30340292cd87d268a

JackOD-9B-Coder-Q8_0.gguf

→ 6a5f16b9169c6f2b5e7c6347a282b5430bd7cde688c2e5396b8e55fe8e47a499

Running it

llama.cpp

llama-server -m JackOD-9B-Coder-Q4_K_M.gguf \
  --jinja \
  -c 32768 -ngl 99 \
  --temp 0.6 --top-p 0.95 --top-k 20 --presence-penalty 1.5

--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

Published at mannix/JackOD-9B-Coder

with the sampler and presence penalty already set in the Modelfile. num_ctx is

deliberately not pinned in the published template — set it to whatever your

hardware affords, which for agentic work you will want as high as it will go.

Build provenance

• Quantized from the bf16 weights at

ManniX-ITA/JackOD-9B-Coder.

• imatrix computed over the full AtomicChat calibration corpus for **this

specific weight set** — an imatrix fingerprints one set of weights and does

not transfer from a sibling merge. Published here as imatrix.dat.

• Merge recipe and every build script:

recipes/jackod-9b-coder/

in omnimergekit.