Why Is My Mac Slow? AI Coding Agents May Be Eating Memory
AI coding agents quietly hog Mac memory and storage. Here's how to diagnose the mess with Activity Monitor and clean it up safely.
Why is my Mac running out of memory when I use AI coding agents?
Your Mac is running out of memory because AI coding agents don’t just think in the cloud, they act on your machine. Every agent you run spins up local development servers, browsers, build tools, and file caches, and a lot of that stuff keeps running after the task is “done.” Add a second or third agent or harness and the load compounds. Buying a faster machine doesn’t fix this, because agent workloads grow to fill whatever capacity you give them.
TL;DR
- AI agents leave processes running after a job finishes: dev servers, browser tabs, build tools, and file watchers all keep consuming RAM even once you’ve mentally moved on.
- Memory pressure is diagnosable, not mysterious. macOS Activity Monitor’s Memory tab shows a color-coded pressure graph (green, yellow, red) plus a per-app breakdown of what’s actually using RAM.
- Storage and memory are linked: macOS uses disk space for swap when RAM runs low, and build artifacts, logs, and crash reports from agent tools can quietly consume tens of gigabytes.
- Real-world bug reports back this up: one public Codex user found a crash report folder that grew past 50GB, another found over 100GB of Git objects tied to checkpoints, and a separate report measured roughly 37 terabytes of SSD writes in 21 days from excessive logging (since patched).
- More hardware doesn’t solve the root problem: agents keep getting more capable and will expand to use whatever CPU, RAM, or disk you throw at them unless you actively manage the workload.
- The fix is behavioral, not just technical: audit first, clean up only what you understand, give every agent a clear stopping point, and queue heavy jobs instead of running them all at once.
- Local model tools (Ollama, LM Studio, Docker Desktop) have their own memory knobs, like context size, parallel request limits, and how long a model stays loaded, all of which affect your baseline memory use.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
How do I check what’s actually using my Mac’s memory?
Open Activity Monitor and click the Memory tab. macOS shows a memory pressure graph in real time, color-coded: green means the system is fine, yellow and red mean it’s under strain. If you’re running multiple agents, browsers, and local models at once, don’t be surprised if you’re sitting in yellow or red regularly.
Below the graph, Activity Monitor lists every application and process with its RAM usage. A high number next to one app doesn’t automatically mean you need more memory. It means you need to look closer. Is that Chrome tab still running a dev server from a project you finished yesterday? Is a local model still loaded even though you’re not actively prompting it? That’s the real diagnostic question.
Next, check storage. Go to System Settings, General, Storage. RAM is your working space, storage is where files, software, and swap memory live. When RAM runs low, macOS temporarily writes memory contents to disk, like a credit card hold, so processes don’t collide. But if your storage is already clogged with abandoned build files, dependency caches, and logs, you’ve got less room for that swap buffer, and the whole system gets squeezed from both directions.
What’s actually eating the memory: the agent or the local tools?
It’s rarely the model itself. When you ask Codex or Claude Code to build something, the model’s reasoning happens in a data center. But the resulting work, running a dev server, launching a browser to test the site, executing build tools, compiling dependencies, all of that happens locally. That’s where the pressure comes from.
This matters because it changes where you look for a fix. If you’re getting memory warnings, the local tools tied to your agent’s work are your primary suspect, not the model provider. Labs have made some progress here. OpenAI shipped a Codex update that reduced its memory footprint, and separate fixes addressed excessive SSD logging that one user clocked at roughly 37 terabytes of writes over three weeks. Codex also later added reclamation of unused log database space. These are real improvements, but they’re point fixes. If you’re running multiple harnesses at once (say, Codex plus Claude Code plus a local model like Qwen), no single vendor’s patch covers your whole setup. You have to manage the combination yourself.
How do you clean up AI agent files without breaking something?
The safe approach is audit first, then clean. Don’t delete things based on folder size alone. A large folder isn’t necessarily a useless one.
A practical first step is to have your agent inspect your own system and report back without changing anything. Ask it to identify the largest memory users and the directories taking up the most storage, explain what each one belongs to, and propose specific fixes, before touching anything. That gives you a map of what’s safe to close or delete versus what’s still doing real work.
Common things this kind of audit turns up: multiple development servers left running from finished side projects, browser tabs still open from testing, duplicate build caches across work trees, and in some documented cases, crash report folders or checkpoint data that ballooned to dozens or even over 100 gigabytes. None of that is doing you any good once the task is done.
Once you know what’s abandoned versus active, close the abandoned stuff and recheck Activity Monitor. If memory pressure and storage usage ease up, you’ve found your leak. If a project might need to be regenerated later, confirm you can rebuild it from source before deleting its build artifacts.
How do you stop the mess from coming back?
Three habits do most of the work:
Give every agent a stopping point. Agents are generally trained to keep going unless told otherwise. If you don’t define “done,” background processes like dev servers and open browser sessions just keep running, quietly holding memory. Tell the agent what finished looks like and where results should land, then actually close things out when it hits that point.
Manage simultaneous workloads deliberately. If you’ve got a dozen jobs queued, running them all at once (every browser, every conversion tool, every local model call simultaneously) is how you max out a machine fast. Instead, have the agent profile the load and run one or two heavy steps at a time, checking memory as it goes. CPU core count doesn’t map cleanly to how many agents you can run: two agents waiting on cloud responses barely touch local resources, while two agents doing a local build or rendering video will consume everything available.
Tune your local model settings if you run them. Tools like Ollama, LM Studio, and Docker Desktop all have memory-relevant controls: context window size, parallel request limits, and how long a model stays loaded in memory between requests. Keeping a model loaded reduces latency on your next prompt but holds memory the whole time it’s idle. That’s a real trade-off you have to make deliberately, not by default.
Is it worth buying a new Mac or more hardware to fix this?
Only after you’ve done the audit and the load management, not before. The core issue isn’t that your Mac is too slow, it’s that agent workloads expand to use whatever capacity you give them. A bigger Mac Studio or Mac mini buys you more room, but it doesn’t change the underlying behavior of agents leaving processes running or queuing every job simultaneously. If you upgrade without fixing the habits, you’ll just hit the new ceiling later.
If you do upgrade, keep your old machine running rather than retiring it. A second Mac can absorb slower background agent jobs, freeing your primary machine for active work. That turns a sunk cost into extra capacity instead of e-waste.
Frequently Asked Questions
How do I check Mac memory pressure for AI agents?
Open Activity Monitor, click the Memory tab, and watch the pressure graph while your agents are running. Green is healthy, yellow and red mean the system is struggling. The app list below shows exactly which processes are consuming RAM.
Why does Codex or Claude Code use so much local storage?
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
Because the agent itself runs in the cloud, but the work it triggers (dev servers, build tools, dependency installs, logs, crash reports, checkpoint data) executes and gets stored locally. Reported cases have included crash folders over 50GB and checkpoint-related Git data exceeding 100GB.
Will more RAM or a faster chip fix agent memory problems?
It buys temporary headroom, but it doesn’t address the underlying issue: agents expand to use available capacity, and multiple harnesses running together compound the load. Audit and workload management matter more than raw hardware specs.
Can an AI agent clean up its own mess safely?
Yes, but only if you ask it to inspect and report first, without making changes, before approving any deletions. This avoids removing files that are still actively needed versus ones that are just sitting idle.
Does running local models like Qwen add to the problem?
Yes. Local models have their own memory footprint tied to context size, parallel requests, and whether the model stays loaded between prompts. Running local models alongside cloud-based agents like Codex or Claude Code compounds total memory pressure on the machine.