PrismML's pitch is one line: "Large models can't fit on smartphones. Datacenters can't sustain them. PrismML is building ultra dense intelligence to solve both."
What I wanted to know was narrower. Kilo had just published a roundup naming Qwen 3.6 27B the best local coding model of 2026, with a hardware note saying a 27B wants a 32GB Mac [1]. I have 16GB. PrismML had quantized a 27B down to 6.7GB of weights. So the question was whether that compression closes the gap: does ultra-dense make a 27B into something a 16GB laptop can use for real coding work, with tool calling and vision?
The first error is the interesting one
Error: tensor "output.weight" size overflow
I assumed a corrupt download. Wrong, and wrong usefully. The file was fine. PrismML packs ternary weights, each one -1, 0, or 1, in blocks of 128, and ships custom kernels to read them. Ollama bundles its own runtime, which had never heard of the format. It reached the largest tensor, multiplied by the wrong constant, and overflowed.
I like this error because it's honest about something software usually hides. The program didn't say "I don't understand this." It said "the arithmetic came out wrong." It didn't know that it didn't know.
The fix took twenty minutes: PrismML's llama.cpp fork, which has the kernels [2].
Where the memory went
Then I asked for everything, because that's what everyone does. Full 262,144-token context, all layers on GPU, vision projector loaded.
The weights were 6.7GB, which felt like the number that mattered. The KV cache wanted 16GB. I had 16GB total. The vision projector never got a chance to load, because there was nothing left to load it into.
That's the whole finding, really. Compression moved the weights into my machine and the cache stayed exactly where it was. Kilo's 32GB recommendation held anyway, because that recommendation was never about weights alone. Everyone quotes the quantization number because it's the impressive one. Nobody puts the cache in the headline. But once weights are two bits, the cache is the model.
Pushing context to find the ceiling produced hard restarts. Not an OOM message, not a graceful failure. The laptop went down. That happened more than once before I stopped experimenting.
Speed, and one very long hello
At 8K it loaded and ran. A 27B model, offline, wifi off. Thirteen tokens per second. Slower than I read.
I tried the 1-bit build assuming half the weights meant twice the speed. It didn't. The constraint was memory bandwidth, not arithmetic. An M1 Pro moves bytes at a fixed rate regardless of how cleverly you've packed them. I'd optimized the wrong thing, which is what you do when you correctly notice something can be optimized and wrongly assume that's why it's slow.
Then I asked it to say hello. It thought for 1,176 tokens first. The transcript has it drafting "Hello!", worrying that's a fragment, trying something longer, counting the sentences, returning to "Hello!", reconsidering, and finally producing eleven words after ninety seconds. It writes "Final decision" four times.
I laughed, then stopped, because I do this. We've built a machine that reproduces our specific failure mode of mistaking anxiety for rigor, and it turns out that's a flag you can set to zero. I wish mine had one.
The actual test (yes I still carried on)
I wired it into Claude Code through LiteLLM, which translates between the OpenAI dialect llama.cpp speaks and the Anthropic one Claude Code expects [3]. Forty lines of config, worked first try, the most satisfying part of the day.
Then I used it for real work and it was bad. Slow enough that I lost the thread between prompt and response. Shaky at tool calls, which is most of what a coding agent does. I uninstalled it that evening.
So: not ready. Not for daily coding on 16GB, and I have no evidence about phones either way.
But notice which part failed. The compression is astonishing and it works exactly as advertised. What failed was everything downstream: bandwidth, cache, tooling, stability. Those are ordinary engineering problems, and ordinary engineering problems get solved.
Some of them already are. Nemotron Cascade 2 uses full attention in only 6 of its 52 layers, which brings its cache to 1.5GB at 262K context, against 40GB for a fully dense model of similar size [1]. Compress the weights like PrismML, structure the attention like NVIDIA, and the machine I have starts to look sufficient.
That's the direction. It just hasn't arrived on my desk yet.
References
[1] A. Messer, "The Best Local Coding Models for Any Setup," Kilo Blog, 29 July 2026. [Online]. Available: https://blog.kilo.ai/p/the-best-local-coding-models-for
[2] PrismML, "llama.cpp (PrismML fork), release prism-b8846-d104cf1," GitHub, 2026. [Online]. Available: https://github.com/PrismML-Eng/llama.cpp/releases/tag/prism-b8846-d104cf1
[3] BerriAI, "LiteLLM Proxy Server," LiteLLM Documentation, 2026. [Online]. Available: https://docs.litellm.ai/docs/simple_proxy
[4] PrismML, "Bonsai-27B-gguf," Hugging Face, 2026. [Online]. Available: https://huggingface.co/prism-ml/Bonsai-27B-gguf