Apple Intelligence shows up as 29 GB in macOS Storage settings. Strip out the models and that number drops to roughly 3.07 GB. Both of those are real, and the gap between them is the entire story.
I run backend infrastructure for a living. My mental model for any machine is simple: every byte on disk is either doing work, waiting to do work, or costing me money for nothing. Twenty-six gigabytes of generative model weights sitting on a soldered SSD I can’t upgrade falls squarely in the third bucket. On a 256 GB MacBook that’s over ten percent of the volume, allocated by default, for a feature set I never scheduled.
Why this registers as an infrastructure problem
Developer laptops are not consumer devices. Mine holds Docker images, multiple language toolchains, local Postgres volumes, node_modules graveyards, and build caches that balloon without warning. Disk pressure on that machine isn’t an inconvenience, it’s a failed build at the worst possible moment. When you’re already playing Tetris with container layers, a fixed 29 GB block that arrived uninvited changes your capacity planning.
The same logic hits harder on fleets. If you manage Mac build runners or a shared CI pool, that allocation multiplies by host count. Nobody budgets storage for model weights that no job in the pipeline will ever call.
What the cleanup actually involves
AppleInsider’s Andrew Orr documented the removal path for macOS 27. The short version: the bulk of the weight lives in a main model folder, and deleting it is what frees the SSD space. The process runs through Terminal to purge the hidden generative models and visual assets rather than through a toggle in System Settings. I’d point you to Orr’s writeup for the exact commands instead of repeating paths from memory, because mistyping a recursive delete against a system directory is a far more expensive mistake than losing 26 GB.
If you do go down this road, treat it like any other production change:
- Have a current backup before you remove anything. Time Machine or a clone, verified, not assumed.
- Read the commands before pasting them. Understand what each path points at.
- Record the before and after numbers from Storage settings so you know what you actually recovered.
- Expect to repeat the procedure. More on that below.
The payoff is measurable: 29 GB down to about 3.07 GB. That’s a solid return for a few minutes of work, and it’s the kind of cleanup that’s easy to document once and hand to the rest of your team.
The part that breaks the pattern
Here’s where my engineering brain starts twitching. macOS 27 still downloads the data for EU users and removes options to disable the functionality. So the deletion isn’t a configuration change. It’s a one-time correction against a system that will happily undo it.
Any backend engineer recognizes this shape. You’ve fought it before: a cleanup script that competes with a daemon whose job is to restore the thing you just removed. You can win individual rounds, but you don’t win the match, because the other side runs on a schedule and you run on attention. Users who reclaim the space may lose it again on upgrade to macOS 27, which turns a fix into a maintenance chore with no end date.
That’s the real cost. Not the gigabytes, the recurring manual intervention. Twenty-six gigabytes recovered once is a win. Twenty-six gigabytes recovered after every point release is a task on your plate forever, and it’s exactly the kind of toil that proper configuration would eliminate in a single line.
What I’d rather see
The MacRumors forum thread on this, where people are reporting 30 GB-plus allocations on macOS 27, lands on the same ask I’d make: not just a disable switch, but genuine removal. Those are different capabilities. Disabled means the bits stay and the feature goes quiet. Removed means I get my capacity back and it stays back.
Every piece of infrastructure software I depend on offers this distinction. Optional components install on request. Uninstalling returns the resources. The system doesn’t re-provision what I explicitly declined. None of that is an unreasonable expectation for an operating system shipping on hardware where storage is permanent at purchase and priced accordingly.
So yes, run the cleanup. Back up first, read the commands, reclaim your 26 GB, and put a note in your team’s runbook so the next person doesn’t have to rediscover it. Just go in with clear eyes about what you’re buying: breathing room until the next upgrade, not a settled configuration. Treat it as a scheduled maintenance item rather than a fix, and you won’t be surprised when the disk fills up again.
đź•’ Published: