ZDNET's latest experiment with free, locally run AI coding offers a candid look at how far open tooling has come and where it still falls short. The author, an experienced developer who has spent more than a year on agentic coding, revisited the topic after a failed attempt in February 2026 with a different free tool. This time the stack ran entirely on an M4 Max Mac Studio with 128GB of RAM, using Ollama to serve models, OpenCode (version 2.2.5) as the agentic coding harness, and a 64,000-token context window.

The setup

The primary model was qwen3-coder-next in a q4_K_M quantization, an 80-billion-parameter mixture-of-experts model that activates only about 3 billion parameters at a time, which keeps it fast. It is designed for coding agents and shows its reasoning as it works, though it occasionally slipped Chinese characters into its responses. For tasks that required interpreting screenshots, the author switched to Gemma4:26b, a multimodal model. Gemma was judged much weaker at coding, prone to runaway behavior, and less communicative while working, so it was used only sparingly. The workflow mirrored the author's Claude Code habits: create a project folder, launch the harness from Terminal, and start with a simple Hello World app to confirm everything worked.

The author notes that RAM is a decisive factor for local coding because it determines how much usable context the model can hold. An earlier test on a 64GB RTX Spark machine, using llama.cpp, OpenCode and a Qwen coder model, managed a rudimentary Windows port of a Mac app, but the author described that as largely a stunt.

Where it failed: the PDF organizer

The first real project was a Mac app to rename and sort PDFs by topic using the new on-device document-understanding foundation model in macOS 27. The choice proved a mistake. The API is brand new, poorly documented and absent from the coding model's training knowledge. After five days of trying to get OpenCode to find documentation and build the app, the author reached a partial result: the app could analyze a single PDF and report its subject, but not reliably repeat the task. Scaling from one document to hundreds or thousands introduced memory and session-management problems that demanded the sort of iterative diagnosis the local stack could not sustain.

Where it worked: the screenshot renamer

The second project used long-established macOS interface components: file lists, directory pickers, image display and text entry. The goal was a tool for working through a folder of more than 7,000 CleanShot X screenshots with unhelpful default names, showing one image at a time and saving a new name when Return is pressed. The app was completed in nearly six days, largely because four of those days went to coaxing the AI into rendering a file list in the left pane. The breakthrough came only after the author deleted the file-display code, started a fresh OpenCode session with no history, and asked for the list from scratch, avoiding any debugging baggage.

The resulting app works but is feature-light: no resizable panes, no naming templates, no zoom, and no arrow-key navigation. Each of those would have required additional building and debugging that the author chose not to attempt.

Context is the core limitation

The central finding is that debugging consumes context. Diagnosing a bug involves accumulating clues, running tests and forming hypotheses, and a 64,000-token window fills up and resets too quickly for that loop. By comparison, the author says Claude Code, with a context window of up to a million tokens, handles this kind of iterative work very well. The author could have hand-written the file list in an hour or two, underscoring how inefficient the local approach was for anything beyond clean, well-trodden tasks.

Analysis and implications

The piece reinforces a pattern visible across the AI coding market: open-weight models running locally are increasingly capable of generating straightforward code at zero marginal cost and with full privacy, but frontier hosted agents still hold a decisive advantage in long-horizon reasoning, large context and debugging. Hardware constraints, particularly memory, effectively cap local usefulness. For developers, the practical takeaway is a hybrid strategy: use local stacks such as Ollama with OpenCode for small, well-documented utilities and fresh-start generation, and reserve paid agents like Claude Code for complex projects or unfamiliar APIs. The author also references a recent survey in which most developers preferred Claude Code, and notes that the choice between Claude Code and Codex remains a matter of use case. Overall, local coding showed intriguing progress since February but is not yet a replacement for premium tools.