AI Mac-opschoners: wat een model wel en niet mag beslissen

"AI Mac-opschoner" wijst naar twee verschillende producten. Het ene is een opschoonapp met ergens een model erin, verkocht op de intelligentie van de aanbevelingen. Het andere is een tool om de schijf terug te winnen die Claude Code, Cursor, Ollama en hun caches het afgelopen jaar stilletjes hebben ingenomen. Het tweede is wat de meeste mensen die die zin in 2026 typen willen. Het eerste is het waard om eerst te beantwoorden, want het antwoord bepaalt hoeveel je alles in de tweede groep vertrouwt.

Deel één: wat het model echt beslist

Een opschoner die AI adverteert doet een bewering over één stap in een pijplijn die er minstens vier heeft:

1. Opsommen. Loop de schijf door en meet die. Werk in de vorm van du, zonder oordeel.
2. Toeschrijven. Beslis welke app of toolchain eigenaar is van elk pad.
3. Rangschikken en uitleggen. Beslis welke twaalf van vierduizend kandidaten een blik verdienen, en zeg in één zin wat elk is.
4. Beslissen en verwijderen. Beslis wat veilig te verwijderen is, en verwijder het daarna.

Stappen 2 en 3 zijn echt vaag, en een model helpt daar echt. Stap 4 is een ander soort probleem, en een model is het verkeerde instrument daarvoor. Bijna elk argument over AI-opschoners is eigenlijk een argument over welke stap de leverancier bedoelt.

Waar een model zijn plek verdient

Toeschrijving is het eerlijke moeilijke geval. Stel dat je ~/Library/Application Support/Foo Labs vindt met 3 GB en geen app met de naam Foo Labs op de schijf. Het bewijs is zwak en verspreid: fragmenten van bundle-identifiers in de eigen plists van de map, een bijpassend voorvoegsel in ~/Library/HTTPStorages, een bundel .savedState onder ~/Library/Saved Application State, een installatiebewijs in /var/db/receipts. Naam-gelijkheid faalt meteen, omdat de leverancier op de ene plek Foo Labs schrijft en op de andere com.foolabs.editor, en een met de hand geschreven catalogus dekt de bovenste paar honderd apps en valt daarna van een klif. Dit is precies de vorm waarin een model een regel verslaat: veel zwakke signalen, geen beslissend signaal, een lange staart die niemand af zal catalogiseren.

Rangschikken heeft dezelfde vorm: een scan die 4.000 paden en 60 GB teruggeeft is een tweede probleem, geen resultaat. Uitleg is nog makkelijker, want ~/Library/Caches/com.apple.nsurlsessiond omzetten in een gewone zin is vertaling. Een tool die een model voor die drie taken gebruikt, en dat zegt, adverteert een echte functie.

Waarom de laatste poort deterministisch moet zijn

De verwijderbeslissing heeft drie eigenschappen die een model niet kan leveren.

Determinisme. Dezelfde schijf, dezelfde versie, hetzelfde antwoord, elke keer. Temperatuur nul koopt dit niet, want de prompt draagt de inhoud van jouw machine: installeer nog één app, de bestandslijst schuift, en de tokens waar de beslissing aan hangt schuiven mee. Een veiligheidsregel die op jouw Mac geldt maar niet op die van je collega is geen veiligheidsregel.

Controleerbaarheid van tevoren. Een beschermingslijst is een verzameling padvoorvoegsels, in een minuut volledig te lezen en te diffen tussen twee releases. Gewichten plus een prompt zijn niet te lezen als een lijst van wat geweigerd wordt, dus niets toont je de grens voordat je die overschrijdt.

Controleerbaarheid achteraf. Wanneer een deterministische regel het verkeerde verwijdert krijg je een reproduceerbare bug: hier is het pad, hier is de regel die het toestond, hier is de test die nu faalt. Doet een model het, dan is het artefact een transcript, de reparatie een prompt-bewerking, en het effect van die bewerking op elk ander geval is ongemeten.

