Mac Mini for AI Agents: How Much Memory You Need, and How to Use What You Have
An agent that calls a hosted model needs little memory: the runtime itself is small, and a 16 GB Mac mini copes if orphaned dev servers and browsers are cleaned up. A local model changes the answer, because weights plus a long-context KV cache must fit alongside everything else. Measure memory pressure before buying more.
Memory goes to four consumers, not one
Buying advice for agent machines usually sizes for the model. On a Mac running agents all day, the model is only one of four things competing for the same unified memory pool.
macOS and your own apps. Browser, editor, chat apps: the baseline before any agent starts.
The agent runtime. The process that holds the loop, the tool registry, schedules, and message channels. It is small. OpenClaw's own hosting FAQ lists an absolute minimum of 1 GB of RAM and recommends 2 GB or more for headroom, and notes that Node tools and browser automation can be resource hungry.
Everything the agent starts. This is the consumer people miss. A coding agent launches dev servers, test runners, language servers, headless browsers, and sometimes a Docker VM. Many of them keep running after the task that needed them has finished. Three agents working in parallel can mean three copies of that stack.
A local model, if there is one. Weights plus the KV cache for the context window. When this exists it is usually the largest single block, and it is the only one that grows with context length.
Measure before you buy
Run your normal agent workload for a day, then look at what the machine actually did.
Memory pressure, not memory used. macOS fills free memory with cache on purpose, so a high used figure means little. Activity Monitor's Memory tab shows a memory pressure graph: green means the system is coping, yellow means it is compressing heavily, red means it is short. The memory_pressure command reports the same thing in a terminal.
Swap. Run sysctl vm.swapusage. A few hundred megabytes is normal. Swap that grows through the day while agents run says the working set does not fit.
Who holds it. Sort Activity Monitor by memory and look for orphans: Node processes from yesterday's dev server, Chromium instances from browser automation, a Docker VM nobody is using.
Disk. Agents write build artifacts, dependency folders, browser profiles, and model files. Ollama stores models under ~/.ollama/models by default, and each model is gigabytes. On a Mac mini with a small internal SSD, disk often runs out before memory does, and a nearly full SSD makes swap slower too.
If pressure stays green after a normal day, you do not need more memory. You may need to clean up.
The unified memory arithmetic
Apple's current Mac mini line, per its spec page, comes in two families. The M6 model starts at 16 GB and configures to 24 GB or 32 GB; Apple lists 153 GB/s memory bandwidth for the 16 GB configuration and 170 GB/s for 24 GB and 32 GB. The M5 Pro model starts at 24 GB and configures to 48 GB or 64 GB, at 307 GB/s.
For a local model, budget it like this:
- Subtract the baseline. macOS, your apps, the agent runtime, and the tools it starts. Measure it with the steps above rather than guessing.
- Respect the GPU limit. macOS does not let the GPU wire all of unified memory by default; a share is held back for the system. Recent macOS exposes the
iogpu.wired_limit_mbsetting to raise it, which trades model room for system stability. - Weights. Parameters times bits per weight, divided by eight. An 8B model at 4-bit is roughly 4 to 5 GB. A 27B model at 4-bit is roughly 14 to 15 GB.
- KV cache. It grows linearly with context length, and agent runtimes want long contexts because system prompts and tool definitions are large before the user types anything.
On 16 GB, that leaves room for a small model with modest context, or for no local model and a lot of agent tooling. 32 GB fits a mid-size quantised model with a working context. Larger dense models and long contexts at once are M5 Pro territory.
How to get more from the machine you have
Most of the gain is behavioural, and it costs nothing.
Decide where the thinking happens
If the agent calls a hosted model, the Mac is a runtime host. It needs memory for the agent and the tools it launches, not for a model, and an existing Mac or a small server does the job. Only a local model changes the sizing question, so make that choice first.
Give every agent a stop condition
Tell agents to shut down the dev servers, browsers, and containers they start when the task ends, and check for orphans at the end of the day. A step limit and a time limit on each run prevent a loop that keeps spawning processes.
Stagger simultaneous work
Parallel agents multiply the tool stack, and with a local model each concurrent request needs its own KV cache. Queue heavy jobs such as full test suites and builds instead of letting three agents run them at once.
Tune the local runtime
With Ollama, keep one model resident (OLLAMA_MAX_LOADED_MODELS=1), unload idle models sooner with OLLAMA_KEEP_ALIVE, and set OLLAMA_NUM_PARALLEL=1 on small machines, since Ollama's documentation notes memory scales with parallel requests times context length. Set context length explicitly rather than accepting the largest the model supports, and consider a quantised KV cache (OLLAMA_KV_CACHE_TYPE=q8_0 with flash attention enabled) to roughly halve cache memory.
Send less context
The KV cache is the part of local model memory you control from the prompt side. An agent that pastes whole files, long histories, and every tool result into each turn pays for it in cache memory and in prompt processing time, which on a Mac mini is the slow part. Retrieval keeps prompts short: index notes, docs, and code once, then give the model only the passages a question needs. RDK does this by indexing local vaults as encrypted private chunks that agents search before calling a model, local or hosted, which also cuts token spend 80 to 90 percent on repeated or reference-heavy work when the call is to a hosted model.
When buying more memory is the right answer
Buy when the measurements say so after cleanup: pressure sits in yellow or red during a normal day, swap keeps growing, and the cause is a local model you actually use rather than processes nobody stopped. Then size for that specific model, its quantisation, and the context length your agent runtime requires, plus the baseline you measured. Memory on a Mac mini is fixed at purchase, so buy one tier above the measured need rather than for the largest model you might try once.
Frequently asked questions
- How much memory does a Mac mini need for AI agents?
- If the agent calls a hosted model, 16 GB is enough for the runtime and the tools it launches, provided orphaned dev servers and browsers are cleaned up. If the model runs on the Mac, memory must hold the weights, a KV cache for the agent's long context, and everything else. In that case 32 GB is the practical floor for mid-size models.
- How do I check whether my Mac is short on memory?
- Open Activity Monitor's Memory tab and watch the memory pressure graph during a normal agent workload. Green is fine, yellow means heavy compression, red means the system is short. Run sysctl vm.swapusage to see swap. Growing swap and sustained yellow or red pressure, after closing orphaned processes, are the signs that the working set does not fit.
- Why do AI agents use so much memory on a Mac?
- Usually not because of the agent itself. Agent runtimes are small, OpenClaw lists 1 GB as its absolute minimum. The memory goes to what agents start: dev servers, headless browsers, test runners, Docker VMs, and local models. Many of those keep running after the task ends, so a day of agent work accumulates processes nobody stopped.
- Can I run several agents on one Mac mini?
- Yes, if the model is hosted, as long as their tool stacks fit together and heavy jobs are staggered. With a local model it is harder, because each concurrent request needs its own KV cache and the model weights are shared by all of them. Queue requests through one model instance rather than letting each agent load its own.