Over the last weeks I ran an experiment with a simple question behind it: if I take one consumer laptop and open weight models, how close can I get to something like Claude Code running fully on my own machine? No API, no cloud, nothing leaving the laptop.
The research was supported by 4D Consulting Kft. and the project is now open source. The short answer: closer than I expected on small tasks, much further than I hoped on real work. Here is the honest version.
The setup#
Everything ran on one machine:
- Intel Core i7-14650HX, 24 logical cores
- 64 GB RAM
- NVIDIA RTX 4060 Laptop GPU with 8 GB VRAM
- Windows 11 Pro, LM Studio serving OpenAI compatible endpoints
Models tested: Qwen2.5-Coder-7B, Qwen3.5-9B as the daily driver, Qwen3-Coder-30B-A3B, Qwen3.6-35B-A3B, and an 80B MoE running mostly from system RAM. On this hardware the practical context window was 8k tokens and healthy decode speed was 10 to 14 tokens per second. When another app stole VRAM, it dropped to 0.6 tokens per second and everything fell apart.
What we built#
What came out of it is BuilderGraph, a local coding agent with 26 tools, built in the Claude Code mold, and it is open source. The core lesson of the whole project lives in this codebase: a small model's weaknesses can be partly repaid by a harness that never lies to it and never wastes its tokens. Every hard feature came from a real failure transcript. A complete chess game was once lost because the model forgot a single closing brace, so the parser now salvages and repairs broken tool calls. A failing test suite once read as passing because output compression dropped the exit code line, so failure is now judged on raw output. The agent once claimed a game "runs correctly" when the window closed instantly, so process spawning now probes and reports whether something actually stayed on screen.
What I found#
For single file tasks in a clean workspace, the local agent genuinely works. It passed the benchmark tasks first try, built playable games, fixed bugs across multiple turns. Think of it as Claude Code, 2 to 10 times slower, with training wheels.
For anything bigger the gap is structural, and it is not about tools:
- Context is the wall. At 8k tokens, the system prompt plus one verbose test run already fills the window. Near 90 percent usage the model starts producing malformed tool calls, and no amount of engineering fully compensates.
- Throughput variance hurts more than throughput. Slow is workable. Unpredictable is not. A browser eating VRAM silently turns a usable agent into a broken one.
- Format discipline degrades under pressure. A 9B model near a full context window loses the ability to close its own braces. The harness recovers a lot, but every recovery costs a round trip a frontier model never spends.
The economics#
Local marginal cost is basically zero: cents of electricity per hour on a laptop you already own. But the wall clock is 2 to 50 times worse and a human has to stay in the loop, so the real cost of a locally completed feature is human attention, not compute. A frontier API agent finishes a small feature for a few euros in minutes, mostly unattended. For anyone whose time is worth more than about 10 euros an hour, the cloud agent wins on unit economics today, except when data cannot leave the machine, when you have huge volumes of simple transformations, or when you are offline.
Which leads to the conclusion I care most about: nobody should want to be a model provider. That is a capital game. The durable positions for a small firm are the harness layer and the data locality layer. Rent frontier intelligence when speed matters, run local when privacy or volume matters, and own the tooling that makes the two interchangeable. BuilderGraph talks to any OpenAI compatible endpoint, local or remote, for exactly this reason.
How far, really?#
My estimate after living with this daily: routine single file coding on a local machine, matching cloud agents in outcome if not in speed, is one or two small model generations away on today's 8 GB hardware. Multi file project work at cloud quality needs roughly ten times today's local context and throughput budget, which points at tomorrow's 24 GB consumer GPUs rather than today's laptops.
The code and the full report:
- BuilderGraph (open source): https://github.com/IdrissaMaiga/BuilderGraph
- Full research report: https://github.com/IdrissaMaiga/BuilderGraph/blob/main/docs/RESEARCH.md
Built in pair programming sessions with Anthropic's Claude, which was also the reference point the whole experiment measured against. Every failure analyzed in the report is a real transcript from this laptop.
Comments (0)
Sign in to join the conversation