KI-Mac-Cleaner: Was ein Modell entscheiden darf und was nicht

„AI Mac Cleaner" meint zwei verschiedene Dinge. Das eine ist eine Cleanup-App mit einem Modell irgendwo darin, verkauft über die Intelligenz ihrer Empfehlungen. Das andere ist ein Werkzeug, um den Speicherplatz zurückzuholen, den Claude Code, Cursor, Ollama und ihre Caches im letzten Jahr still und leise belegt haben. Das zweite ist es, was die meisten Leute 2026 meinen, wenn sie diese Suchanfrage eingeben. Trotzdem lohnt es sich, zuerst das erste zu klären, denn die Antwort entscheidet, wie viel Vertrauen alles in der zweiten Gruppe verdient.

Teil eins: Was das Modell tatsächlich entscheidet

Ein Cleaner, der mit KI wirbt, macht eine Aussage über einen einzigen Schritt in einer Pipeline, die mindestens vier hat:

1. Erfassen. Die Festplatte durchlaufen und vermessen. Arbeit in der Form von du, ohne jedes Urteilsvermögen.
2. Zuordnen. Entscheiden, welche App oder Toolchain zu welchem Pfad gehört.
3. Einordnen und erklären. Entscheiden, welche zwölf von viertausend Kandidaten einen Blick wert sind, und in einem Satz sagen, was jeder einzelne ist.
4. Entscheiden und löschen. Entscheiden, was gefahrlos entfernt werden kann, und es dann entfernen.

Schritt zwei und drei sind wirklich unscharf, und dort hilft ein Modell tatsächlich. Schritt vier ist ein Problem anderer Art, für das ein Modell das falsche Werkzeug ist. Fast jede Debatte über KI-Cleaner dreht sich in Wahrheit darum, welchen Schritt der Anbieter eigentlich meint.

Wo sich ein Modell lohnt

Die Zuordnung ist der ehrlich schwierige Fall. Angenommen, Sie finden ~/Library/Application Support/Foo Labs mit 3 GB Inhalt, aber keine App namens Foo Labs auf der Platte. Die Indizien sind schwach und verstreut: Bundle-Identifier-Fragmente in den eigenen Plists des Ordners, ein passendes Präfix in ~/Library/HTTPStorages, ein .savedState-Bundle unter ~/Library/Saved Application State, eine Installationsquittung in /var/db/receipts. Ein einfacher Namensabgleich scheitert sofort, weil der Hersteller an der einen Stelle Foo Labs schreibt und an der anderen com.foolabs.editor, und ein von Hand gepflegter Katalog deckt die paar hundert wichtigsten Apps ab, bevor er abrupt endet. Genau in dieser Form schlägt ein Modell eine feste Regel: viele schwache Signale, keines davon eindeutig, ein langer Schwanz, den niemand je fertig katalogisieren wird.

Beim Einordnen zeigt sich dasselbe Muster: Ein Scan, der 4.000 Pfade und 60 GB zurückgibt, ist selbst ein neues Problem, kein Ergebnis. Das Erklären ist noch einfacher, denn ~/Library/Caches/com.apple.nsurlsessiond in einen verständlichen Satz zu übersetzen, ist reine Übersetzungsarbeit. Ein Tool, das ein Modell für genau diese drei Aufgaben einsetzt und das auch so sagt, bewirbt ein echtes Feature.

Warum das letzte Tor deterministisch sein muss

Die Löschentscheidung braucht drei Eigenschaften, die ein Modell nicht liefern kann.

Determinismus. Gleiche Festplatte, gleiche Version, jedes Mal dieselbe Antwort. Temperatur null erkauft das nicht, weil der Prompt den Inhalt Ihres Rechners mitträgt: Installieren Sie eine App mehr, verschiebt sich die Dateiliste, und mit ihr verschieben sich die Tokens, an denen die Entscheidung hängt. Eine Sicherheitsregel, die auf Ihrem Mac gilt, aber nicht auf dem Ihres Kollegen, ist keine Sicherheitsregel.

Prüfbarkeit im Voraus. Eine Schutzliste ist eine Menge von Pfadpräfixen, in einer Minute vollständig lesbar und zwischen zwei Versionen per Diff vergleichbar. Gewichte plus Prompt lassen sich nicht als Liste dessen lesen, was verweigert wird, also zeigt Ihnen nichts die Grenze, bevor Sie sie überschreiten.