De faalwijzen zijn ook asymmetrisch. Een slechte rangschikking kost een scroll. Een slechte verwijdering van ~/.claude/projects kost elk transcript dat je hebt. Het kader is dus niet "AI goed, AI slecht". Het is een splitsing midden door de pijplijn: probabilistisch waar ernaast zitten aandacht kost, deterministisch waar ernaast zitten gegevens kost.

Aan welke kant Mole staat

Mole levert geen model en draait geen inferentie. Bij gewoon Opschonen wordt of een pad een verwijder-kandidaat kan worden beslist door een vaste reeks geblokkeerde relatieve voorvoegsels die in de app is gecompileerd, met vermeldingen als .ollama/models, .lmstudio/models, .cache/huggingface, .cache/torch, .claude/projects, .codex/sessions, .grok/sessions en Library/Caches/com.apple.e5rt.e5bundlecache. De helft die jij kunt bewerken is een gewoon tekstbestand dat je kunt lezen met cat ~/.config/mole/whitelist. De gratis Mole CLI is open source onder GPL-3.0. Die deelt de door de gebruiker bewerkbare whitelist met de app maar heeft eigen ingebouwde controles, die je kunt inspecteren.

Die laatste vermelding is het argument in het klein. com.apple.e5rt.e5bundlecache staat in ~/Library/Caches en het woord in de naam is "cache", dus elke heuristiek ter wereld deelt die in als wegwerpbaar. Die bevat gecompileerde modellen van de Apple Neural Engine, en die wissen terwijl een app modellen geladen heeft breekt herkenningsaanroepen tot de machine herstart. Die is beschermd omdat iemand die fout raakte en de regel schreef.

De praktische test voor elke tool hier is dus één vraag: welke van de vier stappen voert het model uit? Opsommen, toeschrijven, rangschikken en uitleggen zijn geloofwaardige antwoorden. "Het beslist wat veilig te verwijderen is" is een antwoord om op te volgen door de lijst te vragen, en als er geen lijst is, is er niets te controleren.

De meeste van deze grenzen zijn niet op een whiteboard bedacht. Iemand liep erop op de eigen Mac, en de regel kwam later. Toen dit artikel werd geschreven had de GitHub-repository van Mole CLI 145 bijdragers en 987 issues, waarvan 984 gesloten en 3 nog open. Dat gesloten aantal is alleen de volgstaat van GitHub, geen bewering dat 984 bugs zijn gerepareerd, maar het laat een lang spoor achter van waar het probleem vandaan kwam, waarom de regel veranderde en wat hetzelfde geval de volgende keer moet blokkeren.

Die getallen bewijzen niet dat elke Mac is getest. macOS en de apps blijven veranderen hoe ze gegevens opslaan, en geen enkele machine kan voor elke andere machine staan. Wat ze laten zien is dat de opruimgrens van Mole voortdurend wordt uitgedaagd op echte computers, verfijnd en terug in tests gezet, in plaats van te rusten op een belofte om "voorzichtig te zijn".

Mole CLI en Mole voor Mac zijn niet hetzelfde verwijderprogramma. Het opdrachtregelgereedschap is gratis en open source, voor mensen die een --dry-run willen lezen en de scope zelf willen beslissen. De Mac-app heeft een eigen scanner en verwijderketen, met een kandidatenset die hetzelfde of smaller is. Mappen als node_modules, Pods en venv hebben een netwerk-verbinding en de juiste afhankelijkheden nodig om opnieuw te bouwen. Ze zijn beschikbaar voor een terminalgebruiker om te inspecteren, maar Mole voor Mac zet ze niet in een gewone opruimlijst.

De regels beginnen te werken voordat een kandidatenlijst het scherm bereikt. Systeemmappen, sleutelhangers, Mail, Berichten, foto's, inhoud van cloudschijven, privacyrechten, inlogonderdelen en achtergrondtaken worden geen kandidaten omdat ze groot zijn of toevallig onder een map met de naam Cache staan. Bij gewoon Opschonen geldt hetzelfde voor transcripten van Claude, Codex en andere AI-tools, plannen, herinneringen en lokale modellen. Mole wijst alleen beoordeelde cachebladeren aan, niet een hele map voor applicatieondersteuning. Kan die niet uitleggen wat een map bevat, dan is de standaard die met rust laten.

