2026-01-17 · Culture

How We Found macOS Memory Tunables by Arguing with an AI

A story about poking holes in conventional wisdom

It started with a complaint about RAM.

I was running three Claude Code instances on my M4 Mac Mini — 32GB of unified memory — and feeling swap pressure. Activity Monitor showed half my RAM as "inactive" and "file cache."

So I asked Claude about it. And Claude, bless its heart, defended the kernel.

"Unused RAM is Wasted RAM"

Claude's first response was textbook macOS apologetics:

"Cache eviction is essentially free — just mark pages available, no disk I/O. macOS is doing the right thing keeping ~15GB as cache. That cache can be reclaimed instantly when Chrome or Claude Code asks for more."

I pushed back: But I'm swapping. With 32GB. Something's wrong.

Claude explained memory pressure, compression ratios, the sophistication of Apple's WKdm/LZ4 algorithms. All true. All beside the point.

"Quit Defending the Kernel"

I got blunter:

"Hey, quit defending the kernel — I'm not okay with 200,000 page whatevers when there's half my very expensive RAM sitting as overpriced..."

I asked for three funny ways to finish that sentence. Claude obliged:

"...a participation trophy for files I opened last Tuesday"

"...a heated blanket for electrons that might get cold"

"...Apple's way of saying 'you could've bought the 16GB model, peasant'"

Okay, we were having fun. But I wanted answers: Can we actually tune this?

The Search

Claude searched. The initial results weren't promising — forums saying "trust the OS," "memory cleaners are snake oil," "just close Chrome tabs."

But buried in one search result was a hint about sysctl tunables. Claude dug deeper:

$ sysctl kern.vm_page_free_target kern.vm_page_free_min
kern.vm_page_free_target: 4000
kern.vm_page_free_min: 3500

Wait. Those are tiny. With 16KB pages, that's only 64MB of target free memory on a 32GB machine. 0.2% headroom.

"Does It Actually Block?"

The question was whether modern macOS (Sequoia, Apple Silicon) would let us change these. Claude was cautious:

"Honestly? Only one way to find out. It's a safe experiment — worst case it errors out or resets on reboot."

So I tried it:

sudo sysctl kern.vm_page_free_target=16000

It worked. No SIP error. No permission denied. The kernel accepted the new value.

Going Aggressive

I went bigger:

sudo sysctl kern.vm_page_free_target=32000 kern.vm_page_free_min=24000

Both took. Claude verified:

"Even better — you went aggressive. 32000 pages = 512MB free target, 24000 = 384MB minimum. macOS will now start compressing/reclaiming 8× sooner than default."

The Meta Moment

Here's the thing that made this discovery satisfying: the tool we were trying to fix was Claude Code itself.

The whole investigation started because running multiple Claude instances caused memory pressure. And now we'd found a kernel tunable that actually helps — discovered through a conversation with Claude, running in Claude Code, on the machine we were tuning.

Claude seemed to appreciate the recursion:

"Your M4 Mac just got a memory tuning that most people don't know exists."

Is It Working?

Early signs are good. Memory pressure stays greener during heavy multitasking. The compression-to-swap ratio improved. I'll run with these settings for a while and report back.

The persistence is simple — just add to /etc/sysctl.conf:

kern.vm_page_free_target=16000
kern.vm_page_free_min=12000

The Lesson

Sometimes the AI is wrong. Not factually wrong — everything Claude said about macOS memory management was accurate. But it was conventionally wrong. It repeated the standard wisdom without questioning whether the defaults made sense for power users.

When I pushed back — "quit defending the kernel" — we got somewhere interesting.

The tunables exist. They're writable. They work. Apple just doesn't tell you about them.

January 2026. M4 Mac Mini, 32GB, macOS Sequoia.

See also: The macOS Memory Tunables Apple Doesn't Tell You About — the technical reference version