Rejected no longer in llama-swap.yaml — entry and/or weights removed after this verdict.
| Run | Score | tok/step | Log |
|---|---|---|---|
| No results-*.log found under this name. | |||
Added to llama-swap.yaml (port 9110), same weights/sampler/split as
[[kimi-distill]] (the box's fastest 256k model, ~100-106 t/s), --parallel 2
→ 131072/slot. Lower-risk than [[fable-fusion-x2-trial]]: no MTP draft head
(nothing to duplicate per-slot) and solo already had ~3.5-5GB free/GPU vs
fable's ~1.1-1.4GB. Unlike the fable trial, this one got the FULL treatment:
standard grill + two rounds of deliberate concurrent agentic testing, because
the user asked to fully test parallel agentic coding specifically.
Full grill (rounds 1-5): 21/23 — identical score to solo kimi-distill (r1
6/8: expr_eval + damerau_levenshtein failed this run vs expr_eval + text_justify
last time — same lineage-hard-task variance, not a regression). r2-r4 all
5/5. Round 5: 6/6 COMPLETE, 0/6 looped, 0% redundant calls — a clean sweep
on the exact test that caught coder-x4's real problem. Decode ~85-106 t/s,
matching solo kimi-distill despite the halved (131072) per-slot context.
Instance A: 4/5 — clarify_missing FAILED by burning the full 8000-token
budget with no answer (a genuine runaway, not a wrong answer). Instance B:
5/5 clean. Disambiguated: re-ran clarify_missing 4x solo + 6x in
concurrent pairs = 10/10 clean. The one failure did not reproduce under
either condition — ordinary low-rate flakiness (~1/13 ≈ 7.7% overall), NOT a
systematic concurrency bug (contrast with bonsai-fast's dspark bug, which
had an identical, ~50%-reproducible failure signature).
Per-stream decode under 2-way concurrency: ~84 t/s (A) / ~66 t/s (B) vs ~87.6
t/s solo → aggregate ~150 t/s ≈ 1.72x, consistent with this box's
established memory-bandwidth-bound pattern ([[decode-bandwidth-ceiling]];
bonsai-duo was ~1.73x, fable-fusion-x2 ~1.63x, coder-x4 1.43-1.86x).
Both instances: 5/6, and — notably — both failed the SAME task
(test_driven_loop, same description: "fixed blind: ran the suite only once,
never re-verified after editing"). This pattern (identical task, identical
failure) looked suspicious enough to warrant the same disambiguation as
clarify_missing. Re-ran test_driven_loop 4x solo: 2 FAIL / 2 PASS —
a genuine ~50-57% baseline flake rate for this model on this specific task
(TDD-style: fix bug, but don't bother re-running the test suite to confirm),
independent of concurrency. Both concurrent runs failing was coincidence
(≈25% chance if independent at 50% each), not causation.
Zero loops, zero redundant tool calls in every single round5 run (solo
and both concurrent instances) — the actual thing this trial needed to prove
safe.
Clean bill of health on the dimension that matters most (loop-safety
under concurrency, the exact failure mode that retired coder-x4): 3/3
round5 runs (1 solo + 2 concurrent) at 0% looping, 0% redundant calls. The
two observed failures are both pre-existing per-task model weaknesses
(clarify_missing ~8% flake, test_driven_loop ~50% flake) present with or
without concurrency — not regressions introduced by --parallel 2.
How to apply: safe to recommend for real 2-agent concurrent agentic
coding work. Known weak spot to flag when assigning tasks: TDD-style
"fix then re-verify" loops are a coin flip for this model regardless of
concurrency — don't trust a single clean pass on that task shape without a
re-verification check of your own.
User asked to make both -x2 entries permanent, client-visible entries.
Propagated through bin/gen_kilo_config.py (SHORT/REASONING/DISPLAY, regen
kilo.jsonc), ~/.config/opencode/opencode.json, ~/.kimi/config.toml, and
the local-model-router skill (new dedicated concurrent-multi-agent row).
Given this trial's full grill + concurrent loop-safety verification, this is
the more solidly-earned of the two promotions — see [[fable-fusion-x2-trial]]
for the sibling that was promoted without the same rigor.