A practical guide for developers, freelancers, and small teams who want local AI coding without the subscription bills, plus a smart way to keep Claude Code for the work that genuinely needs it.
Classic GPU Upgrade on an Old Gaming PC— Generated by Gemini
The Computer Collecting Dust in the Corner
Not long ago I had a spare gaming computer sitting idle. An Intel Core i5–9600, thirty-two gigabytes of RAM, a seven-hundred-and-fifty gigabyte Crucial SATA SSD, and an RTX 2070 graphics card with eight gigabytes of VRAM. By today’s standards, a mid-range machine from two generations ago. A year before I set this up, I would have told you it was not capable of running a serious AI model locally.
I was wrong.
Today, that same machine runs two open-weights AI models continuously. It debugs my code, writes unit tests, navigates my repositories, and executes multi-step agentic tasks — all without sending a single line of my work to an external server. When I hit a problem that genuinely needs frontier-level reasoning, I open Claude Code and use my existing Pro subscription for exactly that task. Then I go back to local.
This article is the guide I wish I had before I started. Whether you are a solo developer, a freelancer protecting client code, a small team trying to reduce overhead, or just someone with a retired gaming rig taking up space, this setup is achievable in a single afternoon.
Why Bother Going Local at All?
Before we get into the how, the why matters. There are three practical reasons to care about running AI models locally for coding work.
The first is privacy. Every time you paste a function into a cloud model, you are sending your code to someone else’s server. For personal projects, that might not matter. For client work, proprietary systems, or anything covered by a nondisclosure agreement, it absolutely does. Running a model on your own machine means your code never leaves your machine. Full stop.
The second is cost. API fees are easy to underestimate. A productive month of agentic coding — where a model is reading files, writing changes, and running in loops across a project — can accumulate charges faster than you expect. Zero dollars a month for the same capability is not a small difference when you are freelancing or running a small operation.
The third is reliability. A local model does not have an outage. It does not throttle you when a product launch drives up demand. It does not have a rate limit that interrupts your flow at an inconvenient moment. When you are deep in a problem, that continuity has real value.
The honest tradeoff is that local models have limits. They handle smaller codebases more reliably than enormous ones, they lack native multimodal input, and they are not quite at the ceiling of what the best frontier cloud models can do. Which is exactly why the hybrid approach makes more sense than going all-in on either side.
The Hardware You Actually Need
Here is the part that surprises most people. You do not need a new machine or a purpose-built server. What you need is enough video memory on your graphics card to hold the model’s active working layers, and enough system RAM to handle the rest.
My RTX 2070 has eight gigabytes of VRAM. That is not a lot by current AI standards. But paired with thirty-two gigabytes of system RAM, it runs both target models at a usable speed, and here is why.
The two models this guide focuses on — Qwen 3.6 at thirty-five billion parameters and Gemma 4 at twenty-six billion parameters — are both built on what is called a Mixture of Experts architecture. The name sounds technical but the practical effect is straightforward. Even though these models have tens of billions of total parameters, they only activate a small fraction of them for any given calculation. Qwen 3.6 activates roughly three billion parameters at a time. Gemma 4 activates roughly four billion.
This means the compute demand on your GPU is far closer to a small three-billion-parameter model than to a thirty-five-billion-parameter one. The catch is that all the parameters still need to live somewhere in memory so the model can access the right experts on demand. That is where your thirty-two gigabytes of system RAM becomes the hero of this setup.
With eight gigabytes of VRAM, the graphics card handles the active layers and does the math. System RAM handles the remaining model weight that does not fit on the GPU. The result is not as fast as running everything on a high-end card, but it is absolutely usable for development work. On this hardware you can expect somewhere between eight and fifteen new words of output per second from the model, which is roughly the pace of a fast reader. You will not be sitting there waiting.
One question that often comes up is whether this kind of workload will wear out an older SATA solid-state drive. The short answer is no. AI model inference is almost entirely a read operation. The model file loads from your drive into memory once when you start it, and then the drive sits essentially idle while you work. Loading a sixteen-gigabyte model file a dozen times a day does not meaningfully add to the write count that determines SSD lifespan. Your hardware is safe. The only penalty for using a SATA drive instead of a modern NVMe drive is a slower initial model load — around thirty seconds instead of a few seconds. That is a fair trade for a setup that costs nothing.
The Two Models and What Each One Does Well
Both models run through a free tool called Ollama, which makes downloading and running local language models about as complicated as installing any other application on your computer. Ollama works on Windows, macOS, and Linux.
Qwen 3.6 at thirty-five billion parameters is the workhorse of this setup. It was specifically trained for multi-step tool use and for navigating real codebases. When you give it access to your file system through an agentic interface, it reads files, plans what needs to change, and executes edits in deliberate sequences. It has a built-in planning mode where it reasons through a problem before it acts, which meaningfully reduces errors when you are asking it to refactor something complex across multiple files.
Gemma 4 at twenty-six billion parameters is the better choice when you want faster responses on more contained tasks. It performs well on isolated functions, generating test cases, writing boilerplate, and explaining unfamiliar code. Its architecture is optimized for efficiency, which means it tends to respond faster on the same hardware.
A practical rule of thumb: reach for Qwen 3.6 when you are working across a whole codebase or running a multi-step task. Reach for Gemma 4 when you want a quick answer, a fast snippet, or a clear explanation.
Setting Up the Stack, Step by Step
Step one: Install Ollama.
Go to ollama.com and download the installer for your operating system. Run it and follow the prompts. When it finishes, Ollama is running as a background service on your machine. You will not need to think about it again.
Step two: Pull the models.
Open a terminal window. On Windows you can search for Command Prompt or PowerShell. On macOS, open the Terminal application. On Linux, you already know where to find it.
Type the following command and press Enter to download Qwen 3.6:
ollama pull qwen3:30b-a3b-q4_K_M
When that finishes, type the following command and press Enter to download Gemma 4:
ollama pull gemma4:27b-it-q4_K_M
The letters at the end of each model name refer to the quantization format, which is a compression method that reduces how much memory the model needs with minimal loss to quality. Each model will be roughly sixteen to twenty gigabytes on disk. The download will take some time depending on your connection speed. This is the longest part of the whole process.
Note: Ollama model tags are occasionally updated. If either of these commands returns an error, visit ollama.com/library, search for the model name, and copy the exact current tag from the listing there.
Step three: Install OpenCode.
OpenCode is a free, terminal-based AI coding agent that connects to Ollama and gives your local models the ability to read files, write edits, run shell commands, and work through multi-step tasks autonomously. It mirrors the agentic workflow of tools like Claude Code but runs entirely against your local models.
To install it, you need Node.js on your machine. If you do not already have it, go to nodejs.org and download the version labeled Long Term Support, then run that installer first. Once Node.js is installed, go back to your terminal and run this command:
npm install -g opencode-ai
Step four: Configure OpenCode.
In your terminal, navigate into any project folder on your computer using the cd command followed by the path to your folder. Then type opencode and press Enter. The first time you run it, it will walk you through a brief setup screen. Select Ollama as your provider. Choose one of the models you downloaded. You can switch between the two models at any time from inside the interface.
Step five: Run your first test.
With OpenCode running inside a project folder, ask it something concrete about your project. Try asking it to describe the structure of the codebase, or ask it to write a unit test for a specific function and name the file. Watch it read your files and produce a response. If it works, your local AI coding stack is live.
Where Claude Code Fits Into This
The local stack handles the day-to-day. Claude Code handles the rest.
The most effective way to use a Claude Pro subscription alongside a local setup is to think in phases. The opening phase of any project — where you are making architectural decisions, scaffolding a new codebase from scratch, or planning out a complex feature — is where frontier-level reasoning pays off most. Claude Code can hold a large codebase in context, reason across the whole system, and help you build something structurally sound before you write a single line of implementation.
Once the foundation exists and you are in the iteration cycle — writing features, debugging, refactoring, and testing — that is where local models take over. The individual tasks are smaller, the privacy concern is higher if you are working with client code, and the cost adds up quickly if you are routing every agentic loop through a paid API.
A workflow that holds up in practice looks like this. Use Claude Code to plan, scaffold, and establish the architecture. Commit that initial structure to version control. Switch to OpenCode with Qwen 3.6 for all implementation work, debugging, and testing. Return to Claude Code when you encounter something genuinely hard — a subtle architectural problem, a concurrency bug you cannot track down, or a task that requires ingesting a very large amount of code all at once.
This is not a compromise. It is a deliberate division of labor that plays to what each tool does best. Claude Code is exceptional at high-level reasoning across large contexts. Local models are free, private, and fast enough for the vast majority of implementation work most developers do every day.
A rough estimate based on real use: somewhere around eighty to eighty-five percent of daily coding tasks are well within the capability of local models at this size. That means a Claude Pro subscription is being used for the fifteen to twenty percent of work where it genuinely makes a meaningful difference, rather than being spent on unit tests and variable renames that a local model handles perfectly well.
A Critical Caveat About Claude Code and Your Subscription
This is the part that trips up almost every developer who tries to set up this workflow, so it is worth spelling out clearly.
Claude Code is Anthropic’s own terminal coding agent — a separate product you install and run directly. When you use it, it draws from the same token budget as your Claude Pro or Max plan. That is the subscription at work, and it is the intended way to access Claude Code. Install it with the command npm install -g @anthropic-ai/claude-code, authenticate it with your Anthropic account, and your subscription covers your usage.
OpenCode is a different, independent tool. It is open source, model-agnostic, and not made by Anthropic. You can configure OpenCode to use any backend you choose, including Anthropic’s models, but doing so requires a separate API key with pay-as-you-go billing — not your Claude Pro subscription. As of April 2026, Anthropic stopped allowing subscription tokens to be used inside third-party tools like OpenCode. If you try to connect OpenCode to a Claude model using your subscription credentials, it will not work the way you expect, and you may find yourself getting billed at standard API rates regardless.
The practical takeaway is this: use Claude Code directly for your Claude work. It is the first-party tool, it is subscription-compatible, and it is designed specifically for agentic coding with Anthropic’s models. Use OpenCode for your local Ollama models, and optionally for third-party cloud APIs like Gemini, which brings us to the next section.
The Middle Tier: Gemini 3.5 Flash Inside OpenCode
If you want the flexibility of a cloud-backed model inside OpenCode without burning through your Claude Pro subscription on every task that exceeds local capacity, Gemini 3.5 Flash is the right tool for that slot.
Google announced Gemini 3.5 Flash in May 2026 as a model built specifically for agentic workflows — the kind of work coding agents actually do, which is reading large codebases, planning multi-step changes, calling tools, editing files, and iterating quickly. It is already available in OpenCode through the Google provider, and you connect it with a standard API key from Google AI Studio. The pricing sits at one dollar and fifty cents per million input tokens and nine dollars per million output tokens, which sounds higher than some alternatives until you work through what a real session actually costs.
A heavy agentic coding session — reading files, planning a refactor, executing edits across a medium-sized codebase — might consume around one hundred thousand tokens of input and twenty thousand tokens of output. At Gemini 3.5 Flash pricing, that session costs roughly thirty-three cents. Even a week of regular middle-tier use across multiple projects lands well under ten dollars. That is a meaningful amount less than routing the same work through the Anthropic API, and it fits comfortably into a pattern where you reserve Claude Code for the genuinely complex fifteen percent.
Why Gemini 3.5 Flash fits this workflow specifically
Three things make it a natural fit for the middle tier in this setup.
The first is speed. Gemini 3.5 Flash generates output roughly four times faster than other frontier models in its class. In an agentic loop — where the model reads a file, decides what to change, writes the change, checks the result, and repeats — that speed difference compounds quickly. Less waiting between steps means a more natural, interactive development pace.
The second is the context window. One million tokens means you can load a very large repository entirely into context and ask the model to reason across all of it in a single session. This is exactly the scenario where local models hit a wall. An RTX GPU with eight or sixteen gigabytes of VRAM can hold meaningful context, but it cannot hold an entire substantial codebase at once. Gemini 3.5 Flash can, and it does not require you to manage chunking or summarization to stay within limits.
The third is multimodal input. Unlike the local models in this guide, Gemini 3.5 Flash can process images, PDFs, diagrams, and screenshots alongside code. If you want to paste a screenshot of an error dialog, a wireframe, or a database schema image and have the model reason about it alongside your code, Gemini handles that natively. Local models in this guide do not.
The free tier option
Before you get to paid API billing, it is worth knowing that Google AI Studio offers a free tier with rate-limited access to Gemini models. For occasional use — a few sessions a week on medium-complexity tasks — the free tier may cover everything you need before you ever reach for a paid API key. If you are just starting out and want to test the middle tier before committing any money, set up a Google AI Studio account, generate an API key, and configure it in OpenCode as the Google provider. You will know quickly whether it fits your workflow.
How the three tiers actually work together
With all of this in place, the full workflow divides cleanly into three zones.
The local zone covers the vast majority of your day — routine coding, debugging, unit tests, refactoring, and anything involving client or proprietary code. OpenCode backed by Qwen 3.6 or Gemma 4 via Ollama handles all of this for free, with zero data leaving your machine.
The middle zone covers tasks that exceed what your local hardware can hold in context — a very large codebase you need to load entirely at once, a long multi-step refactor that would require multiple local sessions, or anything where you want to hand the model an image or diagram alongside your code. OpenCode backed by Gemini 3.5 Flash handles this for cents per session, and the free tier covers lighter use entirely.
The premium zone covers the genuinely hard work — architectural planning, complex system design, problems that require the deepest reasoning available. Claude Code, running directly against your Pro subscription, handles this and earns its cost when you use it for the right fifteen percent of your work.
Common Questions With Honest Answers
Will the local models make mistakes? Yes, sometimes. All AI models make mistakes. The local models in this setup are generally reliable for function-level and file-level work, but they can lose track of complex, multi-file dependencies in very large repositories. This is exactly the scenario where switching to Gemini or Claude Code is the right call.
Can you run both local models at the same time? On thirty-two gigabytes of RAM you can have both available, but running them simultaneously would likely exhaust your memory. Ollama unloads a model from memory after a period of inactivity, so in practice you switch between them simply by calling a different one. Ollama manages the rest automatically.
Do you need an internet connection to use the local models? No. Once the models are downloaded, everything runs completely offline. This is a meaningful feature if you travel frequently, work in a facility with restricted connectivity, or simply do not want any network dependency in your development workflow.
What if your graphics card has less than eight gigabytes of VRAM? The setup still works, but more of the model will spill into system RAM and responses will be slower. You need at least sixteen gigabytes of system RAM as a floor for this to be workable. If you want to upgrade, the next section covers exactly what to buy at each price point.
If You Want to Upgrade: GPU Recommendations at Every Budget
VRAM is the single most impactful hardware variable in this setup. Everything else — your CPU, your system RAM, your storage — matters much less than how many gigabytes your graphics card can hold. More VRAM means more of the model lives on the fast GPU memory and less spills into slower system RAM, which translates directly into faster responses and a smoother agentic workflow.
Here is how to think about GPU upgrades at each price tier, from the budget floor to the point where you genuinely do not need anything more.
The Entry-Level Upgrade: RTX 3060 with 12 GB
The RTX 3060 with twelve gigabytes of VRAM is the most accessible meaningful upgrade for this use case, and you can find one used for roughly two hundred and fifty dollars. Going from eight gigabytes to twelve gigabytes means a four-bit quantized version of Gemma 4 at twenty-six billion parameters fits almost entirely in VRAM, which reduces the system RAM spillover that slows things down on the RTX 2070 setup described in this guide. You will notice a clear improvement in response speed on both models. This card draws around one hundred and seventy watts under load, which means it will work with the power supply already in most gaming machines without any changes.
If your budget is tight and you want the most performance for the least money, this is your card.
The Sweet Spot: RTX 4060 Ti with 16 GB
This is the recommendation worth stretching your budget for, and the reason comes down to a single number: one hundred and sixty-five watts.
The RTX 4060 Ti with sixteen gigabytes of VRAM costs around four hundred and fifty dollars used. At sixteen gigabytes, both Qwen 3.6 and Gemma 4 in four-bit quantized format fit entirely in VRAM with room remaining for a generous context window. That means the model is not reaching into system RAM at all during inference, and response generation is substantially faster than either the eight-gigabyte or twelve-gigabyte configurations.
What makes this card genuinely special for a home lab or repurposed gaming machine is the power draw. At one hundred and sixty-five watts under full load, it runs comfortably off the power supply already in any gaming PC built in the last several years. You do not need to budget for a power supply replacement, you do not need to worry about whether your case has the right cable, and you do not need to open a forum thread to verify compatibility. You buy the card, swap it in, and you are done. That simplicity has real value.
The Ada Lovelace architecture — the underlying chip design of the 4060 Ti — also handles the Mixture of Experts workload more efficiently than older Ampere-based cards. In practice this means faster token generation even when comparing cards with similar raw specifications on paper.
If you can spend between four hundred and fifty to six hundred dollars, this is the card to buy.
The High-End Tier: 24 GB Cards and the Power Supply Question
Once you move past sixteen gigabytes of VRAM, you enter territory where the models in this guide fit completely in GPU memory even at higher bit precision, and where you can begin experimenting with larger models altogether. The RTX 3090 with twenty-four gigabytes is the most common choice in this range, available used for roughly twelve hundred dollars, give or take.
The performance gains are real. A 3090 can push generation speeds well above the 4060 Ti, and the extra VRAM headroom makes it practical to run larger quantization formats that preserve more model quality, or to load significantly larger codebases into context without any slowdown.
The important caveat is power. The RTX 3090 draws around three hundred and fifty watts under sustained AI workloads. If your current power supply is rated below seven hundred and fifty watts, plan to replace it, which adds roughly eighty to one hundred and twenty dollars to the total cost. Make sure your case has adequate airflow as well, because this card generates substantial heat during long inference sessions. Budget the full system cost before comparing it against the 4060 Ti.
Cards above the 3090 — the RTX 4090 and beyond — are genuinely powerful for local AI work but cost upward of fifteen hundred dollars and require eight-hundred-watt power supplies at minimum. At that price point the conversation has shifted from upgrading a development machine to building a dedicated inference workstation, which is a different decision with a different scope.
The One Category to Always Skip
Search for used high-VRAM cards long enough and you will find listings for old NVIDIA Tesla and Quadro data center cards with impressive gigabyte counts at prices that seem too good. They are not good deals for this use case. These cards were built for workloads from a different era, lack the modern processing cores that current AI models depend on, require custom cooling because they were never designed for consumer cases, and often need driver configuration that ranges from finicky to genuinely broken on desktop operating systems. The performance per dollar for running modern open-weights models is poor. Every hour you spend debugging a Tesla P40 is an hour you are not writing code. Stick to consumer RTX cards.
The Short Version
If you are choosing between tiers: the RTX 3060 at twelve gigabytes is the budget floor and a clear improvement over eight gigabytes. The RTX 4060 Ti at sixteen gigabytes is the recommended upgrade — it hits the VRAM threshold where both target models run fully in GPU memory, it drops in without touching your power supply, and the price difference over the 3060 is modest enough that the convenience and performance gap makes it the better value for most people. The twenty-four-gigabyte tier is worth considering only if you need to run larger models, work with very large codebases, or plan to use the machine primarily as a dedicated AI workstation, but start to think about the overall value of the upgrade versus a newer, dedicated machine.
The Bigger Picture
The point of this setup is not to replace cloud AI. It is to stop paying for it when you do not need to, and to stop sending your code to external servers when you have a better option.
A retired gaming PC, a free tool called Ollama, two open-weights models, and a clear line between local work and cloud work is a setup that a beginner developer can have running by tonight. It is also a setup that a senior developer or a small agency can rely on for real professional work.
The hardware requirements are lower than they have ever been. The models are capable enough for the majority of what developers actually do day to day. The hybrid workflow eliminates the friction of choosing between privacy and capability, because you no longer have to choose.
The only thing left is to set it up.
Hardware used in this guide: Intel Core i5–9600, 32 GB DDR4 RAM, NVIDIA RTX 2070 with 8 GB VRAM, 750 GB Crucial SATA SSD. Local models: Qwen 3.6 35B and Gemma 4 27B, both running via Ollama in 4-bit quantized format. Agentic interface: OpenCode. Middle-tier cloud: Gemini 3.5 Flash via Google AI Studio API key, configured as the Google provider in OpenCode. Premium cloud: Claude Code via Anthropic Claude Pro subscription.