Q2_g64

• Build of llama.cpp on 5 runs was 0.4.0-dev (build 10893, commit c32d1dabe), now 0.2.0-dev (build 10618, commit eb25b7263). The runs finished before llama.cpp was upgraded that day, so the serving build was b10618; the stamp was read after the upgrade.

  Corrected 24 October 2026 · a mechanical fix

• Schema evidence corrected. A nullschema run is in the run log; schema enforcement was never probed, so it is unproven rather than absent.

  Corrected 24 October 2026 · a mechanical fix

Where it came from

• Source: prism-ml/Ternary-Bonsai-27B-gguf, file Ternary-Bonsai-27B-Q2_g64.gguf. The HF page listing the assistant read on 2026-09-10 offered two 27B builds: PQ2_0 "for PrismML fork" and Q2_g64 for upstream llama.cpp. Eight files were listed in the repo, including F16, Q2_0, DSpark drafters and two mmproj files; only this one was fetched.
• Revision / sha256: not on record (the download was six parallel curl -r ranges concatenated, no revision pin; models/ternary-bonsai-27b/ was deleted, so no .metadata survives).
• Downloaded: 2026-09-10 07:42Z, to models/ternary-bonsai-27b/, by six parallel range requests. Complete at 07:46Z.
• Header facts (read from the GGUF on 2026-09-14): arch qwen35, 851 tensors, 26.90 B parameters, 2.26 bits per weight, file_type 41, tensor type id 42 on 498 tensors. The card's 1.71 bits per weight is information content; the container stores two bits per weight plus an fp16 scale per 64 weights, which is 2.25 bpw.

How it was served

Seats held: the Hermes aux seat from 2026-09-10 17:01Z. By 2026-09-11 19:45Z a port scan found nothing serving a bonsai; the stop is not on record.

Decisions

• Why downloaded: Alan's question "Just wish more 1.58 bit models would come out" led the assistant to the prism-ml card; it chose this file because it loads on the existing build. (reconstructed) The PQ2_0 build needed a fork, and the night's bench was deliberately single-binary.
• Pre-registered expectation: the script header calls a poor toolcall result "a property of the family" given the Qwen3.6 backbone. The result falsified it: toolcall 60/60 and every arm 12/12.
• Verdict at the time: perfect on both tool suites, worst on the board for worldview (42.5) and nullschema (27.8), with 12.5% on both lure types. Alan, on the speed: "so bonsai slow but it fits being the main selling point". He declined to cut the bench short: "Nah let it run, it’s what the benches are for".
• Hermes seat (2026-09-10). Alan asked "ok make bonsai primary, do the aux models need additional souls or tweaks?". The assistant argued against primary on the 12.5% lure resistance and offered tool-routing instead; Alan: "yeah let's try it, I’ll do a normal chat same as before and then try doing kanban". What was wired: Bonsai as the model for mcp and skills_hub; the primary stayed K2-36B. (reconstructed) Alan's reply most plausibly accepted the tool-routing reading, since the assistant executed that and he did not object.
• Retired as a benchmark subject, 2026-09-14. Alan: "just run them again properly using bonsai and retire the others.". The five Q2_g64 result files were moved (not deleted) to results/_retired. The PQ2_0 build on the prism fork then replaced this file as the board's ternary 27B (Ternary-Bonsai-27B PQ2_0 (prism-ml, prism fork)).
• Deleted 2026-10-11 in the second sweep (below).

What went wrong

• Name inversion, two half-pages. The site registry id was ternary-bonsai-27b; the results were filed under bonsai-27b-ternary, so /model/bonsai-27b-ternary/ showed five scores and "no written entry yet" and /model/ternary-bonsai-27b/ showed the card with different scores. Cost: a re-run under the registry label (the two abandoned attempts above).
• Which file is "the" ternary 27B. Alan, seeing 7.59 GB: "the ternary model is supposed to be 5.9gb I think", then "nah find the right model please". The assistant stopped the run, read the HF repo, concluded the 5.9 GB figure was a card error (the container stores 2.25 bpw; 1.71 is information content) and that this Q2_g64 file was the right one for upstream llama.cpp, and relaunched on it at 16:08Z. Alan then said "do the fork to" and "do it", and the PQ2_0 build replaced it at 16:23Z. Net effect: the board has two ternary 27B builds scored on two runtimes (this file under bonsai-27b-ternary, PQ2_0 under ternary-bonsai-27b); treat them as two measurements.
• Stale build stamp (standing check). Run-log llama_build for these five rows is 0.4.0-dev (build 10893, commit c32d1dabe). The runs were on b10618 (eb25b7263); the upgrade to c32d1dabe started at 12:17Z, four hours later. runtime_version (b10618) is right.
• Partial runs (standing check): the result files are not in the live results directory; the run-log rows show full coverage (measured = attempted for all five). Row counts of the retired files were not recounted here.
• Missing flags: none: --jinja and --reasoning-format deepseek were on the line.
• Thinking starved the speed probe: all three 200-token probes returned the empty-string hash because the model thought through the budget.

What happened to it

Downloaded 2026-09-10 → benched 2026-09-10 → Hermes aux seat 2026-09-10 → results retired 2026-09-14 → stayed on disk, unused → deleted 2026-10-11 (Alan, "nuke tiers a & b"; a lab note; RESTORE-deleted-20261011-tiersAB.sh lists the directory under "ternary-bonsai family — all superseded by bonsai2-27b"). No per-file hf download line exists in that script, only the pointer "Re-download: PrismML/bonsai2 repos". Re-downloadable from prism-ml/Ternary-Bonsai-27B-gguf. The run-log rows survive.