De laatste stap is waar het verschil telt. Een pad dat tijdens een scan veilig leek kan minuten later onveilig zijn: een app kan zijn gestart, een build kan zijn begonnen, of een symbolische koppeling kan ergens anders naartoe hebben geleid. Vóór verwijdering controleert Mole het oorspronkelijke pad, beschermde locaties, de gebruikerswhitelist en de identiteit van het object opnieuw. Die controleert ook dat de app of buildtool die eigenaar is die niet gebruikt. Onzekerheid levert een overslaan op, geen groter getal voor "opgeschoond".

Je kunt het gevolg van elke keuze nog zien. De controlelijst draagt een pad, een eigenaar en een grootte. Een onzeker item kan ongeselecteerd blijven of worden gemarkeerd als Schoon dit nooit op. App-verwijderingen gaan naar de prullenmand. Caches verwijderen standaard direct om ruimte terug te winnen, maar kunnen zo worden ingesteld dat ze naar de prullenmand gaan. Het resultaat scheidt opgeschoonde, in de prullenmand gezette, overgeslagen en mislukte items, en een lokaal log legt vast wat er echt gebeurde.

AI kan een map omzetten in een uitleg in gewone taal en helpen een onbekende toolchain te traceren. Mole doet de andere helft: die aanwijzingen omzetten in een verwijderregel die niet verdwijnt omdat één antwoord, één dubbelzinnige mapnaam of één andere Mac verandert. Die probeert niet alles te verwijderen wat wegwerpbaar zou kunnen zijn. Die probeert elke verwijdering uitlegbaar te maken, en het item te houden wanneer die niet zeker kan zijn.

Deel twee: tools om op te ruimen na AI-tools

Voor opruimen na AI-tools splitst de voetafdruk in vier soorten gegevens met vier verschillende regels, en die door elkaar halen is waar ongelukken gebeuren:

• Toolcaches en logs. ~/Library/Caches/claude-cli-nodejs, Electron-caches van Cursor, telemetrie en debugmappen onder ~/.claude. Opnieuw te maken en saai.
• Transcripten en projectstaat. ~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions. Vaak de grootste verrassing in een scan, en onvervangbaar.
• Oude CLI-versies. Agent-CLI's die zichzelf bijwerken kunnen eerdere releases achterlaten. Als voorbeeld, als elke kopie ongeveer 300 MB inneemt en je bevestigt dat maar één van de vijf nog nodig is, dan zijn de andere vier ongeveer 1,2 GB. Controleer launchers, draaiende processen en vastgezette versies voordat je beslist welke kopieën weggaan.
• Modelgewichten. ~/.ollama/models, ~/.cache/huggingface/hub, de modelmap van LM Studio. Veruit de grootste, in eigendom van de tool die ze downloadde.

Meet voordat je een tool kiest:

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

Mole, voor een beoordeelde veeg die deze paden al kent

Het gereedschap Opschonen scant eerst en toont een resultaat dat je bekijkt voordat er iets beweegt. Elke kandidatenrij draagt het exacte pad, de eigenaar en de grootte, en alles waar de scanner niet zeker over is komt uitgevinkt binnen zodat de standaardklik de kleinere actie is. App-verwijderingen gaan naar de prullenmand. Caches verwijderen standaard direct om ruimte terug te winnen, maar kunnen zo worden ingesteld dat ze naar de prullenmand gaan. Opruimacties worden lokaal vastgelegd in ~/Library/Logs/mole/operations.log. Het log onderscheidt verplaatsingen naar de prullenmand van definitieve verwijdering.

