Vendors are increasingly claiming that small models, run on a laptop, can now do serious agentic coding work. A Simon Willison post about Meta's Muse Glimmer announcement, for instance, highlights Meta's claims of "strong success rates on full-task benchmarks" and "reliable tool use" across "extended workflows." Claims like that are hard to act on. They don't tell you whether the model will handle your tasks, on your hardware, inside your coding harness.
The most useful evidence available on this question isn't a benchmark table. It's a sustained, hands-on evaluation by Birgitta Böckeler, a Thoughtworks engineer, published as two memos on Martin Fowler's site. Over roughly four weeks she ran small open-weight models (mainly Qwen3.6 35B MoE and Gemma 4, in the 26B–31B range) on two Apple Silicon machines - an M3 Max with 48GB RAM and an M5 Pro with 64GB RAM - through coding harnesses (OpenCode and Pi), on real front-end and scripting tasks. This is one practitioner's evaluation, not a controlled study across hardware or model families, and she says so herself. But it's specific enough to tell you what to check before you spend a weekend on this.
The stages a setup has to clear
Böckeler describes working through what she calls a viability funnel - a sequence of questions, each of which a setup has to clear before the next one matters:
1. Does the model fit in available RAM? 2. Does it respond at a reasonable speed? 3. Can it handle tool calling (the harness reading and writing files)? 4. Does it produce functionally correct code? 5. Can it sustain a longer conversation without the context window becoming a problem? 6. Can it handle a larger or more complex task? 7. Is the resulting code quality acceptable, and what's the trade-off between coding speed and review effort?
This matters because failure can happen at any stage, and the failure mode is different each time. A model that fits in RAM and responds quickly can still fail entirely at tool calling. A model that gets a task functionally right the first time can crash the moment you continue the conversation.
Where it failed, and on what hardware
RAM was the first hard constraint. Böckeler ran models between 8GB and 30GB on the 48GB machine, and found the 15-25GB range more workable in practice - a 30GB model left too little room once the context window was added. On the 64GB machine, a 48GB model ran well initially, then crashed. Loading Qwen3 Coder Next 80B (a mixture-of-experts model) on the 64GB machine produced a correct implementation of a charting task in about 2.5 minutes - but the runtime crashed as soon as she added one more message to the conversation. Her conclusion: "it's capable, but not realistically runnable."
Tool calling was consistently shaky. Models often produced malformed calls - using wrong parameter names, for example - though they could frequently self-correct and recover.
Reasoning didn't reliably help. Smaller models often went in circles inside their own chain-of-thought ("Wait, ...", "Actually, ..."). When Böckeler ran her automated evaluation with reasoning switched off, it was faster, as expected, but performed the same or slightly better - reasoning being switched on was not a guaranteed advantage.
Context length was tight even at the low end. She found 32K tokens sometimes sufficient for small tasks, but often had to raise it to 64K, and the RAM the models already needed left limited room to go much higher, even on the 64GB machine.
One result she couldn't explain: the same model, Qwen3 35B MoE, with identical settings, failed a task 5 out of 7 times on the 48GB machine but failed only once when she reran it on the 64GB machine. The source does not state how many runs were made on the second machine, so the failure rates cannot be compared directly. She nevertheless observed a difference in output quality, not just speed, and flagged it as unresolved. If you're evaluating a setup, don't assume results on one machine will transfer to another with more RAM, even with the same model and settings.
Which tasks worked and which didn't
Task choice mattered more than almost anything else. Two examples from the systematic comparison:
- Sorting and cumulating values in an existing bar chart (a small JavaScript/TypeScript change, 1-2 files, no code search needed beyond finding one named chart): models could handle the sorting easily, but the cumulative-percentage part - x-axis labels reflecting a running total - was where they most often struggled. In manual testing, Gemma 4 26B implemented the full request but degenerated into a "text wall of doom" (unbounded repetitive text) on a follow-up request. In automated testing under stricter one-shot conditions, results reversed: Gemma 4 26B failed all three attempts, Qwen3.6 35B MoE succeeded twice out of two. The labels were the recurring point of failure either way.
- Adding a new chart to a single script from log data (one file only, no code search needed elsewhere): this proved "surprisingly rough." Models produced very long reasoning chains and extremely slow edits; Böckeler recorded giving up after 8, 11 and 12 minutes on separate attempts, despite the task not appearing especially complex. Pasting the full 450-line file into a plain chat window (no agentic harness at all) did produce a working solution, in about 6 minutes - most of that time spent by the model re-outputting the existing code before adding new lines. In her later automated runs, the same task failed 5 of 7 times on the 48GB machine and failed only once when rerun on the 64GB machine - the unexplained anomaly noted above.
In day-to-day use over the following weeks, working mainly with Qwen3.6 35B MoE, the pattern was similar: bash and Python scripts were "often ok"; small, well-defined changes to existing content or codebases were "good" or "often ok"; but building a more substantial project from scratch - even with a stronger model doing the planning and the local model only executing - "started well, but fell apart for more complex logic."
Böckeler's own read on what predicts success: how much code discovery the task requires, how many files it touches, how specific the instructions are, and possibly the tech stack - she reports being more successful with Bash and Python than JavaScript, though she's not certain that isn't confounded by other factors in her small sample.
What this suggests, and what it doesn't
Taken together, the evidence suggests local models can currently be viable for small, well-scoped, well-specified changes - a script, a defined edit to a known file, a task where you can point the agent at exactly what needs to change rather than asking it to find it. It does not currently support relying on them for tasks requiring significant code discovery, longer conversations, or more complex reasoning: those are precisely where the evaluation recorded crashes, stalls and repeated failure.
The evidence itself is limited in ways worth restating rather than glossing over. It covers two specific machines, both Apple Silicon, both with substantial RAM by ordinary laptop standards. It covers a handful of model families (Qwen3, Gemma 4) at a single quantization level (4-bit), tested mostly on JavaScript/TypeScript tasks plus some Python and Bash. Results were sometimes inconsistent between manual and automated runs of the same task, and once inconsistent between two machines running what was meant to be an identical setup, for reasons Böckeler could not identify. She is explicit that she looked at functional correctness, not code quality, in most of this work. None of this generalises cleanly to other hardware, other model sizes, or other languages.
What this evidence does not tell you
If your reason for considering a local model is privacy, cost, or working offline, this evaluation doesn't measure any of those - it's entirely about whether the model can do the coding work at all, on the hardware tested. Whether the privacy or cost trade-off is worth it, for your project, is a separate question this evidence has nothing to say about. It also says nothing about how local models compare with cloud-hosted assistants; that comparison isn't something either source attempted, and nothing here should be read as one.
What to check before trying it
Based on what actually held setups back in this evaluation, worth checking before committing time to a local model:
- RAM headroom, not just model size. A model that fits at rest can still crash once the context window fills up mid-conversation. Leave more room than the model's stated file size suggests.
- How much the task requires the model to find things itself, versus being told exactly which file and what to change. Discovery work consistently strained tool calling and context.
- Whether you expect a single conversation or an extended one. Several failures in this evaluation appeared only after the first exchange, not during it.
- Whether the same setup behaves consistently on your hardware over repeated runs, not just once. The unexplained gap between two "identical" configurations here is a reason to test more than once before trusting a result.
None of this replaces judging the output against agreed behaviour once it's produced, whichever model wrote it - see How to Test Code You Didn't Write for how to do that regardless of where the code came from.