ManniX-ITA/JackOD-9B-Coder-MTP-GGUF

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.

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.6 · top_p 0.95 · top_k 20

Add presence_penalty 1.5 where your runtime supports it (ollama and llama.cpp do; HF GenerationConfig has no such field). On long agentic runs that penalty is doing real work — it is what discourages re-treading a tool call that already happened.

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.