PrismML Put a 27B Model on a Phone. 626 HN Points Later, the Open-Weight Routing Floor Just Collapsed.

PrismML shipped Bonsai 27B this morning — the first 27B-class model that runs end-to-end on a phone. The HN thread hit #3 on the front page at 626 points and 219 comments in under six hours. (HN thread.)

Two variants. Both Apache 2.0. Both based on Qwen 3.6 27B:

• Ternary Bonsai 27B — 1.71 effective bits/weight, 5.9 GB, runs on any modern laptop with full reasoning, tool-calling, and agentic capability. 95% of full-precision Qwen 3.6 27B quality retained.
• 1-bit Bonsai 27B — 1.125 effective bits/weight, 3.9 GB, fits on an iPhone 17 Pro. 90% of baseline quality retained. First 27B-class model running on-device on a phone.

Both variants ship with multimodal vision at 4-bit, 262K-token context, and speculative decoding support. License is Apache 2.0.

The HN thread's most-upvoted comment is the engineering community articulating what this changes about routing architecture: "Has anybody had success using Claude Code with frontier agents to invoke local LLMs for specific sub-tasks?" and "Mixture of experts is essentially what you're doing." That's the architecture Trimio's LCR engine already executes — except now the "local" target in the routing table isn't a Mac Mini basement deployment. It's a phone. Every laptop. Every engineer.

What exactly shipped this morning — the spec, not the headline

PrismML's announcement is more specific than "small model on device." Two distinct quantization tiers, each with a target deployment surface:

• Ternary Bonsai 27B (laptop): 1.71 effective bits/weight. The choice that retains enough tool-calling fidelity (74.0 on the agentic benchmark vs. 80.0 at full precision) to drive real agentic workloads — the workloads that have historically justified paying $3/M input to Sonnet.
• 1-bit Bonsai 27B (phone): 1.125 effective bits/weight. The choice that makes the architecture interesting: a 27B-class model with full 262K context and multimodal vision running on a device the user already carries. Inference cost: battery + heat. Privacy: zero data leaves the device. Latency: sub-200ms for typical prompt shapes.

Both variants preserve multimodal vision at 4-bit precision on the vision tower. Both preserve 262,144-token context. Both support speculative decoding. The compression is in the language-model weights, not in the capability set.

Why this is structurally different from "Qwen 3.6 27B hit the cost floor"

Trimio's June 30 post on Qwen 3.6 27B (974 HN points, our most-read post of Q3) argued the open-weight cost floor collapsed into $0.26/M input on OpenRouter. Today the same logical model collapses further — to $0.00/M input on a device that an enterprise already owns. Three structural changes:

1. The price floor is now literal zero — not "$0.26 vs. $3" but "free electricity vs. $3." For quality-floor-routed traffic that fits Bonsai 27B's band, the cloud alternative is now a rounding error on top of a zero.
2. The privacy floor is now literal local — for prompts that contain PII / PHI / trade secrets / financial data, the routing rule no longer has to settle for "we trust the provider's data-handling page." The rule can say "this prompt never leaves the device."
3. The latency floor is now lateral — sub-200ms goes from "fine-tuned model on a beefy inference cluster" to "local model on commodity hardware." The 200ms median cloud round trip becomes zero round trip.

These three are not independent. They're the same fact stated three ways: the proxy layer that can route this prompt shape to Bonsai 27B on-device owns the cheapest, most private, and fastest execution path simultaneously. All three buyers — CFO (cost), CISO (privacy), head-of-engineering (latency) — get the same routing decision.

The proxy-layer architecture for cloud-edge-device routing

Today's HN thread makes the architectural question explicit: "frontier orchestrator + local specialist" is the routing pattern the engineering community is articulating as the post-compression reality. Trimio's LCR engine already implements the broader version of this — the current routing table today routes across providers on cost, quality, latency, and policy dimensions. Adding local endpoints means the proxy has to answer a new question the routing config has never had to answer:

Is the prompt shape one we can run locally?

That question resolves into three sub-questions the proxy can score per call:

1. Capability match. Does Bonsai 27B Ternary pass the quality floor on this prompt's task class? (Coding: yes at 86.0/88.7. Multimodal: yes at 65.2/72.6 with the 4-bit vision tower. Long-context retrieval: yes with native 262K support. Authentic frontier reasoning: no — escalate to Sonnet 5 / Opus 4.8.)
2. Device availability. Is a registered local Bonsai endpoint reachable from this client? (Laptop fleet: Mac Mini M4 64GB-class machines registered as a tenant-level endpoint. Phone fleet: iPhone 17 Pro devices on the same tenant with the 1-bit variant sideloaded.)
3. Policy alignment. Is on-device routing allowed for this prompt? (Default: yes for any prompt not flagged for cloud-required routing. Explicit opt-out per tenant for prompts routed to a cloud-only compliance boundary.)

All three scores computed at the proxy layer, per request. The same LCR routing engine that today picks Sonnet over Opus on cost can now pick Bonsai local over Sonnet on cost, privacy, and latency simultaneously. No application-side change — the routing decision is still made at the proxy URL the application already calls.

How this lands in a representative LCR V2 routing config this week

A representative enterprise Trimio LCR V2 config for a mixed workload today (post-quantization-collapse):

