# AI Mac Cleaners: What a Model Should and Should Not Decide
> Ranking and attribution can be probabilistic, the delete decision cannot. How cc-cleaner, DevCleaner, agent skills and Mole each draw that line, and which one fits your disk.
Published: 2026-08-20 | Updated: 2026-08-22
"AI Mac cleaner" resolves to two different products. One is a cleanup app with a model
somewhere inside it, sold on the intelligence of its recommendations. The other is a tool
for reclaiming the disk that Claude Code, Cursor, Ollama and their caches have quietly
taken over the past year. The second is what most people typing that phrase in 2026 want.
The first is worth answering first, because the answer decides how much to trust anything
in the second group.
## Part one: what the model is actually deciding
A cleaner that advertises AI is making a claim about one step in a pipeline that has at
least four:
1. **Enumerate.** Walk the disk and measure it. `du`-shaped work, no judgement in it.
2. **Attribute.** Decide which app or toolchain owns each path.
3. **Rank and explain.** Decide which twelve of four thousand candidates deserve a look,
and say in a sentence what each one is.
4. **Decide and delete.** Decide what is safe to remove, then remove it.
Steps 2 and 3 are genuinely fuzzy, and a model genuinely helps there. Step 4 is a different
kind of problem, and a model is the wrong instrument for it. Almost every argument about AI
cleaners is really an argument about which step the vendor means.
### Where a model earns its place
Attribution is the honest hard case. Suppose you find
`~/Library/Application Support/Foo Labs` holding 3 GB with no app called Foo Labs on the
disk. The evidence is weak and scattered: bundle identifier fragments inside the folder's
own plists, a matching prefix in `~/Library/HTTPStorages`, a `.savedState` bundle under
`~/Library/Saved Application State`, an install receipt in `/var/db/receipts`. Name
equality fails immediately, because the vendor writes `Foo Labs` in one place and
`com.foolabs.editor` in another, and a handwritten catalogue covers the top few hundred
apps then falls off a cliff. This is the exact shape where a model beats a rule: many weak
signals, no decisive one, a long tail nobody will finish cataloguing.
Ranking is the same shape: a scan returning 4,000 paths and 60 GB is a second problem, not
a result. Explanation is easier still, since turning
`~/Library/Caches/com.apple.nsurlsessiond` into a plain sentence is translation. A tool
using a model for those three jobs, and saying so, advertises a real feature.
### Why the last gate has to be deterministic
The delete decision needs three properties a model cannot supply.
**Determinism.** Same disk, same version, same answer, every time. Temperature zero does
not buy this, because the prompt carries your machine's contents: install one more app, the
file listing shifts, and the tokens the decision hangs on shift with it. A safety rule that
holds on your Mac but not your colleague's is not a safety rule.
**Auditability before the fact.** A protection list is a set of path prefixes, readable in
full in a minute and diffable between two releases. Weights plus a prompt cannot be read as
a list of what will be refused, so nothing shows you the boundary before you cross it.
**Auditability after the fact.** When a deterministic rule deletes the wrong thing you get
a reproducible bug: here is the path, here is the line that allowed it, here is the test
that now fails. When a model does it, the artifact is a transcript, the fix is a prompt
edit, and that edit's effect on every other case is unmeasured.
The failure modes are also asymmetric. A bad ranking costs a scroll; a bad delete of
`~/.claude/projects` costs every transcript you have. So the frame is not "AI good, AI
bad", it is a split down the middle of the pipeline: probabilistic where being wrong costs
attention, deterministic where being wrong costs data.
The split is not between smart and dumb tools, it is between the half of the pipeline where being wrong wastes a scroll and the half where being wrong loses a file.
### Which side Mole is on
[Mole](https://mole.fit/) ships no model and runs no inference. Whether a path can ever become a deletion
candidate is decided by a fixed array of blocked relative prefixes compiled into the app,
holding entries like `.ollama/models`, `.lmstudio/models`, `.cache/huggingface`,
`.cache/torch`, `.claude/projects`, `.codex/sessions`, `.grok/sessions` and
`Library/Caches/com.apple.e5rt.e5bundlecache`. The user-editable half is a plain text file
you can read with `cat ~/.config/mole/whitelist`. The free
[Mole CLI](https://github.com/tw93/Mole) is open source under GPL-3.0 and applies the same
list, so the code enforcing it is public.
That last entry is the argument in miniature. `com.apple.e5rt.e5bundlecache` sits in
`~/Library/Caches` and the word in its name is "cache", so every heuristic on earth
classifies it as disposable. It holds Apple Neural Engine compiled models, and clearing it
while an app has models loaded breaks recognition calls until the machine restarts. It is
protected because a person hit that failure and wrote the line.
So the practical test for any tool here is one question: which of the four steps does the
model perform? Enumeration, attribution, ranking and explanation are credible answers. "It
decides what is safe to delete" is an answer to follow by asking to see the list, and if
there is no list there is nothing to review.
## Part two: tools for cleaning up after AI tools
This is the query most people mean. The footprint splits into four kinds of data with four
different rules, and conflating them is where accidents happen:
- **Tool caches and logs.** `~/Library/Caches/claude-cli-nodejs`, Cursor's Electron caches,
telemetry and debug directories under `~/.claude`. Regenerable and boring.
- **Transcripts and project state.** `~/.claude/projects`, `~/.codex/sessions`,
`~/.grok/sessions`. Often the largest surprise in a scan, and irreplaceable.
- **Old CLI versions.** Agent CLIs that self-update leave prior releases behind. On Codex
this measures roughly 300 MB per release, so five stacked releases reach 1.2 GB with one
live.
- **Model weights.** `~/.ollama/models`, `~/.cache/huggingface/hub`, the LM Studio models
directory. Largest by far, owned by the tool that downloaded them.
Measure before picking a tool:
```
du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h
```
### Mole, for a reviewed sweep that already knows these paths
The Clean tool scans first and shows a result you review before anything moves. Every
candidate row carries its exact path, owner and size, and anything the scanner is not
confident about arrives unchecked so the default click is the smaller action. Removals go
to the Trash rather than being unlinked, and every operation appends to
`~/Library/Logs/mole/operations.log` where `TRASHED` and `DELETED` are different words.
The scan finishes before the review screen appears, so you are never picking items out of a half-built list.
Two behaviours matter specifically for AI tooling. Old agent CLI version directories are
offered, but the live release never becomes a candidate: the launcher target is resolved
and pinned first, so the version you are running is excluded by construction rather than by
a version-number guess. And uninstall reasons about ownership instead of name matching, so
removing one app from a vendor does not offer the shared `Application Support` parent a
still-installed sibling owns.
To run the job: open Clean, let the scan finish, expand the groups that look large, uncheck
anything you want to keep, then clean and check the freed space. Scanning is free and each
paid tool runs twice for free, so the whole review is verifiable before deciding whether
$19 is worth it.
### The Mole CLI, when you would rather stay in the terminal
A separate free product, open source under GPL-3.0, installed with `brew install mole`.
Preview first, always:
```
mo clean --dry-run
mo purge --dry-run
```
`mo clean` handles caches and logs, `mo purge` targets old project build artifacts, and
every destructive command takes `--dry-run` so you read the exact path list first. It shares
the protection list and the operations log with the Mac app. One difference before you drop
the flag: CLI cache cleanup removes files permanently, while uninstall and leftover removal
still go to the Trash.
### cc-cleaner, the open source terminal option built for this problem
[cc-cleaner](https://github.com/elexingyu/cc-cleaner) is MIT licensed, Python 3.10 and
later, installable with `pipx install cc-cleaner`. It ships 22 cleaners including Claude
Code, npm, uv, cargo, Docker, Playwright, browser caches, and an AI/ML models group covering
Hugging Face, PyTorch, Whisper and Ollama. `cc-cleaner status` prints a size table,
`cc-cleaner clean` opens an interactive picker, `-n` is a dry run.
Its risk model is explicit: Safe items clean by default while Moderate and Dangerous items
require `--force`, and its README puts "conversation transcripts, shared stores" in the
Moderate tier. The source tells you the rest. Its Ollama cleaner removes the whole of
`~/.ollama/models` as one directory, its Hugging Face cleaner does the same to
`~/.cache/huggingface/hub` and `datasets`, and its Claude cleaner offers the `*.jsonl`
transcripts under `~/.claude/projects`. Deletion is `shutil.rmtree` and `Path.unlink`, so
nothing lands in the Trash. Its safety layer is a frozen set of forbidden system paths plus
a requirement that every target sit under your home directory: a deterministic list a human
wrote, exactly as it should be. The difference is where the line sits, not rigour.
cc-cleaner puts model stores and transcripts behind a flag; Mole refuses them.
### DevCleaner, if you want a menu bar app for the same ground
[DevCleaner](https://devcleaner.app) is a macOS 14+ menu bar utility, currently 1.9.0,
covering 23 ecosystems from Xcode DerivedData and Gradle to npm and Docker, with dedicated
scanners for Claude, ChatGPT, Cursor, Ollama and LM Studio. Safe items are deleted by
default, Warning items are "your call", Danger items are never pre-selected, and it keeps a
hard deny-list for credentials and session files plus a warning before touching a running
app's caches. Core cleanup is free and Pro is sold as a one-time purchase or a yearly
subscription; check current numbers on the vendor page. Its site does not say whether
removals go to the Trash, which is the thing worth asking before a first run.
MacPaw also ships a CleanMyMac CLI as a public beta, via a Homebrew cask, aimed at the same
artifacts. It is proprietary, its repository is an issue tracker rather than source, and its
behaviour is explicitly still changing, so read what its confirmation step shows you rather
than any published description.
### Pointing an agent at your own disk
The last route is to skip cleanup tools and ask Claude Code or a similar agent to clean the
disk directly, optionally through one of the published cleanup skills. Its advantage is
real and nothing else here has it: an agent can reason about a layout nobody has
catalogued, whether that is a framework released last month, a private toolchain, or a home
directory arranged the way only you arrange it.
The assessment has to be equally plain. The shell commands are generated at inference time
against your real filesystem, so what runs was never reviewed by anyone before it ran.
There is no dry run unless you demand one. The blast radius is your home directory, and
`rm -rf` composed from a variable that turned out empty is a failure mode with a long
history. Part one applies with the safety net removed: the decision is probabilistic and
wired straight to the last gate.
Four guardrails cost almost nothing:
- **Have it drive a tool with a preview flag instead of composing removals itself.** One
public Claude Code skill wraps the `mo` CLI and makes `mo clean --dry-run` mandatory
before `mo clean`, prints the full dry-run output, and requires a typed confirmation. The
agent picks the target, a deterministic tool performs the delete.
- **Never pre-approve `rm` in your permission settings.** Approve each removal command
individually, and read the path rather than the summary of it.
- **Make the Trash the default.** `trash` from Homebrew, or `mv` into `~/.Trash`, turns
every mistake into a recoverable one.
- **Bound the working set.** Point it at one directory, and ask for `du -sh` before and
`df -h` after so the claimed reclaim is measured rather than estimated.
### Model stores belong to the tool that downloaded them
No general cleaner should be your instrument here, including the ones above. Ollama and
Hugging Face both keep content-addressed stores where models share blobs, so only the owning
tool knows which blob is still referenced. Use `ollama ls` and `ollama rm `, and
`hf cache ls` with `hf cache rm model/ --dry-run`. Why deleting blob files by hand
orphans a model is covered in
[removing AI tool leftovers](https://mole.fit/blog/how-to-remove-ai-tool-leftovers-mac).
## How they compare
| Tool | Decides deterministically | Previews paths | Recoverable | Protects model stores and chat history | Cost |
|---|---|---|---|---|---|
| Mole for Mac | Fixed blocked-prefix list plus user whitelist | Yes, path, owner and size per row | Yes, Trash by default, plus an operation log | Yes, never candidates | $19 once, two Macs, lifetime updates |
| Mole CLI | The same shared protection list | Yes, `--dry-run` on every destructive command | Uninstall to Trash, cache cleanup permanent | Yes, same list | Free, GPL-3.0 |
| cc-cleaner | Frozen forbidden-path set, home-directory bound | Yes, `-n` dry run and an interactive picker | No, `shutil.rmtree` and `unlink` | Reachable behind `--force`, not refused | Free, MIT |
| DevCleaner | Three risk tiers plus a credentials deny-list | Sizes per scanner, Danger never pre-selected | Not documented, ask before running | Model weights called out as a separate class | Free core, Pro one-time or yearly |
| CleanMyMac CLI | Not published, repository is an issue tracker | Yes, confirmation before removal | Not documented | Not documented | Public beta, check vendor terms |
| Agent with shell access | Nothing, decided at inference time | Only if you demand it | Only if you force the Trash | Only if you say so in the prompt | Your agent subscription |
| `ollama rm`, `hf cache rm` | Reference counting inside the store | `hf cache rm --dry-run` | No, but re-downloadable | This is the protection | Free |
## The boundary, stated plainly
Mole is not malware response, not a backup, and not a substitute for a vendor uninstaller
on software shipping drivers, VPN components or system extensions. It does not delete model
weights or AI chat history, so if your 200 GB problem is entirely a model library, it shows
you the shape of that library in Analyze and hands the job to Ollama or LM Studio. That is
a deliberate boundary, not a gap to be closed later.
## Picking one
**200 GB of build output and a dozen toolchains.** The volume is in caches, old
`node_modules`, DerivedData and Docker, not in anything AI-specific. Start with a reviewed
sweep or `mo clean --dry-run`, then work through
[clearing developer caches](https://mole.fit/blog/how-to-clear-dev-caches-mac) for the stores needing their
own prune command. cc-cleaner is a good second pass if you read its risk tiers first.
**A big local model library.** Skip general cleaners for the weights entirely. `ollama ls`,
`hf cache ls` and LM Studio's My Models view are the only tools that can free a shared blob
safely. Use a disk map to find the store and the owning tool to change it.
**You just noticed Cursor or Claude Code eating disk.** The most tractable case: caches and
logs regenerate, old CLI versions are pure waste, and the transcripts are the one thing not
to touch. Any reviewed tool here handles it, and the step-by-step version is in
[cleaning up after AI coding tools](https://mole.fit/blog/how-to-clean-up-ai-coding-tools-mac).
## FAQ
### Does an AI-powered Mac cleaner delete more safely than a normal one?
Not on the evidence available. A model can beat a rule at deciding which app owns an
orphaned folder and at ranking what deserves attention, because those are fuzzy problems
with many weak signals. Deciding whether a path is safe to delete needs determinism and an
auditable list, neither of which a model provides. Ask a vendor which pipeline step their
model runs, and treat "it decides what is safe to delete" as a prompt to see the list.
### Is it safe to let Claude Code clean my Mac?
It is the most flexible option and the least bounded one. The commands are generated at
inference time and run against your home directory, with no preview unless you ask for one.
If you do it, make the agent drive a tool that has a dry-run flag rather than composing
`rm -rf` itself, never pre-approve `rm` in your permission settings, send removals to the
Trash, and confine it to one directory at a time.
### Will a Mac cleaner delete my Ollama models or my Claude Code history?
It depends entirely on the tool, which is why it is the question to ask first. Mole blocks
`~/.ollama/models`, `~/.lmstudio/models`, `~/.cache/huggingface`, `~/.claude/projects`,
`~/.codex/sessions` and `~/.grok/sessions` at the deletion gate at any age, so they never
become candidates. cc-cleaner classifies model directories and Claude Code transcripts as
Moderate risk and removes them if you pass `--force`. Read a tool's risk tiers before the
first run rather than after.
### What is actually taking the space after a year of AI coding tools?
Usually old CLI versions and transcripts rather than the caches people expect. An agent CLI
that self-updates can leave several hundred megabytes per release behind, and on Codex five
stacked releases reach roughly 1.2 GB with one live. Transcripts under `~/.claude/projects`
accumulate quietly and are the item most likely to surprise you in a scan, which is also
why they should be excluded from a sweep rather than included.
## Related reading
- [Clean up Ollama and LM Studio models on Mac](https://mole.fit/blog/how-to-remove-ai-tool-leftovers-mac)
for the mechanics of content-addressed model stores.
- [Clear developer caches without breaking builds](https://mole.fit/blog/how-to-clear-dev-caches-mac) for
package manager stores and scattered `node_modules`.
- [Clean up after AI coding tools](https://mole.fit/blog/how-to-clean-up-ai-coding-tools-mac) for the
step-by-step version, path by path.
---
Canonical HTML page: https://mole.fit/blog/ai-mac-cleaner-tools
Blog index for agents: https://mole.fit/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