Twee gedragingen tellen specifiek voor AI-tooling. Oude versiemappen van agent-CLI's worden aangeboden na controle van het launcherdoel, niet alleen door versienummers te vergelijken. Dat doel wijst één actief pad aan. Controleer vóór het verwijderen van andere kopieën op draaiende processen, updates en vastgezette installaties die ze nog nodig hebben. Bewaar alles wat onzeker is. Verwijderen controleert eigendom in plaats van alleen op namen te matchen, zodat het verwijderen van één app van een leverancier niet de gedeelde bovenliggende map Application Support aanbiedt die een nog geïnstalleerde zusterapp bezit.

Om de taak te draaien: open Opschonen, laat de scan afmaken, vouw de groepen open die groot lijken, vink uit wat je wilt houden, schoon daarna op en controleer de vrijgekomen ruimte. Scannen is gratis en elk betaald gereedschap draait twee keer gratis, dus de hele controle is te verifiëren voordat je beslist of $19 het waard is.

De Mole CLI, wanneer je liever in de terminal blijft

Een apart gratis product, open source onder GPL-3.0, geïnstalleerd met brew install mole. Bekijk eerst, altijd:

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

mo clean behandelt caches en logs, mo purge richt zich op oude buildartefacten van projecten, en clean, uninstall en optimize ondersteunen --dry-run zodat je hun acties kunt bekijken. Die deelt de gebruikerswhitelist en de locatie van het bewerkingslog met de Mac-app. Eén verschil voordat je de vlag weglaat: cache opruimen via de CLI verwijdert bestanden definitief, terwijl verwijderen en het wegnemen van resten nog naar de prullenmand gaan.

cc-cleaner, de open source terminaloptie die voor dit probleem is gebouwd

cc-cleaner heeft een MIT-licentie, Python 3.10 en later, te installeren met pipx install cc-cleaner. Die levert 22 opschoners inclusief Claude Code, npm, uv, cargo, Docker, Playwright, browsercaches, en een groep AI/ML-modellen die Hugging Face, PyTorch, Whisper en Ollama dekt. cc-cleaner status drukt een groottetabel af, cc-cleaner clean opent een interactieve kiezer, -n is een dry run.

Het risicomodel is expliciet: Safe-items worden standaard opgeschoond terwijl Moderate- en Dangerous-items --force vragen, en de README zet "conversation transcripts, shared stores" in de laag Moderate. De bron vertelt de rest. De Ollama-opschoner verwijdert het geheel van ~/.ollama/models als één map, de Hugging Face-opschoner doet hetzelfde met ~/.cache/huggingface/hub en datasets, en de Claude-opschoner biedt de transcripten *.jsonl onder ~/.claude/projects aan. Verwijderen is shutil.rmtree en Path.unlink, dus niets komt in de prullenmand. De veiligheidslaag is een bevroren set verboden systeempaden plus de eis dat elk doel onder je thuismap staat: een deterministische lijst die een mens schreef, precies zoals het hoort. Het verschil is waar de lijn ligt, niet de strengheid. cc-cleaner zet modelstores en transcripten achter een vlag. Gewoon Opschonen in Mole weigert ze.

DevCleaner, als je een menubalkapp wilt voor hetzelfde terrein

DevCleaner is een menubalkhulpprogramma voor macOS 14 en nieuwer, nu 1.9.0, dat 23 ecosystemen dekt van Xcode DerivedData en Gradle tot npm en Docker, met eigen scanners voor Claude, ChatGPT, Cursor, Ollama en LM Studio. Safe-items worden standaard verwijderd, Warning-items zijn "jouw keuze", Danger-items zijn nooit vooraf geselecteerd, en die houdt een harde weigerlijst voor inloggegevens en sessiebestanden plus een waarschuwing voordat die de caches van een draaiende app aanraakt. De kernopschoning is gratis en Pro wordt verkocht als eenmalige aankoop of een jaarlijks abonnement. Controleer de huidige getallen op de pagina van de leverancier. De site zegt niet of verwijderingen naar de prullenmand gaan, en dat is wat je vóór een eerste run wilt vragen.

