Using Local Coding Agents

The Case for Coding Agents That Never Leave Your Machine

For roughly two years, the default answer to "which AI should write code with us" has had a single shape. You picked a subscription. You paid a frontier lab by the month, you sent your source code to their servers, and you accepted a bill that rose with your usage. The models were good enough that the arrangement rarely felt like a decision. It felt like the only serious option.

That assumption is starting to break, and a recent, careful evaluation by Sebastian Raschka is a good place to watch it break. Raschka set up local coding agents that run entirely on his own hardware, with no cloud service in the loop, and put them through a set of real coding tasks. The results are worth the attention of anyone deciding how their team will build software over the next few years.

What He Actually Tested

A local coding agent has two parts. The first is an open-weight model that runs on your own machine. The second is a coding harness, the tool that lets the model read files, make edits, run commands, and check its own work. Raschka paired several open-weight models with several harnesses and measured how they held up.

The models he focused on sit in the 30 to 35 billion parameter range and use a mixture-of-experts design, which keeps them fast because only a fraction of the network activates on any given token. Qwen3.6, Cohere's North Mini Code, and Nvidia's Nemotron all performed well. Running on a Mac Mini, they produced output at 20 to 30 tokens per second, which he notes is roughly the pace of a frontier model in high-reasoning mode. On a small benchmark of five coding tasks, the strongest local combinations scored four or five out of five.

He is careful not to oversell it. These models are not as capable as the current frontier, Opus 4.8 or GPT 5.5, and for the hardest problems that gap still decides the outcome. But the important distinction is between "not as good as the best" and "not good enough." For a large share of everyday engineering work, the local models are simply sufficient, and sufficient is a much lower bar than the subscription framing implies.

Why the Economics Are the Real Story

The capability numbers are encouraging. The cost structure is transformative, and it is where we spend most of our attention with clients.

A subscription is a variable cost. It scales with how much you use it, and it never stops. The more your team leans on AI, the larger the recurring bill, forever. Local hardware inverts that. It is a fixed cost you pay once, after which each additional token of generated code is effectively free aside from electricity. The heavier your usage, the lower your effective cost per unit of work.

For an individual developer, that is a pleasant efficiency. For an organization running coding agents continuously across many engineers and automated workflows, it changes the shape of the budget entirely. Usage stops being something to ration and starts being something to encourage.

What You Gain Beyond Cost

Money is the headline, but it is not the whole case. Running the agent locally buys three things a subscription cannot sell you.

The first is privacy. Your proprietary code, your internal systems, your unreleased work never leave your own network. For teams handling regulated data or sensitive intellectual property, that is not a preference. It is often a requirement, and it removes an entire category of vendor and compliance risk.

The second is control and transparency. Open-weight models run inside open harnesses, which means you can inspect exactly how the agent behaves and modify it when it does not do what you need. Instead of adapting your workflow to a black box, you shape the tool around your process.

The third is stability. No rate limits set by someone else's capacity planning. No model you have come to rely on being deprecated on the vendor's timeline rather than yours. The stack you validate today keeps working tomorrow because you own it.

We Have Seen This Pattern Before

There is a rhythm to how technology matures, and this fits it precisely. A capability arrives expensive, centralized, and available only through the cloud. Over time it becomes cheap, local, and unremarkable. Storage followed that path. Raw compute followed it. Databases followed it. Each began as a service you rented from a handful of providers and ended as something you could simply run yourself when it made sense to.

Coding agents are early on the same curve, and Raschka's results suggest the descent is faster than subscription pricing would lead you to expect. The frontier will keep moving, and there will always be work that genuinely needs the very best model available. But the share of everyday work that a private, local, fixed-cost agent can handle well is growing quickly.

The Question Worth Asking

For most teams the useful question has changed. It is no longer "can open models write our code." The evidence says they can handle a great deal of it. The better question is one of allocation: which of our workloads truly require the frontier, and which of them just need something sufficient, private, and cheap that runs on hardware we already control.

At Skylab we help clients answer exactly that, mapping which parts of their engineering belong on a frontier subscription and which are better served by a local stack they own outright. Increasingly, the answer is a deliberate mix, and the teams that plan for it now will spend far less, and worry far less about where their code is going, than the ones still treating the monthly subscription as the only way to build.