• Default L1 (cost-floor, in-band traffic): Bonsai 27B Ternary on registered laptop fleet. $0.00/M input. Quality floor: passes on coding, chat, constrained writing, RAG synthesis within 262K context.
• L2 quality-bump (out-of-band L1 traffic): Sonnet 5 at $2/M intro pricing (effective through Aug 31). Escalation from L1 when the request shape is high-complexity reasoning or full-precision-sensitive.
• L3 frontier (rare, explicit): Opus 4.8 at $5/M input. Routing rule: only when the L2 fallback also fails the quality floor.
• L4 spend-cap (current model rate ceiling): GPT-5.6 Luna at $1/$6 per MTok on OpenRouter. Routing rule: when the tenant's monthly spend reaches the alert threshold.
• Open-weights cloud fallback chain: if Bonsai 27B Ternary is unavailable on every registered local endpoint, route to Qwen 3.6 27B (OpenRouter, $0.26/M input) → GLM-5.2 (Fireworks, $0.17/vulnerability-equivalent) → DeepSeek V4 Pro (cheapest open-weights cloud endpoint that passes floor).

The change from yesterday's config: L1 is no longer a cloud endpoint. L1 is a registered local Bonsai Ternary endpoint that the proxy can reach on the enterprise's own laptop fleet. The cost delta on the L1 tier is between $260K and $260 per billion input tokens, depending on whether the Bonsai endpoint is the new default or stays as fallback.

The Trimio story for the engineering and CFO buyer

Today's story is two stacked together.

Story one: PrismML Bonsai 27B shipped a laptop-runnable Qwen 3.6 27B at 95% quality retention, and a phone-runnable 27B at 90% quality. The HN community voted at 626 points that this is the open-weight moment for on-device deployment.

Story two: Trimio's LCR engine routes to a new endpoint class — local/edge model deployments with zero per-token cost — at the proxy URL the application already calls.

For a Trimio buyer evaluating the routing infrastructure decision this week:

• The Q3 cost-quality conversation has a new bottom rung. The L1 default for in-band enterprise traffic is no longer "$0.26/M input on OpenRouter" — it's "$0.00/M on a laptop already on the balance sheet." Routing configs that captured the Qwen 3.6 27B collapse should be reconsidered — the new floor is below the cloud floor.
• The data-egress conversation also collapses. Prompts that previously justified a "don't send to frontier provider" exemption can now stay on-device by default. CISO review becomes "what fraction of prompts have to leave the device" rather than "who do we trust to receive the prompts."
• The latency conversation moves into a different league. A local Bonsai 27B inference on laptop hardware: sub-200ms median. On a phone: 300–500ms with the 1-bit variant. Both below the cloud round-trip floor. Streaming UX improvements compound.
• The application-side change is none. The Trimio URL the application calls doesn't change. The LCR routing rule adds a new target class. The proxy layer questions capability match, device availability, and policy alignment per request and routes accordingly.

What every Trimio customer should do this week

If your existing quality-budget routing config still treats "local Bonsai endpoint" as an exotic option, Bonsai 27B's 626-point HN consensus is the signal to add it as a standard target. The moves:

1. Register a Bonsai 27B Ternary endpoint for the laptop fleet you want to route to. Trimio's local-endpoint registration is configuration, not deployment — a tenant-level endpoint URL that the proxy can reach.
2. Add Bonsai 27B Ternary as the L1 default in your LCR V2 routing table. Set the quality floor to the 95%-retention band: coding within 4 points of full precision, tool-calling within 6 points, multimodal within 8 points with the 4-bit vision tower.
3. Keep Sonnet 5 (or whatever the L2 escalation tier is for your tenant) above the L1 routing rule, not deleted. Most L1 traffic gets routed there today; you'll thank yourself in two weeks when Bonsai 27B has a momentary supply wobble and your routing still has an open-weights cloud fallback match for the in-band traffic.
4. Run a one-week shadow benchmark on 1,000 representative calls with Bonsai 27B Ternary as a probe target, painted alongside your existing default. Expect ≥95% pass rate on coding and constrained-writing patterns, ≥85% on multimodal, ≥75% on long-context retrieval. Expect <10% pass rate on the prompts that genuinely need frontier reasoning — those escalate to L2/L3 by design.
5. Report the cost delta against the cloud-cost baseline. The 60–80% L1 cost collapse is the headline. The data-egress delta and the latency delta are the second-order stories your CISO and head-of-engineering will each have a slide for.

The Semgrep arc validates the routing thesis in two weeks

Two data points in 16 days. The first: Semgrep proved GLM-5.2 (via Fireworks) beats Claude Opus 4.8 on security tasks at $0.17 per vulnerability — open-weights clearing closed-weights on a production-quality task at a fraction of the cost. The second: Bonsai 27B today, the same Qwen 3.6 27B lineage already in Trimio's routing catalogue, hit 95% quality retention on a laptop at $0.00/M input. The open-weight routing thesis is no longer speculative. It's production-validated on two independent axes in 16 days.

The HN consensus articulates the routing architecture in their own language. The engineering community has stated, in 219 comments on the Bonsai 27B thread, what the routing-layer answer should look like. Trimio's LCR V2 engine is the closest production artifact to the architecture the community is articulating.

The bottom line

Three months ago (April 2026), the routing conversation was: "frontier is expensive but reliable — pay the premium for predictable quality." One month ago (June 14), the conversation was: "Qwen 3.6 27B is the cost-floor model at $0.26/M." Today, after two weeks of Bonsai 27B following the Semgrep precedent, the conversation is: "the cost-floor model is on the laptop already on the balance sheet." Trimio's LCR V2 routes to a registered local Bonsai endpoint at the proxy URL the application already calls. The Quality Budget's bottom rung just moved below zero per-token. The move this week is configuration, not deploy.

Trimio is the LLM API gateway built for quality-aware, multi-provider, multi-tier routing — LCR V2 rules that route every call to the cheapest model that clears your quality floor by default, across cloud providers and on-device endpoints. See how it works.