PrismML Bonsai 27B is the first 27B-class model that runs entirely on a phone. For mobile automation, AI agents, and orchestration stacks, that is a bigger shift than another benchmark point. When a multimodal reasoning model can live inside the app itself, the boundary between the mobile side and the server-side agent moves — and the orchestration graph has to move with it.
The mid-July 2026 AINews / smol.ai newsletter flagged Bonsai 27B alongside the other agent-orchestration stories of the week: Kimi K3 for long-horizon swarms, Claude Cowork for mobile background agents, and Sol Ultra's planner and verifier. The Bonsai release is the one that changes what "on-device" means for teams building real mobile automation.
The 30-Second Version
What Bonsai 27B Actually Is
Bonsai 27B is not a new base model. It is a heavily quantized build of Qwen3.6 27B released by PrismML under Apache 2.0, tuned so that the same weights can run on a laptop or a modern phone. Two variants shipped at launch.
| Variant | Size | Effective bits per weight | Target device | Retention vs FP16 |
|---|---|---|---|---|
| Ternary Bonsai 27B | 5.9 GB | 1.71 | Laptop-class hardware | 94.6% of the FP16 baseline |
| 1-bit Bonsai 27B | 3.9 GB | 1.125 | Phone-class hardware | 89.5% of the FP16 baseline |
Both variants keep the full 262K-token context window, ship a 4-bit vision tower for on-device screenshot, document, and camera input, and support speculative decoding. Throughput lands around 87 tok/s in 1-bit and 58 tok/s in Ternary on an Apple M5 Max, and up to 163 tok/s in 1-bit on an RTX 5090 for the laptop tier. That is more than fast enough to drive a real UI without spinner theatre.
The important part for orchestration teams is not the size or the throughput on their own — it is the combination. A single on-device model can do multi-step reasoning, structured tool calls, vision, and coherent agentic loops without ever leaving the phone. That is what makes Bonsai 27B a change of shape, not a change of degree.
Why On-Device Reasoning Changes Mobile AI Agents
For most of 2026 the standard mobile agent pattern has been a thin client and a fat server. The phone captures intent, sends it to a hosted planner, waits for tool calls to happen elsewhere, and then reflects the result. That works, but it drags four familiar problems with it: latency, cost per call, privacy of raw inputs, and offline behavior. Bonsai 27B does not remove those problems, but it changes where they live.
- Latency. A local planner responds in tens of milliseconds instead of round-trip seconds. That is the difference between a tap and a wait.
- Cost. Trivial planning steps — is this a valid intent, which tool do I call, is the model already stuck — run for free once the model is on the device.
- Privacy. The raw screenshot, camera frame, or document never has to leave the phone to be classified or summarized. Only the resulting action does.
- Offline behavior. A mobile automation flow can degrade gracefully instead of failing outright when the network is bad.
The interesting question is no longer "can this model plan a workflow". It is "which parts of the workflow should the phone plan by itself, and which parts should be handed to a bigger model in the cloud".
The New Mobile Agent Loop
With Bonsai 27B in the app, the mobile agent loop stops being a passthrough and starts being an active layer. That is the same pattern we described in the Gemini Flash mobile agent guide, but pushed one step further: the reasoning that used to live in a hosted Flash-class model can now live on the phone itself for a class of tasks.
- Capture. The app collects the user goal, the current screen, and any relevant context.
- Plan on-device. Bonsai 27B produces a short structured plan, decides which local or remote tools to call, and flags anything it is not confident about.
- Route. Simple tool calls run locally. Long-horizon or high-stakes calls are escalated to a hosted model with the plan attached.
- Reflect. The on-device model reads the tool result, decides whether the goal is met, and either finishes or loops.
The escalation step is where orchestration teams save the most money. When the on-device model can honestly answer "this is a simple case, I finished it", the hosted planner never sees the call. That is the same lesson we drew from the model routing layer for mobile agents in n8n flows: the routing decision itself is the highest-leverage step in the whole pipeline.
How Bonsai 27B Fits Multi-Model Orchestration
A useful mental model is that Bonsai 27B is the local tier in a three-tier orchestration graph. The graph does not go away — it just gets a new bottom step that is almost free to run.
| Tier | Model class | What it does | Typical cost per call |
|---|---|---|---|
| On-device | Bonsai 27B (1-bit or ternary) | Intent parsing, routing, simple tool calls, screen reading, offline fallback | Effectively zero after install |
| Regional executor | Mid-tier hosted model | Multi-step tool use, browser and terminal control, structured workflows | Cents per call |
| Frontier planner | Sol Ultra, Kimi K3 Swarm Max, Sonnet 5 planner | Long-horizon plans, novel tasks, cross-agent coordination | Higher per call, but rarer |
The design goal is not to run everything on the phone. It is to make the phone honest about what it can finish itself, so the hosted tiers only see the calls that actually need them. That is the same pattern that stabilized in the July 2026 orchestration stories out of Kimi K2.6 Claw Groups and Sol Ultra subagents — a smaller model at the edge, a stronger model when the plan needs it.
Which flows to move to Bonsai 27B first
- Intent classification for the mobile app's main entry point.
- Screen-reading and OCR that today calls a hosted vision endpoint.
- Local tool selection when the tool surface is small and stable.
- Offline fallback so the app keeps working when the network is down.
- Sensitive inputs — anything the team would rather never send to a hosted API.
Which flows to leave in the cloud for now
- Anything that needs the very latest planner behavior or up-to-date web tool use.
- Long-horizon multi-agent runs where a frontier model already earns its cost.
- Flows that depend on tools the phone cannot reach — private VPCs, internal APIs, or shared team state.
- Regulatory workloads where the audit trail has to live on a controlled server, not on the device.
Do Not Rip Out the Server Agent
What This Means for Automation and n8n Flows
An n8n automation layer usually sits behind the mobile app, catching webhooks and driving longer running work. Bonsai 27B does not replace n8n — it changes what the webhooks look like. Instead of the phone sending "here is a raw user message, please figure it out", the phone sends "here is a structured intent, I already validated it, please run the workflow". The n8n side gets cleaner inputs and fewer surprise retries.
That maps directly to the operating pattern we already use on Halmob engagements — the same one we wrote about in our n8n on ECS Fargate load test. When the automation layer receives well-formed structured events, its load profile becomes predictable, and you can size it for the real work instead of for chatty guesswork.
What to Watch Before Shipping Bonsai 27B
On-device inference is not free of trade-offs. Four things are worth checking before Bonsai 27B goes into a production mobile build.
- Battery and thermals. A 3.9 GB model at 87 tok/s uses real energy. Long agentic loops need to be scheduled, not run continuously.
- Storage and cold start. The model file is meaningful next to a normal app bundle. Ship it as a downloadable asset, not as part of the binary, and warm the model once at launch.
- Model updates. A local model is a shipping artifact. Plan how you push updates, roll back a bad build, and A/B test a new quantization.
- Quality regressions. The 1-bit variant retains around 89.5% of the FP16 baseline. That is excellent for on-device work, but not the same as the cloud model. Log escalation rates and watch for the flows where the phone quietly gets things wrong.
Where Bonsai 27B Fits in the Halmob Stack
At Halmob, most engagements combine a mobile app, an n8n automation layer, and an AI agent that keeps the two honest. Bonsai 27B slots into the mobile layer as a local planner and router, without changing the shape of the automation pipeline or the frontier planner behind it. That is the same operating model we described in the executor and advisor pattern and in Hermes mobile agent orchestration.
For teams thinking about long-horizon coordination on top of an on-device planner, our writeups on Kimi K2.6 long-horizon agent swarms and Sakana Fugu multi-model orchestration pair well with this one. The local model earns its place at the bottom of the graph. The frontier model still owns the top.
The Bottom Line
Bonsai 27B is the first release that makes a 27B multimodal reasoning model a realistic component of a shipping mobile app. For teams building mobile automation, AI agents, and orchestration stacks, the leverage is not in running everything locally — it is in giving the phone an honest planner so the hosted tiers only see the work that really needs them. Move the routing decision first, measure escalation rate for a week, and only then widen what the on-device model owns.
For source material, start with the PrismML Bonsai 27B announcement, the Bonsai 27B model docs, and the smol.ai AINews newsletter for the wider July 2026 mobile agent context. To put a local planner inside a real mobile and automation product, Halmob can connect Bonsai 27B to the n8n workflows and hosted agents that make the change safe to ship.