I had 18 hours on a train from Delhi to Lucknow and back, and I wanted to use that time productively—writing code.

Not skimming documentation. Not watching tutorials. Actually writing code. But there was a problem: there was no internet connectivity on that fast-moving train. Cloud-based AI tools were out of the question. I needed a setup that worked offline, cost nothing beyond the hardware I already owned, and actually produced code I could review and trust.

That train ride became the seed for everything that followed.

Free Local AI for Coding hero image

The Setup That Started on a Train

I should have bought the 64GB MacBook Pro.

That is a lesson I learned the hard way. My M4 Max with 48GB of RAM runs qwen3.6-35b through LM Studio (or Ollama, if you prefer) just fine. The model works. It produces the code. But the token generation is noticeably slower than it would be with 64GB. There is a difference between a model that works and a model that flies.

But here is the thing I did not expect: the slowness turned out to be the best feature of this entire setup.

The Subscription Trap

Let me set the scene. You are a developer who wants to use AI for coding. The obvious path is to subscribe to the big cloud models. Claude, GPT, whatever is trending this month. You pay $20 to $200 a month depending on your usage. You get incredible speed. You also get something else: bulk code that no human can possibly review in a reasonable timeframe.

I have been there. You ask a model to build a feature. It generates 500 lines of code in 30 seconds. You stare at a wall of code you did not write, trying to figure out what it actually does, whether it matches your patterns, and whether it introduces bugs you will not find until production.

The speed is impressive. The reviewability is not.

The Setup

Here is what I built instead. A setup that costs nothing beyond the one-time hardware investment:

  • LM Studio or Ollama running qwen3.6-35b-a3b locally
  • OpenCode CLI as the orchestration layer
  • OpenAgentsControl for the agent framework with its full workflow: context analysis, planning, information extraction, plan approval, execution, testing, and deployment

The model I am running is qwen3.6-35b-a3b. It is a capable model that runs on my 48GB M4 Max. Yes, it is slower than the cloud models. Yes, I wish I had the 64GB machine. But it works, and it works for free after the hardware cost.

OpenAgentsControl is the piece that makes this setup actually useful. It is not just a raw local model with a chat window. It is a structured agent framework built on OpenCode that provides:

  • Context analysis — The agent reads your codebase and extracts relevant patterns before doing anything
  • Planning — It proposes a plan before writing any code
  • Information extraction — It understands your architecture, conventions, and standards
  • Plan approval — You review and approve before execution happens
  • Execution — Incremental, validated implementation
  • Testing and deployment — Automated validation steps built in

The key insight: OpenAgentsControl does not just generate code. It generates code that matches your project because it loads your patterns first.

The Real Advantage: Slow AI Is a Feature, Not a Bug

This is the part that surprised me the most.

Claude and similar cloud models are fast. Incredibly fast. They produce bulk code at a rate that exceeds human review capacity. You get 500 lines in 30 seconds. You cannot possibly read all of it. You skim. You hope for the best. You merge. You pray.

My local setup does something different. It produces code at a pace that matches human cognitive throughput. Two to three bite-sized features per day. Each one small enough to read, understand, review, test, and commit with confidence.

This is not a limitation. This is alignment with how effective human development actually works.

A skilled developer ships maybe two to three well-understood features in a day. Not because of tooling constraints. Because that is how deep work works. You focus on one thing. You understand it. You ship it. You move to the next.

The cloud models bypass this entirely. They give you more code than you can process. The local setup gives you code at the rate you can actually work with.

How It Works in Practice

The workflow is straightforward because OpenAgentsControl handles the complexity:

  1. You give a prompt — “Add user authentication” or “Build the dashboard layout”
  2. The agent does lean planning — Context analysis, pattern extraction, plan generation. This happens while you are in your daily standup or attending other meetings. By the time you are back, the plan is ready.
  3. You approve the plan — You review what the agent intends to do. Not the code itself yet. The plan. This is the critical gate.
  4. Agent executes seamlessly — It implements the feature using your project patterns, validates each step, and produces clean code.
  5. You review 2-3 bite-sized features — Each feature is small enough to read thoroughly. You test it. You commit it as a PR. No bugs slip through because the volume is human-scale.

