JackOD-9B-Coder — a 9B merge tuned for multi-turn agentic coding

~9B dense · Qwen3.5-9B lineage · text-only · MTP draft head intact · 4-way omnimerge_v2 merge

A four-way merge over Qwen3.5-9B built for one job: staying on a coding task across turns and tool calls until it is actually finished, and then stopping. It is not built to win knowledge benchmarks, and its world knowledge is limited for its size. What it does is finish, and stop — and on the hardest code benchmark in the set it is the best model in its own family tree.

Full model card & methodology: ManniX-ITA/JackOD-9B-Coder (weights) · GGUF repo · full build recipe.

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. The MTP head (15 tensors) is excluded from the merge and passed through from the base, so the draft head survives.

There is no vision tower. config.json inherits a populated vision_config from the Qwen3_5ForConditionalGeneration architecture, but that is metadata with no weights behind it: base and merge both carry 775 tensors and zero visual.*. No mmproj exists and none can be built — there are no vision- tags for this model, and it is text-only.

Field impression — initial, limited testing

This is the author's early hands-on impression from a small number of runs, not a benchmark result. It is here because it is the reason the model exists, and 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. Minutes rather than hours, from a 9B dense model, is what this merge was assembled to get — on a sample far too small to quote a success rate of its own.

Evaluation (Q6_K + imatrix, llama.cpp, greedy — 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.67pp — 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.45pp over the strongest source (the base itself) and +14.54pp 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.05pp, 5 problems of 164) and IFEval, a little under the base on MultiPL-E. Small give-backs.

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 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 a large part of why the LiveCodeBench number is what it is.

Other benches, all on the published Q6_K — HumanEval p50 590 / max 60,219 / 1 over 20k · HumanEval+ p50 590 / max 5,961 / 0 · MultiPL-E p50 257 / max 1,007 / 0 · IFEval p50 791 / max 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 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 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 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 offered, 84 scored, 168 pts)

5 paired seeds (42–46) per arm, n=5 → t=2.776, greedy, --hardmode --weight-by-difficulty. Every arm shares that basis exactly — same scorer build, same llama.cpp build, same denominator.

On aggregate points the 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: Ornith is also the source with the best termination rate (2/55 capped). A model that stops reliably and plans worse 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 describes.

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. Structured Output is 2.0/4 for all five — none of these models clears it.

Which tier to pull

Every _K and IQ tier is built with an importance matrix, including Q6_K, from this model's own imatrix — an imatrix fingerprints one specific weight set and cannot be shared with a sibling merge. Sizes are GB (bytes ÷ 1e9).

CD ladder

ContribDynamic (CD) tags use custom per-tensor bit-width maps generated from this model's own imatrix instead of 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. They are not separately benchmarked — the eval tier is stock Q6_K.

Pull

ollama run mannix/JackOD-9B-Coder              # default tag
ollama run mannix/JackOD-9B-Coder:Q4_K_M      # recommended
ollama run mannix/JackOD-9B-Coder:Q6_K        # the eval tier
ollama run mannix/JackOD-9B-Coder:CD-Q4_K_M   # imatrix-shaped ladder

Sampler

The published Modelfile already sets:

temperature      0.6
top_p            0.95
top_k            20
presence_penalty 1.5

presence_penalty 1.5 is doing real work on long agentic runs — it is what discourages re-treading a tool call that already happened. Don't drop it because it looks unusual.

num_ctx is deliberately not pinned in the published template. Set it to whatever your hardware affords — for agentic work you want it as high as it will go, and a template-pinned value would silently cap you below that.

Good to know

• The benchmark sampler is not the serving sampler. Every number on this card was measured at greedy (temp 0.0) because that is the only setting under which variants are comparable. The tags ship at temp 0.6 because that is what serves better. Don’t expect to reproduce the table with the default tag as-is.
• Knowledge is the trade. This is a 9B tuned toward finishing agentic tasks, not toward knowing things. If you need breadth of world knowledge, this is the wrong model — use it as the thing that drives the tools.
• MTP head is intact and passed through from the base rather than averaged, so speculative decoding remains available on runtimes that support it.
• Every tier has a published SHA-256 in the GGUF repo, alongside the imatrix.dat used to build them.