Can a Mac Run a Useful Local Coding Model?
I now understand the basic pieces behind the local agentic coding environment I want to build. The next step is more practical:
Can my Mac actually run it?
Running a local model doesn't mean giving it the entire computer. I still need IntelliJ or VS Code open. My Spring Boot or Next.js project needs to run. I normally have a browser open, probably a database, and everything else I use during development.
So the real question isn't whether I can somehow make a model load.
It's whether I can run a useful coding model alongside a normal development environment without making the computer unusable.
Time to find out.
First, establish the baseline
Before installing anything, I wanted a snapshot of my current environment.
This serves two purposes. First, I need to know what hardware I'm working with before choosing a model. Second, if I change something later, I have a baseline to compare against.
On macOS, I used the following commands:
echo "===== SYSTEM ====="
sw_vers
echo "Architecture:"
uname -m
echo "CPU:"
sysctl -n machdep.cpu.brand_string
echo "Physical memory:"
sysctl -n hw.memsize | awk '{printf "%.1f GB\n", $1/1024/1024/1024}'
echo "Disk:"
df -h /
echo "Java:"
java -version 2>&1
echo "Node:"
node --version
echo "pnpm:"
pnpm --version
echo "Git:"
git --version
I also checked my IntelliJ and VS Code installations separately.
My starting point was:
| Item | My environment |
|---|---|
| CPU | Apple M2 |
| Architecture | ARM64 / Apple Silicon |
| Unified memory | 16 GB |
| Available disk | 192 GiB |
| Java | OpenJDK 26.0.1 |
| Node.js | 22.14.0 |
| pnpm | 10.4.0 |
| Git | 2.40.0 |
| IntelliJ IDEA | 2023.1.6 |
| VS Code | 1.135.0 |
The machine is certainly capable of experimenting with local AI.
The main constraint is obvious: 16 GB of unified memory.
Disk space determines how many models I can store. Memory has a much larger influence on which models I can comfortably run.
And I don't have 16 GB available exclusively for AI.
16 GB unified memory
│
├── macOS
├── IDE
├── Browser
├── Project
├── Database / services
└── Local model
So my objective isn't to find the largest model I can force into memory.
I want the best model I can run while still using my Mac as a development machine.
Install the local runtime
In the previous post, I chose Ollama as the runtime and model-management layer for the experiment.
I already use Homebrew to manage development software, so installation was simple:
brew --version
brew install --cask ollama
Then I verified the installation:
ollama --version
which ollama
Ollama runs a local service on macOS. After launching it:
open -a Ollama
I could check its local API:
curl http://localhost:11434/api/tags
At this point I hadn't installed any models, so an empty list was exactly what I wanted:
{ "models": [] }
This small test proves an important part of the architecture:
Application
↓
localhost:11434
↓
Ollama
No model yet. No agent. No IDE integration.
Just the runtime.
Verify each layer before adding another one
I deliberately didn't download a model immediately.
I want to introduce one piece at a time. Otherwise, if something doesn't work later, I won't know whether the problem is Ollama, the model, the agent, or the integration between them.
A few commands are enough to verify Ollama independently:
ollama --version
ollama list
curl http://localhost:11434/api/tags
ps aux | grep -i '[o]llama'
lsof -nP -iTCP:11434 -sTCP:LISTEN
At this stage I confirmed:
- the Ollama CLI was installed;
- the Ollama service was running;
- the local API responded;
- port
11434was listening; - the model list was empty.
My environment now had a working local runtime.
I can now move to the model.
Don't start with the largest model
Model selection becomes more interesting with only 16 GB of memory.
There are plenty of coding models available, including some very capable ones. The problem is fitting the model alongside everything else I need.
I shortlisted four candidates:
| Model | Approx. model size | Role in the experiment |
|---|---|---|
| Qwen2.5-Coder 7B | ~4.7–6 GB | Safe baseline |
| Ministral 3 8B | ~6 GB | Alternative smaller model |
| Qwen2.5-Coder 14B | ~9 GB | Larger coding candidate |
| gpt-oss:20b | ~14 GB | Memory stress test |
The progression is intentional:
7–8B
↓
14B
↓
~20B
Starting small gives me a reference point. If a 7B model performs reasonably well and keeps the machine responsive, I have something useful to compare against when increasing model size.
Starting with the largest possible model would tell me much less. If everything becomes painfully slow, I already know the model is too heavy, but I don't know how much capability I could have kept with a smaller one.
Developer experiments on more powerful Macs show the same practical constraint at a different scale: models can technically fit while leaving too little memory for the applications around them.
For my 16 GB M2, I decided to start conservatively.
My first model: Qwen2.5-Coder 7B
I selected Qwen2.5-Coder 7B as the baseline.
It's specifically focused on coding, small enough to leave meaningful memory for the rest of the system, and large enough to make the experiment interesting.
Downloading it through Ollama takes one command:
ollama pull qwen2.5-coder:7b
Then:
ollama list
confirmed the model was installed.
I also inspected exactly what Ollama downloaded:
ollama show qwen2.5-coder:7b
My model reported:
| Property | Result |
|---|---|
| Architecture | qwen2 |
| Parameters | 7.6B |
| Quantization | Q4_K_M |
| Context length | 32,768 tokens |
| Embedding length | 3,584 |
| Capabilities | Completion, tools, insert |
| License | Apache License 2.0 |
The quantization is particularly relevant to my hardware. As discussed earlier, Q4 reduces the memory required to represent the model, making a model of this size much more practical on a 16 GB machine.
Now I finally had all the pieces required for the simplest possible local test:
Mac
↓
Ollama
↓
Qwen2.5-Coder 7B
Run the first local prompt
Time for the complicated test:
ollama run qwen2.5-coder:7b
Then:
What is 2 + 2?
Not exactly software architecture.
But quality isn't what I'm measuring yet. I only want to know whether the complete local inference path works.
I also tried a basic Java question and confirmed the model generated a response.
While it was running, another useful command was:
ollama ps
This shows the model currently loaded by Ollama.
There's an important difference between:
ollama list
and:
ollama ps
The first shows models installed on disk. The second shows models currently loaded/running.
When finished, I could unload it with:
ollama stop qwen2.5-coder:7b
The first local model was officially alive.
Storage was easy. Memory is still the question.
The experiment still needs to answer questions such as:
- How fast does the model respond?
- How much memory does it consume while running?
- What happens when IntelliJ is open?
- Does macOS start swapping memory to disk?
- Is the computer still comfortable to use?
- More importantly, is the model actually good at coding?
A model being able to load is only the first requirement.
Don't optimize anything yet
At this point, Ollama gives me plenty of settings I could start changing: context size, temperature, model configuration, system prompts, and others.
I'm deliberately leaving them alone.
I want a baseline before tuning anything.
The environment at the end of this step is intentionally boring:
macOS
│
M2 / 16 GB
│
Ollama
│
Qwen2.5-Coder 7B
No IntelliJ integration.
No VS Code integration.
No coding agent.
No cloud model.
And no custom model configuration.
The model downloaded successfully, loaded successfully, generated responses, appeared as running in Ollama, and could be stopped normally.
So, can my Mac run a local coding model?
Yes.
But that's the easy question.
The useful question is:
Can it run a model that's fast and capable enough to help with real software development while leaving enough resources for me to keep working normally?
I can't answer that from ollama run.
Now I need benchmarks.