Prüfbarkeit im Nachhinein. Löscht eine deterministische Regel das Falsche, bekommen Sie einen reproduzierbaren Fehler: hier der Pfad, hier die Zeile, die es erlaubt hat, hier der Test, der jetzt fehlschlägt. Macht ein Modell das, ist der einzige Beleg ein Transkript, die Korrektur eine Prompt-Änderung, und welche Wirkung diese Änderung auf jeden anderen Fall hat, bleibt ungemessen.

Auch die Fehlerfolgen sind ungleich verteilt. Eine schlechte Einordnung kostet einen Scroll, ein falsches Löschen von ~/.claude/projects kostet jedes Transkript, das Sie je hatten. Die richtige Frage lautet also nicht „KI gut, KI schlecht", sondern wo die Pipeline in der Mitte geteilt wird: probabilistisch dort, wo ein Fehler nur Aufmerksamkeit kostet, deterministisch dort, wo ein Fehler Daten kostet.

Auf welcher Seite Mole steht

Mole liefert kein Modell aus und führt keine Inferenz durch. Ob ein Pfad überhaupt zum Löschkandidaten werden kann, entscheidet eine feste, in die App einkompilierte Liste gesperrter relativer Präfixe mit Einträgen wie .ollama/models, .lmstudio/models, .cache/huggingface, .cache/torch, .claude/projects, .codex/sessions, .grok/sessions und Library/Caches/com.apple.e5rt.e5bundlecache. Die vom Nutzer editierbare Hälfte ist eine reine Textdatei, die Sie mit cat ~/.config/mole/whitelist lesen können. Die kostenlose Mole-CLI ist Open Source unter GPL-3.0 und wendet dieselbe Liste an, der Code, der sie durchsetzt, liegt also offen.

Der letzte Eintrag ist das ganze Argument im Kleinen. com.apple.e5rt.e5bundlecache liegt in ~/Library/Caches, und in seinem Namen steckt das Wort „cache", also stuft ihn jede Heuristik der Welt als entbehrlich ein. Tatsächlich enthält er kompilierte Modelle für die Apple Neural Engine, und ihn zu leeren, während eine App Modelle geladen hat, bricht Erkennungsaufrufe, bis der Rechner neu startet. Geschützt ist er, weil jemand genau in diesen Fehler gelaufen ist und die Zeile geschrieben hat.

Der praktische Test für jedes Tool hier ist also eine einzige Frage: Welchen der vier Schritte übernimmt das Modell? Erfassung, Zuordnung, Einordnung und Erklärung sind glaubwürdige Antworten. Auf „Es entscheidet, was sicher gelöscht werden kann" folgt am besten die Bitte, die Liste zu sehen, und gibt es keine Liste, gibt es auch nichts zu prüfen.

Teil zwei: Werkzeuge zum Aufräumen nach KI-Tools

Das ist gemeint, wenn die meisten Leute danach suchen. Der Fußabdruck zerfällt in vier Datenarten mit vier verschiedenen Regeln, und genau dort, wo man sie vermischt, passieren die Unfälle:

• Tool-Caches und Logs. ~/Library/Caches/claude-cli-nodejs, die Electron-Caches von Cursor, Telemetrie- und Debug-Verzeichnisse unter ~/.claude. Regenerierbar und uninteressant.
• Transkripte und Projektzustand. ~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions. Oft die größte Überraschung in einem Scan, und unersetzlich.
• Alte CLI-Versionen. Agenten-CLIs mit Selbstupdate lassen frühere Releases zurück. Bei Codex sind das rund 300 MB pro Release, fünf angehäufte Releases kommen so auf 1,2 GB, obwohl nur eines aktiv genutzt wird.
• Modellgewichte. ~/.ollama/models, ~/.cache/huggingface/hub, das Modelle-Verzeichnis von LM Studio. Mit Abstand am größten, und Eigentum des Tools, das sie heruntergeladen hat.

Erst messen, dann ein Tool wählen:

du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h

Mole, für einen geprüften Durchgang, der diese Pfade schon kennt

Das Clean-Tool scannt zuerst und zeigt Ihnen ein Ergebnis, das Sie prüfen, bevor sich irgendetwas bewegt. Jede Kandidatenzeile trägt ihren genauen Pfad, Eigentümer und ihre Größe, und alles, bei dem sich der Scanner nicht sicher ist, kommt unmarkiert an, sodass der Standardklick die kleinere Aktion auslöst. Entferntes wandert in den Papierkorb, statt direkt gelöscht zu werden, und jede Operation hängt sich an ~/Library/Logs/mole/operations.log an, wo TRASHED und DELETED zwei verschiedene Wörter sind.