MacPaw levert ook een CleanMyMac CLI als publieke bèta, via een Homebrew-cask, gericht op dezelfde artefacten. Die is propriëtair, de repository is een issuetracker in plaats van bron, en het gedrag verandert expliciet nog, dus lees wat de bevestigingsstap je toont in plaats van een gepubliceerde beschrijving.

Een agent op je eigen schijf richten

De laatste route is opruimtools overslaan en Claude Code of een vergelijkbare agent vragen de schijf direct op te schonen, eventueel via een van de gepubliceerde opruimskills. Het voordeel is echt en niets anders hier heeft het: een agent kan redeneren over een indeling die niemand heeft gecatalogiseerd, of dat nu een framework is dat vorige maand uitkwam, een privé-toolchain, of een thuis-map die alleen jij zo indeelt.

De beoordeling moet even rechttoe zijn. De shellopdrachten worden gegenereerd op het moment van inferentie tegen je echte bestandssysteem, dus wat draait is door niemand beoordeeld voordat het draaide. Er is geen dry run tenzij je die eist. De explosieradius is je thuismap, en rm -rf samengesteld uit een variabele die leeg bleek is een faalwijze met een lange geschiedenis. Deel één geldt met het vangnet weg: de beslissing is probabilistisch en rechtstreeks aan de laatste poort gekoppeld.

Vier vangrails kosten bijna niets:

• Laat die een tool met een voorbeeldsvlag aansturen in plaats van zelf verwijderingen samen te stellen. Eén publieke skill voor Claude Code wikkelt de CLI mo en maakt mo clean --dry-run verplicht vóór mo clean, drukt de volledige dry-run-uitvoer af, en vraagt een getypte bevestiging. De agent kiest het doel, een deterministische tool voert de verwijdering uit.
• Keur rm nooit vooraf goed in je rechteninstellingen. Keur elke verwijderopdracht apart goed, en lees het pad in plaats van de samenvatting ervan.
• Maak de prullenmand de standaard. Gebruik de Finder of een tool die de prullenmand kent, zoals trash van Homebrew. Bestanden die nog in de prullenmand staan zijn meestal terug te zetten, maar dit is geen back-up. Een gewone mv naar ~/.Trash is niet gelijkwaardig: naambotsingen kunnen bestanden overschrijven.
• Begrens de werkset. Wijs die op één map, en vraag du -sh ervoor en df -h erna zodat de geclaimde teruggave wordt gemeten in plaats van geschat.

Modelstores horen bij de tool die ze downloadde

Geen algemene opschoner hoort hier je instrument te zijn, ook de bovenstaande niet. Ollama en Hugging Face houden allebei content-addressed stores bij waarin modellen blobs delen, dus alleen de tool die eigenaar is weet welke blob nog wordt gebruikt. Gebruik ollama ls en ollama rm <model>, en hf cache ls met hf cache rm model/<repo> --dry-run. Waarom blobbestanden met de hand verwijderen een model wees maakt staat in resten van AI-tools verwijderen.

Hoe ze zich verhouden

De grens, rechttoe

Mole is geen reactie op malware, geen back-up, en geen vervanging voor een uninstaller van de leverancier bij software die stuurprogramma's, VPN-onderdelen of systeemextensies meelevert. Die verwijdert geen modelgewichten, en AI-chatgeschiedenis vertrekt alleen via AI-opschoning en -onderhoud, één aangevinkte sessie tegelijk, dus als je probleem van 200 GB helemaal een modelbibliotheek is, toont Analyse je de vorm van die bibliotheek en geeft de taak aan Ollama of LM Studio. Ollama-modellen die een maand ongebruikt zijn, zijn de uitzondering: AI-opschoning en -onderhoud toont ze en verwijdert de modellen die je aanvinkt met ollama rm. Dat is een bewuste grens, geen gat om later te dichten.

Er één kiezen

