Bonsai 2 Arrived on Ollama Before Anyone Announced It Was Going To

Sometime in the small hours of 17 October 2026, Ollama started serving Bonsai 2 — a nine-tag library entry covering Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B and Bonsai 2 27B, each in two packings plus a default alias. Prism ML has said nothing about it. There is no post on the vendor's news page, no line in the 15 October announcement of the small models — that post names llama.cpp and MLX as the runtimes and a hosted console as the demo, and never mentions Ollama at all. The listing simply exists, with all nine tags stamped the same few hours old, which is what a fresh push looks like and not what a gradual rollout looks like.

So the honest split is this. Knowable right now, from the registry and the files: the tags, their names, their exact byte sizes, their content digests, and — because Ollama ships GGUF — the architecture and metadata strings inside the weights themselves. Not confirmed: who packaged them, why the vendor's announcement omits the platform, whether the ternary kernels are upstream in Ollama's own engine or vendored, and whether any of the vendor's numbers survive the trip. Those are separate questions and this piece keeps them separate.

What is actually on the shelf

Nine tags, four sizes, three packings of the same weights. Ollama's library page lists a default alias per size and a -q2_0 variant per size:

• bonsai-2:latest — 3.2 GB, resolves to the 9B (digest c8b5462f8688)

• bonsai-2:2b and bonsai-2:2b-q2_0 — 911 MB, same digest de2ccb4e7328

• bonsai-2:4b and bonsai-2:4b-q2_0 — 1.6 GB, same digest 93edd652c932

• bonsai-2:9b and bonsai-2:9b-q2_0 — 3.2 GB, same digest c8b5462f8688

• bonsai-2:27b and bonsai-2:27b-q2_0 — 8.3 GB, same digest f3c4f4208659

The naming is doing more work than it looks. Two tags per size sharing a digest is not a duplicate — it is a statement about which packing Ollama picked. Pull the manifest for bonsai-2:9b and the model layer is 2.557 GB. That is Ternary Bonsai 2 9B's Q2_0 file, measured on Hugging Face at 2.557 GB to the byte. The PQ2_0 pack is 2.417 GB and the PTQ1_0 pack — the smallest at 1.997 GB — is not here at all.

That choice has a consequence worth stating plainly, because it is the kind of thing that turns into a support thread. On the vendor's model card, upstream llama.cpp runs exactly one of the three packings: Q2_0, "recent master, which includes the Hadamard activation runtime." It rejects PQ2_0 and PTQ1_0 as unknown types, because those need the Prism ML llama.cpp fork. Ollama serves its own engine. Q2_0 is the pack that a stock GGUF consumer can plausibly load — and Q2_0 is precisely the pack Ollama shipped. Whether Ollama grew ternary kernels of its own or routes to a vendored build is not something the registry tells you. What it does tell you is that they did not ship the file that cannot load.

The GGUF metadata tells you more than the page does

Ollama's page reports four facts per tag: a byte size, a "256K" context badge, an input type of text-plus-image, and a relative timestamp. Everything else is inside the file. Reading the GGUF header of each model layer gives the following, and it is worth reading for a specific reason: it is the only part of this story that is not somebody's marketing claim.

• general.architecture — qwen35 on all four sizes

• general.name — Ternary-Bonsai-2-2B, -4B, -9B on the small three; the 27B layer reports the generic string Hf with general.basename = folded

• general.file_type — 41 on all four, with general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, matching the tag names

• Tensor counts — 320 for the 2B, 426 for the 4B, 427 for the 9B, 851 for the 27B

The architecture string is the interesting one. qwen35 is the Qwen3.5 hybrid-attention backbone, and it confirms from the artefact itself what the model cards say in prose: the small three are Qwen3.5-2B, -4B and -9B with the architecture unchanged, and the weights replaced. It also exposes a naming seam the vendor's own release notes paper over. The 15 October post says the new models are "based on Qwen3.5." The 27B is a different base entirely — Qwen3.8-27B, announced on 17 September. Four sizes, one family name, two base models. Anything you read about "Bonsai 2" behaviour that was measured on the 27B does not automatically transfer down to the 9B, and the GGUF header is where you can see why.

The 27B's metadata is also visibly less tidy than the rest: general.name = Hf, a general.basename = folded, a general.version = v5, and one extra sampling key the small three do not carry. That is what a conversion pipeline's intermediate output looks like when it gets pushed without a final rename pass. It is not a defect — the tensors are the tensors — but it is a fingerprint, and it suggests the 27B tag came through a different path than the small three.

What the Ollama numbers do not mean

Here is where most coverage of a library listing goes wrong, so it is worth slowing down. The byte sizes on Ollama's page are container sizes, and for every size they are larger than the model file inside. The 2B tag reads 911 MB against a 0.547 GB model layer and a 0.365 GB vision projector. The 27B tag reads 8.3 GB against a 7.626 GB model layer and a 0.629 GB projector. Add the license and parameter blobs and the arithmetic closes: Ollama is quoting the whole pulled artefact, vision tower included.

That means the Ollama page's 3.2 GB for the 9B is not comparable to the vendor's "2GB" figure for the same model, and the gap is not a discrepancy to report — it is two different measurements of two different things. Prism ML's 0.43 GB / 0.95 GB / 2 GB are the language models alone. The vision tower is offloaded and loaded only when an image actually arrives, so a text-only deployment never pays for it, but a ollama pull does. If you are sizing a device against the vendor's numbers and then pulling from Ollama, you will be 0.5 to 1 GB over budget before you run anything.