Zwei Verhaltensweisen sind speziell für KI-Werkzeuge wichtig. Alte Versionsverzeichnisse von Agenten-CLIs werden angeboten, das aktive Release wird aber nie zum Kandidaten: Das Launcher-Ziel wird zuerst aufgelöst und festgelegt, sodass die gerade laufende Version bereits konstruktionsbedingt ausgeschlossen ist und nicht bloß über eine geratene Versionsnummer. Und beim Deinstallieren zählt die Eigentümerschaft, nicht der Namensabgleich, sodass beim Entfernen einer App eines Herstellers der gemeinsame Application Support-Elternordner nicht mit angeboten wird, wenn ein noch installiertes Geschwisterprogramm ihn braucht.

So läuft der Ablauf: Clean öffnen, den Scan abwarten, groß wirkende Gruppen aufklappen, alles abwählen, was bleiben soll, dann bereinigen und den freigewordenen Platz prüfen. Das Scannen ist kostenlos, und jedes kostenpflichtige Tool lässt sich zweimal gratis ausprobieren, sodass sich die ganze Prüfung nachvollziehen lässt, bevor Sie entscheiden, ob Ihnen $19 das wert sind.

Die Mole-CLI, wenn Sie lieber im Terminal bleiben

Ein eigenständiges kostenloses Produkt, Open Source unter GPL-3.0, installiert mit brew install mole. Erst die Vorschau, immer:

mo clean --dry-run
mo purge --dry-run

mo clean kümmert sich um Caches und Logs, mo purge zielt auf alte Build-Artefakte in Projekten, und jeder destruktive Befehl akzeptiert --dry-run, damit Sie zuerst die genaue Pfadliste lesen. Sie teilt sich die Schutzliste und das Betriebsprotokoll mit der Mac-App. Ein Unterschied, bevor Sie das Flag weglassen: Die CLI-Cache-Bereinigung entfernt Dateien endgültig, während Deinstallation und Rückstands-Entfernung weiterhin im Papierkorb landen.

cc-cleaner, die Open-Source-Terminal-Option für genau dieses Problem

cc-cleaner steht unter der MIT-Lizenz, braucht Python 3.10 oder neuer und lässt sich mit pipx install cc-cleaner installieren. Es bringt 22 Cleaner mit, darunter für Claude Code, npm, uv, cargo, Docker, Playwright, Browser-Caches, sowie eine KI/ML-Modellgruppe für Hugging Face, PyTorch, Whisper und Ollama. cc-cleaner status gibt eine Größentabelle aus, cc-cleaner clean öffnet eine interaktive Auswahl, -n ist ein Probelauf.

Das Risikomodell ist explizit: Safe-Elemente werden standardmäßig bereinigt, während Moderate- und Dangerous-Elemente --force verlangen, und die README ordnet „conversation transcripts, shared stores" in die Moderate-Stufe ein. Den Rest verrät der Quellcode. Der Ollama-Cleaner entfernt ~/.ollama/models als Ganzes in einem Rutsch, der Hugging-Face-Cleaner macht dasselbe mit ~/.cache/huggingface/hub und datasets, und der Claude-Cleaner bietet die *.jsonl-Transkripte unter ~/.claude/projects an. Gelöscht wird mit shutil.rmtree und Path.unlink, es landet also nichts im Papierkorb. Die Sicherheitsschicht ist eine fest eingefrorene Menge verbotener Systempfade plus die Vorgabe, dass jedes Ziel innerhalb des Home-Verzeichnisses liegen muss: eine deterministische Liste, von einem Menschen geschrieben, genau wie es sein sollte. Der Unterschied liegt darin, wo die Grenze gezogen wird, nicht in der Sorgfalt. cc-cleaner stellt Modellspeicher und Transkripte hinter ein Flag, Mole verweigert sie ganz.

DevCleaner, wenn Sie dafür lieber eine Menüleisten-App möchten

DevCleaner ist ein Menüleisten-Tool ab macOS 14, aktuell Version 1.9.0, das 23 Ökosysteme abdeckt, von Xcode DerivedData und Gradle bis npm und Docker, mit eigenen Scannern für Claude, ChatGPT, Cursor, Ollama und LM Studio. Safe-Elemente werden standardmäßig gelöscht, bei Warning-Elementen liegt die Entscheidung bei Ihnen, Danger-Elemente sind nie vorausgewählt, dazu kommt eine feste Sperrliste für Zugangsdaten und Session-Dateien sowie eine Warnung, bevor die Caches einer laufenden App angefasst werden. Die Grundfunktionen sind kostenlos, Pro wird als Einmalkauf oder Jahresabo verkauft; die aktuellen Preise stehen auf der Anbieterseite. Die Website sagt nicht, ob Entferntes im Papierkorb landet, und genau das lohnt sich, vor dem ersten Lauf zu klären.

