256GB Mac voll? Diese KI-Skill räumt nachts 135GB frei – ohne 1500€ für mehr Speicher

256GB Mac voll? Diese KI-Skill räumt nachts 135GB frei – ohne 1500€ für mehr Speicher
RichardsonDas Problem: Wie „Systemdaten” auf 256GB Macs auf 100GB anschwellen
Jeder Mac-Veteran kennt den Albtraum: die grauen „Systemdaten” in „Über diesen Mac”, die locker 50, 100GB fressen, ohne dass man weiß, was drin steckt. Beim 256GB MacBook Air ist es am schlimmsten – das System frisst die Hälfte, ein paar DevTools später passt nicht mal mehr eine neue Xcode-Version drauf, ohne vorher irgendwas zu löschen.
Der Cache versteckt sich an drei Stellen: Feishu, Chrome, Terminal-Toolchain. Feishus LarkShell/aha-Verzeichnis cached jedes Dokument, das du je geöffnet hast – einer hat laut Projektreadme 42GB angehäuft. Chrome Service Worker plus Debug-Daten blähen sich auf über 50GB auf (Eigenmessung). Der ~/.cache/uv von Python-Entwicklern frisst still 56GB (Eigenmessung). Dazu kommen Telegram-Mediacache, npm-Cache, Homebrew-Downloads – nach ein, zwei Jahren Entwicklermaschine sind 100GB Cache normal.
Das Problem: die Hälfte ist Müll, die Hälfte ist State. Feishu-Dokumentcache löschen – kein Ding. Aber die Login-State-Datei im selben Ordner löschen heißt QR-Code neu scannen. Chrome Service Worker darf weg, aber der IndexedDB daneben enthält deine PWA-Daten. Klassische Cleaner listen nur „welche Ordner sind groß”, beurteilen aber nicht „welche darf man löschen”.
Und dann der Schmerz bei der Lösung: Apples SSD ist aufs Logic Board gelötet. Von 256GB auf 512GB kostet offiziell 1500€, eine Stufe höher meist vierstellig. Dieses Geld muss nicht sein.
Die Chance: „Löschbar oder nicht?” an die KI auslagern
Disk Raccoon (硬盘小浣熊) ist ein Open-Source-Projekt mit einem simplen Kerngedanken: Eine strukturierte Cache-Map sagt der KI, was sie anfassen darf und was nicht. Kein weiteres Cleaner-Tool – eine Skill für Claude Code, Cola und andere KI-Programmierassistenten. Eine Art Plug-in für deinen Agent: sag ihm „schau mal den Cache an”, er legt los.
GitHub: https://github.com/orange2ai/disk-raccoon, MIT-Lizenz, aktuell 11 Stars (laut Quellpost, nicht unabhängig verifiziert), letzter Commit Ende August 2026 (laut Quellpost, nicht unabhängig verifiziert). Die offizielle Beschreibung ist direkt: „macOS Cache-Cleanup-Agent: erst waschen, dann fressen. Cache-Map + drei Sicherheitsstufen, löscht nur was sichergelt. Erster Real-Test: 135GB in einer Nacht.”
„Erst waschen, dann fressen” – das kommt vom Waschbär, dem einzigen Tier, das sein Futter vor dem Essen wäscht. Er frisst nicht blind, er frisst nicht nichts. Genau das ist der macOS-Cleanup-Kernkonflikt: groß heißt nicht löschbar, löschbar heißt nicht groß. Klassische Tools lösen nur den ersten Teil. Raccoon löst den zweiten.
Nebenbei: KI-Skills installieren können ist本身 schon eine Auftragsfähigkeit – 30€ pro Rechner aufräumen, Werkzeug steht, Marge ist deine.
Der Weg: Drei Sicherheitsstufen plus Cache-Map
Disk Raccoon arbeitet in drei Schritten, jeder mit klarer Sicherheitsschranke.
Schritt 1: Erst Mole scannen lassen, große Ordner finden
Mole ist ein weiteres Open-Source-Tool, spezialisiert auf große Ordner – quasi die „Augen” des Raccoon. Ohne Mole weiß der Agent nicht, wo er hingucken soll. Mole listet, welche Ordner 10, 20, 50GB fressen – der „Gesundheitscheck” zeigt dem Agent, wo er suchen muss. Ohne Mole läuft’s auch, nur blind und langsamer.
Schritt 2: KI prüft anhand der Cache-Map jeden Eintrag
Raccoon liefert eine references/cache-map.md mit, jeder Cache-Pfad hat eine Sicherheitsstufe. So sehen echte Einträge aus:
1 | ## ~/.cache/uv |
Was, wenn ein Pfad nicht in der Map steht? Raccoons Regel: „erst rausfinden, dann reden, im Zweifel Finger weg”. Der Agent recherchiert, welchem App der Ordner gehört, was drin liegt, was beim Löschen passiert – und legt dir die Liste zur Freigabe vor.
Schritt 3: Standard read-only, sudo bleibt bei dir
Sicherheitsdesign mit harten Regeln:
- Standard read-only: erste Runde nur gucken, nichts löschen, erst Report.
- Wiederherstellbar bevorzugt: was in den Papierkorb kann, geht nicht direkt in
rm -rf. - Erst App beenden, dann löschen: keine laufenden Prozesse, sonst wird parallel neu geschrieben.
- sudo gehört dir: System-Level-Löschungen werden nur als Befehl generiert, ausführen tust du selbst.
Warum ist read-only mehr wert als One-Click-Cleanup? Einmal versehentlich Chatverlauf oder Projektabhängigkeiten gelöscht – die Wiederherstellung kostet mehr als die 50GB Zeitersparnis je Clean. CleanMyMacs „Scannen + Aufräumen”-Design schiebt die Entscheidungslast zum User – traust du dich, „Alles aufräumen” zu klicken? Die meisten nicht. Raccoon verlagert die Beurteilung in die KI, du nickst am Ende nur ab oder schüttelst den Kopf. Entscheidungskosten auf Minimum.
Der Case: Wie die 135GB zustande kamen
Aus dem öffentlichen Real-Test des Quellpost-Autors – die drei größten Brocken beim ersten Lauf:
| Cache-Quelle | Freigegeben |
|---|---|
~/.cache/uv (Python-Paketcache) |
~56GB |
| Chrome Service Worker + ChromeDebug | ~51GB |
Feishu LarkShell/aha Dokumentcache |
~38GB |
| Gesamt | 135+ GB |
Die 135GB umgerechnet in Apples offiziellen Upgrade-Preis: ein komplettes 512GB-MacBook-Upgrade gespart – 1500€. Bei 100GB pro Cleanup sind das 1100€ Wert pro Lauf. Der Case deckt die drei häufigsten „Festplatten-Killer” ab: Dev-Toolchain (uv), Browser (Chrome), Office-Software (Feishu). Python-Entwickler plus Feishu plus Chrome-Poweruser – das ist Standard-Setup in der Dev-Szene. Hast du diese Kombi, schlummern bei dir vermutlich ähnliche 100GB+ Cache – ein Lauf, gleiche Größenordnung.
Warum klassische Cleaner das nicht lösen
Am Markt mangelt es nicht an Mac-Cleanern: CleanMyMac, DaisyDisk, OmniDiskSweeper – alles alte Hasen. Aber sie haben einen gemeinsamen blinden Fleck: sie sagen dir nur „was ist groß”, nicht „was darf weg”.
Feishu-Beispiel: LarkShell/aha ist im Finder quasi unsichtbar, tief in Library vergraben. CleanMyMac markiert den Ordner gelb, aber drin sind nur kryptische Unterordner – da löscht niemand was. Chrome ist noch komplexer: Service Worker, IndexedDB, Cache Storage, Cookies – unterschiedliche Mechanismen, einer falsch gelöscht, PWA-Offline-Daten weg.
Raccoons Lösung: KI macht „semantische Beurteilung”. Bei 50GB Chrome-Verzeichnis unterscheidet der Agent, was Service Worker ist (löschbar), was IndexedDB ist (nach Bedarf), was Login-State ist (Finger weg). CleanMyMac markiert 50GB Feishu-Cache nur gelb ohne Erklärung, Raccoon sagt dir direkt: 30GB davon löschbar, 20GB sind Login-State. Deshalb löst CleanMyMac das Problem nicht, obwohl 40$/Jahr kostet – eine Regel-Engine versteht keine Pfad-Semantik. Erst LLMs geben einem Cleanup-Tool Lesefähigkeit.
Call-to-Action: Heute Nacht deinem Agent den Waschbär verpassen
Mac, Festplatte ständig am Limit, keine 1500€ für Upgrade übrig? Dann drei Schritte:
Schritt 1: Skill installieren
1 | git clone https://github.com/orange2ai/disk-raccoon ~/.claude/skills/disk-raccoon |
Alle Agents mit SKILL.md-Protokoll funktionieren – Claude Code, Cola, beide.
Schritt 2: Mole als Gesundheitscheck dazuholen
Erst Mole laufen lassen, große Ordner finden, dann Raccoon die Beurteilung machen lassen. Einer scannt, einer entscheidet – klare Aufteilung.
Schritt 3: Mit dem Agent reden
Keine komplizierten Befehle merken. Einfach „schau mal den Cache an” oder „Festplatte voll, was können wir löschen?” sagen. Der Agent arbeitet die Cache-Map durch und legt dir die Liste vor. Nicken = löschen, Kopfschütteln = überspringen.
Die Cache-Map lebt – der Projektautor ruft im README dazu auf, neue Cache-Pfade per Issue oder PR beizusteuern. Pfad, Größe, zugehöriges App reichen. Einmal aufgeräumt, hilfst du vielleicht dem nächsten User, seine 1500€ zu sparen.






