I turned my gaming PC into a private AI coding server, and it actually works
Most developers hear “run your own LLM locally” and picture a research lab, a rack of A100s, and a cooling bill that needs its own line…
I turned my gaming PC into a private AI coding server, and it actually works
Most developers hear “run your own LLM locally” and picture a research lab, a rack of A100s, and a cooling bill that needs its own line item. My setup is a Ryzen 5 5600, 16 GB of RAM, and an RTX 3060 12 GB sitting on a desk in my room. It powers agentic coding sessions on my MacBook across the local network, and it generated a complete, structured Node.js backend without me writing a single line.
Here is how I built it, what broke along the way, and what I genuinely did not expect.
The idea: a free inference server sitting idle on my desk
My primary tool for AI-assisted coding is Claude Code. But I have a gaming PC that sits mostly idle, and I kept thinking about whether it could pull its weight as a local inference server — something I could point an agentic coding tool at without touching an external API or racking up token costs for every experiment.
The question was whether the hardware was good enough. Turns out, yes — with some configuration work that nobody fully documents in one place.
The hardware stack

The 12 GB of VRAM is the real protagonist here. Most consumer GPUs tap out at 8 GB, which limits you to smaller quantised models. The RTX 3060’s full 12 GB lets you run a 26-billion parameter model with enough room to actually think.
Choosing the model: gemma4 26b on Ollama
Ollama is the easiest way to run open-source models locally. One command pulls and serves the model:
ollama pull gemma4:26b
ollama serve
By default, Ollama binds to localhost. That is fine for local use, but since I wanted my MacBook to talk to this machine across the network, I needed it to listen on all interfaces. Most guides tell you to set an environment variable for this — but the easier way is to just toggle the setting inside Ollama itself.
Open Ollama on Windows → Settings → and enable “Expose Ollama to the network”. That is it. No environment variables, no config files. Ollama handles the binding for you.
This is the step most guides over-complicate. The toggle has been sitting there the whole time.
The firewall problem: Windows Defender and inbound rules
Here is where things got interesting. Even after binding Ollama to 0.0.0.0, my MacBook still could not reach it. Windows Defender Firewall was silently dropping the inbound traffic on port 11434.
The fix is to create an inbound rule manually:
- Open Windows Defender Firewall with Advanced Security
- Click Inbound Rules → New Rule
- Choose Port, then TCP, and enter
11434 - Allow the connection
- Apply to Private networks (do not open this to Public unless you know what you are doing)
Once that rule was in place, my MacBook could reach the Ollama server at http://192.168.x.x:11434. No VPN, no tunnelling — just the local network.
Verify before you configure anything
Before touching Cline, take two minutes to confirm the connection is actually working. Debugging a Cline configuration when the real issue is a firewall rule is a frustrating way to spend an afternoon.
Step 1 — ping the Windows machine from your MacBook:
ping 192.168.x.xxx
If you get responses, the machines are talking on the network. If it times out, sort your local network first — no amount of Ollama configuration will help.
Step 2 — curl the Ollama endpoint directly:
curl http://192.168.x.xxx:11434/api/tags
A healthy Ollama server responds with a JSON list of your installed models:
{
"models": [
{
"name": "gemma4:26b",
"model": "gemma4:26b",
...
}
]
}
If you get a connection refused here, the firewall rule is not in place yet. If you get a response but an empty model list, the model pull did not complete. Both of these are easy to fix — but you want to know about them now, before Cline enters the picture.
Only once both commands succeed should you proceed to Cline.
Wiring up Cline on the MacBook
Cline supports custom OpenAI-compatible API endpoints. Ollama exposes one at /v1, so the configuration in VS Code's Cline settings looks like this:
API Provider: Ollama
Base URL: http://192.168.2.107:11434
Model: gemma4:26b
Context Window: 32768
Request Timeout: 300000ms
The 300-second timeout is important. A 26B model on a mid-range consumer GPU is not fast. Some responses, especially long code generation, take 30–60 seconds. If your timeout is too low, Cline will give up before the model finishes.
I also enabled Use compact prompt, which strips down the system prompt to keep it within the model’s practical context window. Without this, complex agentic tasks started hitting degradation at the edges of the context.
The real test: scaffold a Node.js backend
Once everything was connected, I gave it a proper task: build a TODO application backend in Node.js, structured with controllers, services, models, and routes.
This is not a trivial prompt. A good agentic response means the model needs to plan a folder structure, write multiple files coherently, handle TypeScript types, set up an ORM, and wire everything together without contradicting itself across files.
The result, from a 26B open-weights model running on a gaming PC:
src/
├── app.ts
├── controllers/
│ └── todoController.ts
├── middlewares/
├── models/
│ └── todoModel.ts
├── routes/
│ └── todoRoutes.ts
├── services/
│ └── todoService.ts
└── types/
└── index.ts
Full CRUD — POST /todos, GET /todos, GET /todos/:id, PUT /todos/:id, DELETE /todos/:id — using Express, Sequelize with SQLite, and TypeScript with verbatimModuleSyntax. The app.ts synced the database on startup and handled errors cleanly.
Cline ran through it autonomously. I just watched.
What you should know about the resource usage
Honest answer: it is brutal.
When the model is generating, the GPU hits 100% utilisation and stays there. The RAM — all 16 GB — is essentially fully committed between Windows, Ollama, and the model weights. There is no headroom. If another heavy process starts on the Windows machine, you will see generation stall or slow to a crawl.
This is not a server you can run alongside other workloads. Treat it as a dedicated inference machine when it is in use.
Inference speed sits around 8–12 tokens per second for this setup. Usable for agentic tasks. Not fast enough for real-time chat where you want snappy responses.
What surprised me
I expected the model to struggle with multi-file coherence. It did not. todoController.ts imported from todoService.ts, which used types defined in index.ts — and the imports matched across files without me correcting them.
That kind of cross-file coherence is where smaller models (7B, 13B) typically fall apart. The 26B parameter count seems to be the threshold where the model can hold enough context about the project structure to stay consistent.
Second test: redesigning a real UI with a single prompt
Backend code is one thing. UI transformation is a different class of task — it requires design sense, an understanding of how CSS variables cascade through a codebase, and the ability to touch multiple files (HTML, CSS, JS) in a way that stays visually coherent throughout.
I gave it one prompt: “Give the website a modern retro look.”
No mood board. No colour palette. No detailed specification. Just that.
The model came back with a structured plan before writing a single line. It identified the existing “clean SaaS” aesthetic (white background, Inter font, soft shadows) and proposed a “Neo-brutalist / Retro-tech” direction — then laid out exactly how it would approach each layer:
- Replace the white background with a deep midnight (
#0f172a) and introduce neon green accents (#22c55e) - Swap soft box-shadows for hard, offset black borders to create a physical, pop-art feel
- Redesign the install widget to look like a terminal window with OS toggle tabs
- Update hover transitions from smooth/fluid to snappy and mechanical
Then it executed across all three files. Here is the CSS variable overhaul it made to styles.css:
:root {
--bg-color: #0f172a;
--text-color: #f8fafc;
--text-secondary: #94a3b8;
--accent-color: #22c55e;
--accent-bright: #4ade80;
--border-color: #334155;
--border-heavy: #000000;
--code-bg: #000000;
--card-bg: #1e293b;
}
That single variable change rippled through every component on the page. The result was a full dark-mode, neo-brutalist redesign — the install widget now looks like a terminal window, the feature cards have hard black borders and offset shadows, and the whole page feels like it was built in the late 90s by someone who had seen the future.

Before

After
What made this notable was the token efficiency. The task used 64.7% of the context window — 21.2k out of 32.8k tokens — and finished cleanly. Total token count across the session was 279.2k, the vast majority of which were prompt tokens (the model re-reading the codebase between edits). Completion tokens — the actual output generated — were just 6.7k. A lightweight task, handled well.
A note on tooling: Cline, not Claude Code
To be clear about the setup: my primary tool for serious coding work is Claude Code Pro. Claude-class models are in a different league for complex reasoning, debugging, and anything where I need to get it right on the first attempt.
Cline is not something I use day-to-day. For this experiment, it was simply the right interface — it supports any OpenAI-compatible endpoint, which made it easy to wire up to the local Ollama server. Think of it as the bridge between the task and the model, not the primary workflow. If you want to try this yourself, Cline is a good fit for that same reason.
What you need to replicate this
- A GPU with at least 12 GB VRAM (RTX 3060 is the sweet spot for price-to-VRAM)
- Ollama installed on the Windows machine, with
OLLAMA_HOST=0.0.0.0:11434 - An inbound firewall rule on Windows Defender for TCP port
11434, scoped to Private network - Cline in VS Code on the client machine, pointed at the server’s local IP
- Patience — first-time model loading takes a few minutes, and generation is not instant
The whole thing cost nothing beyond existing hardware.
Written after a weekend of firewall debugging, a lot of ollama logs, two successful agentic runs, and one website that now looks like it belongs in a hacker film.
메타데이터
- post_id
- eee85a89ac9f
- slug
- i-turned-my-gaming-pc-into-a-private-ai-coding-server-and-it-actually-works-eee85a89ac9f
- url
- https://medium.com/@tsvillain/i-turned-my-gaming-pc-into-a-private-ai-coding-server-and-it-actually-works-eee85a89ac9f
- canonical_url
- https://medium.com/@tsvillain/i-turned-my-gaming-pc-into-a-private-ai-coding-server-and-it-actually-works-eee85a89ac9f
- author_url
- https://medium.com/@tsvillain
- status
- ok
- fetched_at
- 2026-06-23 03:48:11