The /compact command in OpenCode is essential here. It reduces the token count in your context session at regular intervals, keeping the prompt size small and under control. Smaller context means faster AI decisions. This is not a minor convenience. It is a fundamental requirement for keeping the workflow responsive.

The Architect Workflow

I think of myself as an architect now. I give a prompt. The agent handles the planning and execution. I approve the plan. The agent executes. I review the output.

This is not a metaphor. This is literally what happens. The OpenAgentsControl framework maintains the entire plan-approve-execute-test-deploy cycle automatically. I do not manually track tasks or manage the workflow. The agent does that.

What I do is the high-level work: deciding what to build, approving the approach, and reviewing the output. The mechanical work — file creation, pattern matching, validation, testing — is handled by the agents.

The result is that I ship 2-3 features per day, each one manually reviewed, tested, and committed as a clean PR. No bugs slip into production because of excessive code volume or human error from reviewing code I could not possibly process.

Why This Matters

There are three concrete advantages to this setup:

1. It is practically free.

One-time hardware investment. No monthly subscriptions. No per-token billing. No usage limits. The qwen3.6-35b model runs locally. The OpenCode CLI is open source. The OpenAgentsControl framework is open source. The marginal cost of each coding session is zero.

2. The speed matches human capability.

This is the counterintuitive insight. Faster AI is not always better AI. When AI produces code faster than you can review it, you are not gaining productivity. You are gaining risk. The local setup produces code at a rate you can actually work with. Two to three features per day. Human-scale. Reviewable. Shippable.

3. Clean PRs with zero bugs from code volume.

When you review 500 lines of AI-generated code in one sitting, you miss things. When you review 2-3 small features, each one independently, you catch everything. The volume constraint of the local model is what keeps the quality high.

What Is Real Today vs. What Is Speculation

Let me be clear about what this setup can and cannot do:

What is real today:

  • Local models like qwen3.6-35b can produce production-quality code that matches your project patterns
  • OpenAgentsControl’s context system actually works — it loads your patterns and generates matching code
  • The plan-approve-execute workflow reduces bugs and improves code quality
  • Token-efficient context management (/compact) keeps sessions responsive
  • Claude-like coding quality is achievable locally, just slower

What is speculation:

  • Whether local models will ever match cloud model speed
  • Whether this workflow scales to large teams or complex multi-system projects
  • Whether the “slow AI” advantage holds as cloud models improve their reviewability

I am not claiming this setup replaces cloud models for every use case. I am claiming it is a viable, practical alternative for developers who value code quality and reviewability over raw generation speed.

The Bigger Picture

There is a fundamental tension in AI-assisted development that nobody talks about enough: speed versus reviewability.

Cloud models optimize for speed. They generate code faster than any human can read it. This feels productive in the moment. But it shifts the bottleneck from generation to review. And review is where real engineering happens.

Local models optimize for something different. They generate code at a pace that matches human cognitive throughput. This feels slower. But it keeps the bottleneck where it should be: on the human who understands the system, not on the model that produces text.

I think the future of AI-assisted development is not about faster code generation. It is about better alignment between AI output and human review capacity. The setup I described achieves that alignment. It is free. It works. And it produces code at the rate a human architect can actually work with.

Whether this is the right approach for you depends on what you value more: speed of generation or quality of review. I have found that quality of review matters more than I expected.

What’s Next

I am still refining this setup. The 48GB vs 64GB question still haunts me. But the workflow is solid enough that I no longer feel the need to upgrade. The question is no longer “can I run this model?” but “what should I build next?”

If you are curious about the specific tools, the OpenAgentsControl framework is available at github.com/darrenhinde/OpenAgentsControl. The OpenCode CLI is at opencode.ai. Both are open source. Both free.

The next question I am exploring: can this workflow be extended to write technical documentation with the same quality? I have been experimenting with the OpenAgentsControl technical writer agent for this blog series, and the results are promising. More on that in a future post.

Have thoughts on this setup? Connect with me on LinkedIn or Twitter.