The same caution applies to the "256K" badge. The underlying context is 262,144 tokens, inherited from the Qwen3.5 backbone — 24 linear-attention and 8 full-attention layers on the 9B — and Ollama's badge rounds it down for display. The context is real and it is inherited, not something Ollama added. What is not stated anywhere on the page is how much memory a long context costs, and on a hybrid-attention model with a full-attention cache on a subset of layers that is not a small number. Nothing on the Ollama page tells you whether 262K actually fits wherever you intend to run it.

Who packaged this, and does it matter

Unanswered, and it should be flagged as unanswered rather than guessed. Three possibilities: Prism ML pushed it, Ollama pulled it from the vendor's public GGUF repos as part of their own catalogue work, or a third party did it. The registry cannot tell you which.

What can be checked is provenance of the artefact, and it lines up. Ollama's own model description says "Bonsai 2 from Prism ML is a family of vision models built for ternary weights (−1, 0 or +1): about half the size of standard 4-bit models, at close to full-precision quality" and links the vendor's Hugging Face org, the Bonsai 2 27B whitepaper, and Apache 2.0. The licence blob embedded in every one of the four size manifests is the verbatim Apache 2.0 text. The parameter blob for the 2B, 4B and 9B reads {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — which is the vendor's recommended thinking-mode sampling recipe from the model cards, with min_p omitted exactly as the 27B card says the GGUF files omit it. That is not a guess someone made; that is a conversion that read the card.

Which is reassuring and still tells you nothing about the thing that actually decides your experience: whether the ternary kernels are in the engine you are running. The honest position is that a successful pull proves the file is well-formed GGUF, and nothing more. Verify on your own hardware before you build on it.

The vendor's claims, and what has been checked

Every quality number attached to this family comes from Prism ML, on Prism ML's own harness, and none of it is reproduced independently. That is normal at this age and it should be said out loud rather than implied. The 15 October post reports 19 benchmarks across six skill areas for the small models, with retention against full-precision Qwen3.5 baselines:

• 2B — agentic 95.5%, math 107.8%, instruction following 121.5%, coding 115.0%, knowledge 82.9%, vision 89.0%

• 4B — 90.0% / 99.3% / 106.0% / 100.7% / 90.9% / 91.3%

• 9B — 92.4% / 98.2% / 100.0% / 100.1% / 93.0% / 92.5%

Several of those exceed 100%, which is not a typo and not a rounding artefact — it means the ternary model scored higher than the full-precision model it was derived from on that category. Instruction following at 121.5% for the 2B is the loudest example. Treat that with the suspicion it deserves: a compressed model beating its own baseline on a benchmark the vendor selected is a statement about the training and the harness at least as much as about the representation, and the small-model category scores are a great deal noisier than the 27B's. The 27B's numbers are more conservative and more credible in shape — 84.78 against 86.32 for FP16, a 98.2% retention across 14 thinking-mode benchmarks, with math at 96.57 versus 97.06 and coding level at 89.42 versus 89.07, and the loss concentrated in knowledge/reasoning and vision. Where a family gives up capability under a 1.7-bit representation, that is the profile you would predict.

The one claim in the small-model post that is not a benchmark is the one worth taking most seriously: the 9B "uses roughly 40% fewer tokens on standard instruction-following and everyday math tasks." That is a claim about verbosity, not ability, and it is the kind of thing you can check in an afternoon on your own prompts. It also interacts with a warning on the vendor's own model cards — thinking mode can burn 3,000-plus tokens on a trivial question, so set at least 8,192 output tokens, and do not run greedy decoding with thinking on because it can get stuck reasoning. A model that is 40% less verbose and still needs an 8,192-token budget is telling you it is verbose in a specific place.

Where this leaves you

If you already run Ollama and you wanted to try a 27B-class model on a laptop without a datacenter GPU, the four tags are the shortest path that exists right now: one pull, no fork, no kernel build. If you need the packing that is actually smallest, or the speculative-decoding drafters the vendor ships for the 4B and 9B, the Ollama listing does not have them — that is a Hugging Face download and the Prism ML llama.cpp build, and it has been since 15 October.

The other thing worth knowing is that local is not the only way to consume a low-bit model, and it is not always the right one. OrcaRouter puts one API in front of 200-plus hosted models with 0% markup — provider list price passed through — plus automatic failover between providers, so you can evaluate a model on a real workload before deciding whether it earns a place on your laptop. None of the Bonsai 2 sizes are served through OrcaRouter today, and this piece is not claiming otherwise: the family is a download you run yourself, and it stays that way until the vendor publishes an endpoint. What the routing layer buys you is the other half of the decision — the hosted models you will compare it against, behind one key, with the model fusion and routing DSL available when a single model is not enough.

What to watch, in order of how much it would change the picture: an Ollama tag gaining a ptq1_0 sibling, which would mean the dense-trit kernels made it upstream; a vendor post acknowledging the platform, which would answer the provenance question; and any independent benchmark of the 9B or the 27B, which is the only thing that would move the retention figures out of the vendor-reported column. Until one of those lands, the listing is a delivery mechanism, not a new model — and the model it delivers has been public since 15 October.

None of that is hypothetical: the documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.