I upgraded from 8GB to 16GB, then 24GB, as my web development setup grew to include more Docker containers, simulations, browsers, and development tools. I eventually bought a 96GB Mac Studio so I could run my normal workflow while also keeping unrelated apps open.
Instead, macOS seems to use more memory now that more is available. Chrome sometimes reaches 8GB, VS Code around 5GB, Ghostty about 6GB, and Docker roughly 16GB. Activity Monitor also shows a large amount of cached memory, yet the system still uses around 6–20GB of swap. Once memory pressure turns red, the entire machine becomes extremely sluggish and I often have to force-quit applications.
I understand that unused RAM can be used for file and application caches, and that cached memory should normally be released when needed. However, why would macOS be swapping while so much memory appears to be cached? Is there a way to limit this behavior, or should I focus on finding which application or container is causing the actual memory pressure?
4 Answers
Cached memory is generally not a problem. macOS uses otherwise idle RAM to cache files and recently used data, and that memory can be reclaimed when an application needs it. The important metric is memory pressure, not whether the RAM graph is nearly full.
That said, red memory pressure, heavy swap activity, and the whole machine becoming unusable are real symptoms—not just cosmetic RAM usage. Check which processes are growing over time, especially Docker containers, browser tabs or extensions, VS Code extensions, and Ghostty. A terminal application using several gigabytes is unusual and worth investigating. Also make sure the internal drive has plenty of free space, since swap performance gets worse when the disk is nearly full.
Swap itself is not automatically bad. macOS may move inactive memory pages to disk while keeping frequently accessed data in RAM, even before every byte of physical memory is consumed. With a large amount of RAM, the system can also retain more cache.
However, swap should not make a 96GB machine crawl during ordinary development. Compare Activity Monitor's Memory Pressure, Swap Used, compressed memory, and the top processes while the problem is happening. Restart Docker and stop containers one at a time to identify whether a service is leaking. You can also test the workflow with Chrome extensions disabled and without Ghostty or unusual VS Code extensions running.
If the only issue is seeing a full RAM graph, leave it alone—full RAM is often the efficient state. If applications are actually freezing, force-quit dialogs are appearing, and memory pressure stays red, then the system is genuinely under pressure. Capture Activity Monitor sorted by memory during the slowdown and check the specific Docker VM, containers, browser processes, and development tools rather than trying to reduce harmless cached memory.
The numbers you listed are much more suspicious than macOS's cache. Docker using 16GB may be expected if its VM has been assigned that much, but Ghostty at 6GB and VS Code at 5GB deserve attention. Check Docker's memory allocation and container statistics, inspect browser tabs and extensions, and look for runaway language servers or build processes.
There is no normal switch that simply turns off memory caching. The practical fix is to locate the workload that is continuously consuming or retaining memory. Also remember that Apple silicon uses unified memory, so graphics workloads and virtual machines share the same pool.
The cache should normally be evicted before the system becomes desperate for memory. If pressure is red while individual apps keep growing, I would treat that as an application or container leak rather than a macOS feature that needs disabling.