I kept paying a monthly subscription for a cloud coding assistant while a 16GB M4 Mac mini sat on my desk idling most of the day.
So I ran the obvious experiment: can a 16GB Mac mini run a coding assistant entirely offline — no code leaving the machine, no subscription — and is it actually usable for real work?
Short answer: yes, with one hard constraint (RAM) and one soft one (context length).
This article is the written version of the video above, with every command, config file, and benchmark number so you can reproduce it.
Table of contents Why bother running locally The hardware constraint nobody mentions Step 1: Install Ollama Step 2: Pick a model that fits in 16GB Step 3: Run and verify Step 4: Wire it into VS Code Step 5: Tune Ollama for a 16GB box Benchmarks What it does well, what it doesn't Should you cancel Copilot?
Why bother running locally Three reasons, in the order that actually mattered to me: Privacy.
Client code, internal repos, anything under NDA — none of it leaves the machine.
This is the one thing a hosted assistant cannot offer you at any price tier.
Cost.
A coding assistant subscription is roughly $100–240/yr depending on tier.
The Mac mini was already bought.
Offline.
Flights, bad hotel wifi, coffee shop dead zones.
The assistant just works.
The reason not to: raw capability.
The frontier hosted models are better at large multi-file reasoning, and it isn't close.
More on that below.
The hardware constraint nobody mentions On Apple Silicon, the GPU and CPU share one pool of unified memory.
A model has to fit in that pool alongside macOS, your browser, VS Code, and whatever containers you're running.
On a 16GB machine, macOS + a normal dev environment eats 6–8GB before you've loaded anything.
That leaves you roughly 7–9GB of realistic headroom for the model.
This single number determines everything else, and it's why "just run the 30B model" advice from people on 64GB machines doesn't transfer.
By default macOS allows the GPU to use about 75% of total RAM as VRAM.
You can check what you're actually working with: Step 1: Install Ollama Two options.
Homebrew is easier to script and update: Or download the app directly from ollama.com.
Either way, verify the daemon is up: If that returns JSON, the local API server is live on port .
That endpoint is what VS Code will talk to — it is OpenAI-API-compatible enough for most tooling.
If it isn't running: LM Studio alternative: if you'd rather have a GUI with a model browser and a built-in chat window, LM Studio does the same job and also exposes an OpenAI-compatible server (default port ).
Everything below works with either — swap the port.
Step 2: Pick a model that fits in 16GB This is where most local-LLM writeups go wrong.
Here's the actual size on disk (and roughly in memory) for the Qwen coder family: Model Download size Fits in 16GB?
Use it for 986 MB ✅ Trivially Autocomplete only 1.9 GB ✅ Easily Autocomplete, light chat 4.7 GB ✅ Sweet spot Chat + edit + autocomplete 9.0 GB ⚠️ Tight — close other apps Best quality you can get 20 GB ❌ No — (a3b) 19 GB ❌ No Needs 32GB+ The 16GB recommendation: for chat and edits, for inline autocomplete.
Running a small dedicated autocomplete model alongside the bigger chat model is the trick that makes the whole thing feel responsive — autocomplete needs to answer in milliseconds, and a 7B can't.
Pull them: If you have the RAM headroom and want to try 14B, pull an explicit quantization rather than the default — is the best quality-per-gigabyte tradeoff: Step 3: Run and verify Then, to see actual timings instead of vibes, use verbose mode: prints , , and (tokens/sec) after every response.
That's your benchmark instrument — no extra tooling needed.
While it's generating, watch memory in another terminal: The column in should say .
If it says anything with , the model spilled out of unified memory and your tokens/sec just fell off a cliff — drop to a smaller model or quantization.
Step 4: Wire it into VS Code Install the Cont