200 GB aan builduitvoer en een dozijn toolchains. Het volume zit in caches, oude node_modules, DerivedData en Docker, niet in iets dat specifiek voor AI is. Begin met een beoordeelde veeg of mo clean --dry-run, en werk daarna door ontwikkelaarscaches wissen voor de stores die hun eigen snoeiopdracht nodig hebben. cc-cleaner is een goede tweede ronde als je eerst de risicolagen leest.

Een grote lokale modelbibliotheek. Sla algemene opschoners voor de gewichten helemaal over. ollama ls, hf cache ls en de weergave My Models van LM Studio zijn de enige tools die een gedeelde blob veilig kunnen vrijmaken. Gebruik een schijfkaart om de store te vinden en de tool die eigenaar is om die te wijzigen.

Je merkte net dat Cursor of Claude Code schijf opeet. Begin met wegwerpbare caches en logs te scheiden van transcripten en projectstaat. Oudere CLI-versies zijn alleen kandidaten na controle van launchers, draaiende processen, updates en vastgezette versies. Bewaar transcripten en alles wat je niet kunt aanwijzen. De stap-voor-stapcontrole staat in opruimen na AI-codingtools.

Veelgestelde vragen

Verwijdert een Mac-opschoner met AI veiliger dan een gewone?

Niet op het beschikbare bewijs. Een model kan een regel verslaan bij het beslissen welke app eigenaar is van een weesmap en bij het rangschikken van wat aandacht verdient, omdat dat vage problemen zijn met veel zwakke signalen. Beslissen of een pad veilig te verwijderen is vraagt determinisme en een controleerbare lijst, en een model levert geen van beide. Vraag een leverancier welke pijplijnstap hun model draait, en behandel "het beslist wat veilig te verwijderen is" als een aanleiding om de lijst te zien.

Is het veilig om Claude Code mijn Mac te laten opschonen?

Het is de meest flexibele optie en de minst begrensde. De opdrachten worden gegenereerd op het moment van inferentie en draaien tegen je thuismap, zonder voorbeeld tenzij je erom vraagt. Doe je het, laat de agent dan een tool aansturen die een dry-run-vlag heeft in plaats van zelf rm -rf samen te stellen, keur rm nooit vooraf goed in je rechteninstellingen, stuur verwijderingen naar de prullenmand, en beperk die tot één map tegelijk.

Verwijdert een Mac-opschoner mijn Ollama-modellen of mijn Claude Code-geschiedenis?

Het hangt helemaal van de tool af, en daarom is dit de vraag om eerst te stellen. Gewoon Opschonen van Mole blokkeert ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface, ~/.claude/projects, ~/.codex/sessions en ~/.grok/sessions bij de verwijderpoort op elke leeftijd, dus ze worden nooit kandidaten. cc-cleaner deelt modelmappen en transcripten van Claude Code in als matig risico en verwijdert ze als je --force meegeeft. Lees de risicolagen van een tool vóór de eerste run en niet erna. De ene bewuste uitzondering is de pagina AI-opschoning en -onderhoud van Mole, die Codex-sessies voorbij een venster dat je kiest kan tonen en Claude Code-sessies waarvan het project weg is, uitgevinkt, zodat je ze één voor één bevestigt.

Wat neemt de ruimte echt in na een jaar AI-codingtools?

Controleer oude CLI-versies en transcripten naast caches. Bijvoorbeeld, als elke versie ongeveer 300 MB is en maar één van de vijf nog nodig is, zijn de andere vier samen ongeveer 1,2 GB. Dat is een illustratie, geen meting van jouw Mac. Transcripten onder ~/.claude/projects kunnen ook in de tijd groeien, maar anders dan caches kunnen ze onvervangbaar werk bevatten, dus sluit ze uit van een opruimveeg.

Verder lezen

• Ollama- en LM Studio-modellen op de Mac opruimen voor de werking van content-addressed modelstores.
• Ontwikkelaarscaches wissen zonder builds te breken voor stores van pakketbeheerders en verspreide node_modules.
• Opruimen na AI-codingtools voor de versie stap voor stap, pad voor pad.