AI Mac Cleaners: What a Model Should and Should Not Decide

DeveloperPublished Updated 15 min read

"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.

A cleanup pipeline split in two: enumerate, attribute, rank and explain on the probabilistic side where a wrong answer costs attention, and the protection list plus the delete decision on the deterministic side where a wrong answer 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 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 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 Clean tool after a reviewed sweep, reporting reclaimed space with the candidates that produced it listed by path and size.
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 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 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 <model>, and hf cache ls with hf cache rm model/<repo> --dry-run. Why deleting blob files by hand orphans a model is covered in removing AI tool leftovers.

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 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.

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.