MacPaw bietet außerdem eine CleanMyMac-CLI als öffentliche Beta über ein Homebrew-Cask an, die auf dieselben Artefakte zielt. Sie ist proprietär, ihr Repository dient nur als Issue-Tracker und nicht als Quellcode, und ihr Verhalten ändert sich ausdrücklich noch, also lesen Sie lieber, was der Bestätigungsschritt tatsächlich anzeigt, als irgendeine veröffentlichte Beschreibung.

Einen Agenten direkt auf die eigene Festplatte loslassen

Der letzte Weg überspringt Cleanup-Tools ganz und bittet Claude Code oder einen ähnlichen Agenten, die Platte direkt aufzuräumen, wahlweise über einen der veröffentlichten Cleanup-Skills. Sein Vorteil ist echt, und kein anderes Werkzeug hier hat ihn: Ein Agent kann über eine Struktur nachdenken, die niemand katalogisiert hat, egal ob das ein erst letzten Monat erschienenes Framework ist, eine private Toolchain oder ein Home-Verzeichnis, das nur Sie so angeordnet haben.

Genauso deutlich muss die Kehrseite benannt werden. Die Shell-Befehle entstehen live zur Laufzeit gegen Ihr echtes Dateisystem, also hat niemand geprüft, was da läuft, bevor es lief. Einen Probelauf gibt es nur, wenn Sie ausdrücklich danach verlangen. Der Wirkungsradius ist Ihr gesamtes Home-Verzeichnis, und ein rm -rf, das aus einer Variable zusammengesetzt ist, die sich als leer herausstellt, hat eine lange Geschichte als Fehlerquelle. Teil eins gilt hier ohne Sicherheitsnetz: Die Entscheidung ist probabilistisch und direkt mit dem letzten, kritischen Tor verdrahtet.

Vier Leitplanken kosten fast nichts:

• Den Agenten ein Tool mit Vorschau-Flag steuern lassen, statt Löschbefehle selbst zusammenzusetzen. Ein öffentlicher Claude-Code-Skill kapselt die mo-CLI und macht mo clean --dry-run vor mo clean verpflichtend, gibt die vollständige Vorschau aus und verlangt eine eingetippte Bestätigung. Der Agent wählt das Ziel, ein deterministisches Tool führt die Löschung aus.
• rm in den Berechtigungseinstellungen nie pauschal freigeben. Jeden Löschbefehl einzeln genehmigen, und dabei den Pfad lesen, nicht nur dessen Zusammenfassung.
• Den Papierkorb zum Standard machen. trash aus Homebrew, oder mv nach ~/.Trash, macht aus jedem Fehler einen wiederherstellbaren.
• Den Arbeitsbereich eng abstecken. Den Agenten auf ein einzelnes Verzeichnis ansetzen und vorher du -sh, hinterher df -h verlangen, damit der behauptete Gewinn gemessen und nicht bloß geschätzt ist.

Modellspeicher gehören dem Tool, das sie heruntergeladen hat

Hierfür sollte kein allgemeiner Cleaner Ihr Werkzeug sein, auch keiner der oben genannten. Ollama und Hugging Face führen beide inhaltsadressierte Speicher, in denen sich Modelle Blobs teilen, sodass nur das jeweilige Tool selbst weiß, welcher Blob noch referenziert wird. Nutzen Sie ollama ls und ollama rm <model>, sowie hf cache ls mit hf cache rm model/<repo> --dry-run. Warum manuell gelöschte Blob-Dateien ein Modell verwaisen lassen, steht in KI-Tool-Rückstände entfernen.

Der Vergleich im Überblick

Die Grenze, unverblümt gesagt

Mole ist keine Malware-Abwehr, kein Backup und kein Ersatz für den Deinstaller eines Herstellers bei Software, die Treiber, VPN-Komponenten oder Systemerweiterungen mitbringt. Es löscht weder Modellgewichte noch KI-Chatverläufe. Steckt Ihr 200-GB-Problem also komplett in einer Modellbibliothek, zeigt Ihnen Mole in Analyze nur deren Umriss und überlässt die eigentliche Arbeit Ollama oder LM Studio. Das ist eine bewusste Grenze, keine Lücke, die später noch geschlossen wird.

Die passende Wahl

