The interesting line in Vicki Boykis’s post on local models isn’t that a 26B model on a 2022 M2 writes decent Python. It’s the metric she uses to decide a model is good enough: “do I have to double-check it against an API model.” For most of the last two years the answer was always yes. Now, with GPT-OSS and the Gemma 4 family, it’s sometimes no — and that’s the threshold that actually matters for anyone running an eval harness in production.

Raw single-shot quality was never the blocker for local inference. The blocker was the agentic loop: tool calls, retries, multi-step refactors where one small error compounds across turns. Getting local loops to roughly 75% of frontier accuracy and speed is the real unlock, because it moves local models from “fast personalized Google” to something that can actually close a task. Once the loop closes, the calculus for a lot of internal, non-recency workloads changes — you stop paying per-token for work that never needed frontier reasoning.

What I’d watch from the LLM-ops side is buried in a parenthetical: she runs every agentic workflow in a Docker container with restricted execution. That’s the part teams skip when they get excited about going local. A model that’s 75% as good but runs unsandboxed against your filesystem is a worse deal, not a better one. The HN thread has the usual llama.cpp-vs-Ollama-vs-LM-Studio tooling debate, but the operational question underneath it is provisioning and isolation, not which loader is fastest.

If a 26B local model closes 75% of your agentic tasks, which 25% are you still paying a frontier API for — and is that split worth measuring per-workflow instead of defaulting everything to the biggest model?