200 GB Build-Output und ein Dutzend Toolchains. Das Volumen steckt in Caches, alten node_modules, DerivedData und Docker, nicht in irgendetwas KI-Spezifischem. Fangen Sie mit einem geprüften Durchgang oder mo clean --dry-run an, und arbeiten Sie sich dann durch Entwickler-Caches bereinigen für die Speicher, die einen eigenen Prune-Befehl brauchen. cc-cleaner eignet sich gut als zweiter Durchgang, wenn Sie vorher seine Risikostufen lesen.

Eine große lokale Modellbibliothek. Für die Gewichte selbst lassen Sie allgemeine Cleaner komplett außen vor. ollama ls, hf cache ls und die My-Models-Ansicht von LM Studio sind die einzigen Werkzeuge, die einen gemeinsam genutzten Blob gefahrlos freigeben können. Nutzen Sie eine Speicherkarte, um den Speicherort zu finden, und das zugehörige Tool, um ihn zu verändern.

Ihnen ist gerade aufgefallen, dass Cursor oder Claude Code Speicherplatz frisst. Der am leichtesten zu lösende Fall: Caches und Logs regenerieren sich, alte CLI-Versionen sind reine Verschwendung, und die Transkripte sind das Einzige, was unangetastet bleiben sollte. Jedes hier vorgestellte, geprüfte Tool kommt damit klar, die Schritt-für-Schritt-Version steht unter Aufräumen nach KI-Coding-Tools.

Häufige Fragen

Löscht ein KI-gestützter Mac-Cleaner sicherer als ein gewöhnlicher?

Nach allem, was bislang bekannt ist: nicht. Bei der Frage, welcher App ein verwaister Ordner gehört, und bei der Einordnung, was Aufmerksamkeit verdient, kann ein Modell eine feste Regel schlagen, weil das unscharfe Probleme mit vielen schwachen Signalen sind. Ob ein Pfad gefahrlos gelöscht werden kann, braucht dagegen Determinismus und eine prüfbare Liste, und beides liefert ein Modell nicht. Fragen Sie einen Anbieter, welchen Pipeline-Schritt sein Modell übernimmt, und verstehen Sie „es entscheidet, was sicher gelöscht werden kann" als Aufforderung, sich die Liste zeigen zu lassen.

Ist es sicher, Claude Code den Mac aufräumen zu lassen?

Das ist die flexibelste Option und zugleich die am wenigsten begrenzte. Die Befehle entstehen live zur Laufzeit und laufen gegen Ihr Home-Verzeichnis, eine Vorschau gibt es nur, wenn Sie ausdrücklich danach fragen. Wenn Sie es trotzdem tun: Lassen Sie den Agenten ein Tool mit Vorschau-Flag steuern, statt selbst rm -rf zusammenzubauen, geben Sie rm in den Berechtigungseinstellungen nie pauschal frei, schicken Sie Entferntes in den Papierkorb, und beschränken Sie ihn jeweils auf ein einziges Verzeichnis.

Löscht ein Mac-Cleaner meine Ollama-Modelle oder meinen Claude-Code-Verlauf?

Das hängt vollständig vom jeweiligen Tool ab, weshalb genau das die erste Frage sein sollte. Mole sperrt ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface, ~/.claude/projects, ~/.codex/sessions und ~/.grok/sessions unabhängig vom Alter am Löschtor, sodass sie nie zum Kandidaten werden. cc-cleaner stuft Modellverzeichnisse und Claude-Code-Transkripte als Moderate-Risiko ein und entfernt sie, wenn Sie --force übergeben. Lesen Sie die Risikostufen eines Tools vor dem ersten Lauf, nicht danach.

Was frisst nach einem Jahr KI-Coding-Tools tatsächlich den Speicherplatz?

Meist alte CLI-Versionen und Transkripte, nicht die Caches, die man erwarten würde. Eine Agenten-CLI mit Selbstupdate kann pro Release mehrere hundert Megabyte zurücklassen, bei Codex kommen fünf angehäufte Releases auf rund 1,2 GB, obwohl nur eines aktiv genutzt wird. Transkripte unter ~/.claude/projects sammeln sich still an und sind das, was einen Scan am wahrscheinlichsten überrascht, weshalb sie in einem Durchgang eher ausgeschlossen als einbezogen gehören.

Weiterführende Links

• Ollama- und LM-Studio-Modelle auf dem Mac aufräumen für die Mechanik inhaltsadressierter Modellspeicher.
• Entwickler-Caches leeren, ohne Builds zu zerstören für Paketmanager-Speicher und verstreute node_modules.
• Aufräumen nach KI-Coding-Tools für die Schritt-für-Schritt-Version, Pfad für Pfad.