Limpadores de Mac com IA: o que um modelo deve e não deve decidir

"Limpador de Mac com IA" resolve em dois produtos diferentes. Um é um app de limpeza com um modelo em algum lugar dentro, vendido pela inteligência das recomendações. O outro é uma ferramenta para recuperar o disco que Claude Code, Cursor, Ollama e os caches deles tomaram em silêncio no último ano. O segundo é o que a maioria das pessoas que digita essa frase em 2026 quer. O primeiro vale ser respondido primeiro, porque a resposta decide o quanto confiar em qualquer coisa do segundo grupo.

Parte um: o que o modelo está realmente decidindo

Um limpador que anuncia IA está fazendo uma afirmação sobre um passo de um pipeline que tem pelo menos quatro:

1. Enumerar. Percorrer o disco e medi-lo. Trabalho no formato do du, sem julgamento.
2. Atribuir. Decidir qual app ou cadeia de ferramentas é dono de cada caminho.
3. Ordenar e explicar. Decidir quais doze de quatro mil candidatos merecem um olhar, e dizer numa frase o que cada um é.
4. Decidir e apagar. Decidir o que é seguro remover e depois remover.

Os passos 2 e 3 são genuinamente nebulosos, e um modelo ajuda de verdade ali. O passo 4 é um problema de outro tipo, e um modelo é o instrumento errado para ele. Quase toda discussão sobre limpadores com IA é, na verdade, uma discussão sobre qual passo o fornecedor quer dizer.

Onde um modelo ganha o lugar

A atribuição é o caso difícil honesto. Suponha que você encontre ~/Library/Application Support/Foo Labs com 3 GB e nenhum app chamado Foo Labs no disco. A evidência é fraca e espalhada: fragmentos de identificador de bundle nos próprios plists da pasta, um prefixo correspondente em ~/Library/HTTPStorages, um pacote .savedState em ~/Library/Saved Application State, um recibo de instalação em /var/db/receipts. A igualdade de nome falha na hora, porque o fornecedor escreve Foo Labs num lugar e com.foolabs.editor em outro, e um catálogo escrito à mão cobre as primeiras centenas de apps e depois cai num precipício. Esta é exatamente a forma em que um modelo vence uma regra: muitos sinais fracos, nenhum decisivo, uma cauda longa que ninguém vai terminar de catalogar.

Ordenar tem a mesma forma: uma análise que devolve 4.000 caminhos e 60 GB é um segundo problema, não um resultado. Explicar é mais fácil ainda, já que transformar ~/Library/Caches/com.apple.nsurlsessiond numa frase clara é tradução. Uma ferramenta que usa um modelo para esses três trabalhos, e diz isso, anuncia um recurso real.

Por que o último portão tem de ser determinístico

A decisão de apagar precisa de três propriedades que um modelo não consegue fornecer.

Determinismo. O mesmo disco, a mesma versão, a mesma resposta, toda vez. Temperatura zero não compra isso, porque o prompt carrega o conteúdo da sua máquina: instale mais um app, a listagem de arquivos se desloca, e os tokens de que a decisão depende se deslocam com ela. Uma regra de segurança que vale no seu Mac mas não no do colega não é uma regra de segurança.

Auditabilidade antes do fato. Uma lista de proteção é um conjunto de prefixos de caminho, legível por completo num minuto e comparável entre duas versões. Pesos mais um prompt não podem ser lidos como uma lista do que será recusado, então nada mostra o limite antes de você cruzá-lo.

Auditabilidade depois do fato. Quando uma regra determinística apaga a coisa errada, você tem um bug reproduzível: aqui está o caminho, aqui está a linha que permitiu, aqui está o teste que agora falha. Quando um modelo faz isso, o artefato é uma transcrição, a correção é uma edição de prompt, e o efeito dessa edição em todos os outros casos não foi medido.

Os modos de falha também são assimétricos. Uma ordenação ruim custa uma rolagem; um apagamento ruim de ~/.claude/projects custa toda transcrição que você tem. Então o quadro não é "IA boa, IA ruim"; é uma divisão no meio do pipeline: probabilístico onde errar custa atenção, determinístico onde errar custa dados.

De que lado o Mole está

O Mole não traz modelo e não roda inferência. Na limpeza comum, se um caminho pode virar candidato à exclusão é decidido por um array fixo de prefixos relativos bloqueados, compilado no app, com entradas como .ollama/models, .lmstudio/models, .cache/huggingface, .cache/torch, .claude/projects, .codex/sessions, .grok/sessions e Library/Caches/com.apple.e5rt.e5bundlecache. A metade editável pelo usuário é um arquivo de texto que você pode ler com cat ~/.config/mole/whitelist. O Mole CLI gratuito é de código aberto sob GPL-3.0. Ele compartilha a lista de proteção editável pelo usuário com o app, mas tem as próprias conferências embutidas, que você pode inspecionar.

Essa última entrada é o argumento em miniatura. com.apple.e5rt.e5bundlecache fica em ~/Library/Caches e a palavra no nome é "cache", então toda heurística do mundo o classifica como descartável. Ele guarda modelos compilados do Apple Neural Engine, e limpá-lo enquanto um app tem modelos carregados quebra chamadas de reconhecimento até a máquina reiniciar. Está protegido porque uma pessoa bateu nessa falha e escreveu a linha.

Então o teste prático para qualquer ferramenta aqui é uma pergunta: quais dos quatro passos o modelo executa? Enumeração, atribuição, ordenação e explicação são respostas críveis. "Ele decide o que é seguro apagar" é uma resposta a ser seguida do pedido para ver a lista, e se não há lista não há o que revisar.

A maioria desses limites não foi pensada num quadro branco. Alguém esbarrou neles no próprio Mac, e a regra veio depois. Quando este artigo foi escrito, o repositório do Mole CLI no GitHub tinha 145 colaboradores e 987 issues, com 984 fechadas e 3 ainda abertas. Essa contagem de fechadas é só o estado de rastreamento do GitHub, não uma afirmação de que 984 bugs foram corrigidos, mas deixa um rastro longo de onde o problema veio, por que a regra mudou e o que deveria bloquear o mesmo caso da próxima vez.

Esses números não provam que todo Mac foi testado. O macOS e os apps dele continuam mudando a forma de guardar dados, e nenhuma máquina pode representar todas as outras. O que eles mostram é que o limite de limpeza do Mole é continuamente desafiado em computadores reais, refinado e colocado de volta em testes, em vez de descansar numa promessa de "ter cuidado".

O Mole CLI e o Mole para Mac não são o mesmo programa de exclusão. A ferramenta de linha de comando é grátis e de código aberto, para quem aceita ler um --dry-run e decidir o escopo por conta própria. O app para Mac tem o próprio scanner e a própria cadeia de exclusão, com um conjunto de candidatos que é o mesmo ou mais estreito. Diretórios como node_modules, Pods e venv precisam de uma conexão de rede e das dependências certas para reconstruir. Eles ficam disponíveis para um usuário de terminal inspecionar, mas o Mole para Mac não os coloca numa lista comum de limpeza.

As regras começam a funcionar antes de uma lista de candidatos chegar à tela. Diretórios do sistema, chaves, Mail, Mensagens, fotos, conteúdo de disco na nuvem, permissões de privacidade, itens de login e tarefas em segundo plano não viram candidatos porque são grandes ou por acaso ficam sob um diretório chamado Cache. Na limpeza comum, o mesmo vale para transcrições do Claude, do Codex e de outras ferramentas de IA, planos, memórias e modelos locais. O Mole identifica só folhas de cache já examinadas, não um diretório inteiro de suporte de aplicativo. Se não consegue explicar o que um diretório contém, o padrão é deixá-lo em paz.

O último passo é onde a diferença importa. Um caminho que parecia seguro durante uma análise pode estar inseguro minutos depois: um app pode ter aberto, um build pode ter começado, ou um link simbólico pode ter levado a outro lugar. Antes da exclusão, o Mole confere de novo o caminho original, os locais protegidos, a lista do usuário e a identidade do objeto. Também verifica que o app dono ou a ferramenta de build não está usando o item. Incerteza produz um ignorado, não um número maior de "limpo".

Você ainda pode ver a consequência de cada escolha. A lista de revisão traz caminho, dono e tamanho. Um item incerto pode ficar desmarcado ou ser marcado como Nunca limpar. Desinstalações de apps vão para o Lixo; caches apagam direto por padrão para recuperar espaço, mas podem ser configurados para ir ao Lixo. O resultado separa itens limpos, enviados ao Lixo, ignorados e com falha, e um log local registra o que realmente aconteceu.

A IA pode transformar um diretório numa explicação em linguagem clara e ajudar a rastrear uma cadeia de ferramentas desconhecida. O Mole trata a outra metade: transformar essas pistas numa regra de exclusão que não desaparece porque uma resposta, um nome ambíguo de diretório ou um Mac diferente muda. Ele não tenta apagar tudo que talvez seja descartável. Tenta tornar cada exclusão explicável, e manter o item quando não pode ter certeza.

Parte dois: ferramentas para limpar depois das ferramentas de IA

Para limpar depois das ferramentas de IA, a pegada se divide em quatro tipos de dados com quatro regras diferentes, e confundi-los é onde acontecem os acidentes:

• Caches e logs de ferramentas. ~/Library/Caches/claude-cli-nodejs, caches Electron do Cursor, telemetria e diretórios de depuração em ~/.claude. Regeneráveis e sem graça.
• Transcrições e estado de projeto. ~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions. Muitas vezes a maior surpresa de uma análise, e insubstituíveis.
• Versões antigas de CLI. CLIs de agente que se atualizam sozinhos podem deixar versões anteriores para trás. Como exemplo, se cada cópia ocupa cerca de 300 MB e você confirma que só uma de cinco ainda é necessária, as outras quatro somam cerca de 1,2 GB. Confira lançadores, processos em execução e versões fixadas antes de decidir quais cópias remover.
• Pesos de modelo. ~/.ollama/models, ~/.cache/huggingface/hub, o diretório de modelos do LM Studio. De longe os maiores, pertencentes à ferramenta que os baixou.

Meça antes de escolher uma ferramenta:

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

Mole, para uma varredura revisada que já conhece esses caminhos

A ferramenta Limpar analisa primeiro e mostra um resultado que você revisa antes de qualquer coisa se mover. Cada linha de candidato traz o caminho exato, o dono e o tamanho, e qualquer coisa de que o scanner não tem confiança chega desmarcada, então o clique padrão é a ação menor. Desinstalações de apps vão para o Lixo. Caches apagam direto por padrão para recuperar espaço, mas podem ser configurados para ir ao Lixo. Ações de limpeza ficam registradas localmente em ~/Library/Logs/mole/operations.log; o log distingue movimentos para o Lixo de exclusão permanente.

Dois comportamentos importam especificamente para ferramentas de IA. Diretórios de versões antigas de CLI de agente são oferecidos depois de conferir o alvo do lançador, não só de comparar números de versão. Esse alvo identifica um caminho ativo; antes de remover outras cópias, confira processos em execução, atualizações e instalações fixadas que ainda precisam delas. Mantenha qualquer coisa incerta. A desinstalação confere a propriedade em vez de depender só do casamento de nomes, então remover um app de um fornecedor não oferece o pai compartilhado de Application Support de que um irmão ainda instalado é dono.

Para rodar o trabalho: abra Limpar, deixe a análise terminar, expanda os grupos que parecem grandes, desmarque o que quer manter, limpe e confira o espaço liberado. A análise é grátis e cada ferramenta paga roda duas vezes de graça, então toda a revisão pode ser verificada antes de decidir se US$19 vale a pena.

O Mole CLI, quando você prefere ficar no terminal

Um produto gratuito separado, de código aberto sob GPL-3.0, instalado com brew install mole. Pré-visualize primeiro, sempre:

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

mo clean trata de caches e logs, mo purge mira artefatos antigos de build de projeto, e clean, uninstall e optimize aceitam --dry-run para você pré-visualizar as ações. Ele compartilha a lista de proteção do usuário e o local do log de operações com o app para Mac. Uma diferença antes de você tirar a flag: a limpeza de cache do CLI remove arquivos de forma permanente, enquanto a desinstalação e a remoção de resíduos ainda vão para o Lixo.

cc-cleaner, a opção de terminal de código aberto feita para este problema

O cc-cleaner tem licença MIT, Python 3.10 ou posterior, instalável com pipx install cc-cleaner. Traz 22 limpadores, incluindo Claude Code, npm, uv, cargo, Docker, Playwright, caches de navegador, e um grupo de modelos de IA/ML que cobre Hugging Face, PyTorch, Whisper e Ollama. cc-cleaner status imprime uma tabela de tamanhos, cc-cleaner clean abre um seletor interativo, -n é um dry run.

O modelo de risco é explícito: itens Safe limpam por padrão, enquanto itens Moderate e Dangerous exigem --force, e o README coloca "transcrições de conversa, lojas compartilhadas" no nível Moderate. O código-fonte diz o resto. O limpador de Ollama dele remove o todo de ~/.ollama/models como um diretório, o limpador de Hugging Face faz o mesmo com ~/.cache/huggingface/hub e datasets, e o limpador de Claude oferece as transcrições *.jsonl em ~/.claude/projects. A exclusão é shutil.rmtree e Path.unlink, então nada vai para o Lixo. A camada de segurança é um conjunto congelado de caminhos de sistema proibidos mais a exigência de que todo alvo fique sob a sua pasta pessoal: uma lista determinística que uma pessoa escreveu, exatamente como deveria ser. A diferença é onde a linha fica, não o rigor. O cc-cleaner coloca lojas de modelo e transcrições atrás de uma flag; a limpeza comum do Mole as recusa.

DevCleaner, se você quer um app de barra de menus para o mesmo terreno

O DevCleaner é um utilitário de barra de menus para macOS 14 ou posterior, hoje na 1.9.0, cobrindo 23 ecossistemas, do DerivedData do Xcode e do Gradle ao npm e ao Docker, com scanners dedicados para Claude, ChatGPT, Cursor, Ollama e LM Studio. Itens Safe são apagados por padrão, itens Warning são "a sua decisão", itens Danger nunca vêm pré-selecionados, e ele mantém uma lista rígida de negação para credenciais e arquivos de sessão, mais um aviso antes de tocar os caches de um app em execução. A limpeza central é grátis e o Pro é vendido como compra única ou assinatura anual; confira os números atuais na página do fornecedor. O site não diz se as remoções vão para o Lixo, que é a coisa que vale perguntar antes da primeira execução.

A MacPaw também publica um CLI do CleanMyMac como beta público, por um cask do Homebrew, mirando os mesmos artefatos. É proprietário, o repositório é um rastreador de issues em vez de código-fonte, e o comportamento ainda está mudando de forma explícita, então leia o que o passo de confirmação mostra em vez de qualquer descrição publicada.

Apontar um agente para o seu próprio disco

O último caminho é pular as ferramentas de limpeza e pedir ao Claude Code, ou a um agente parecido, para limpar o disco diretamente, opcionalmente por uma das skills de limpeza publicadas. A vantagem é real e nada mais aqui a tem: um agente pode raciocinar sobre um layout que ninguém catalogou, seja um framework lançado no mês passado, uma cadeia de ferramentas privada, ou uma pasta pessoal arrumada do jeito que só você arruma.

A avaliação tem de ser igualmente clara. Os comandos de shell são gerados na hora da inferência contra o seu sistema de arquivos real, então o que roda nunca foi revisado por ninguém antes de rodar. Não há dry run a menos que você exija um. O raio de impacto é a sua pasta pessoal, e rm -rf composto a partir de uma variável que acabou vazia é um modo de falha com uma longa história. A parte um se aplica com a rede de segurança removida: a decisão é probabilística e ligada direto ao último portão.

Quatro proteções custam quase nada:

• Faça-o conduzir uma ferramenta com flag de pré-visualização, em vez de compor as remoções. Uma skill pública do Claude Code envolve o CLI mo e torna mo clean --dry-run obrigatório antes de mo clean, imprime a saída completa do dry run e exige uma confirmação digitada. O agente escolhe o alvo, uma ferramenta determinística executa a exclusão.
• Nunca pré-aprove rm nos seus ajustes de permissão. Aprove cada comando de remoção individualmente, e leia o caminho em vez do resumo dele.
• Faça do Lixo o padrão. Use o Finder ou uma ferramenta que conheça o Lixo, como o trash do Homebrew. Arquivos que ainda estão no Lixo em geral podem ser restaurados, mas isso não é um backup. Um mv simples para ~/.Trash não é equivalente: colisões de nome podem sobrescrever arquivos.
• Limite o conjunto de trabalho. Aponte-o para um diretório e peça du -sh antes e df -h depois, para a recuperação alegada ser medida, não estimada.

Lojas de modelo pertencem à ferramenta que os baixou

Nenhum limpador geral deveria ser o seu instrumento aqui, inclusive os de cima. Ollama e Hugging Face mantêm lojas endereçadas por conteúdo em que modelos compartilham blobs, então só a ferramenta dona sabe qual blob ainda é referenciado. Use ollama ls e ollama rm <model>, e hf cache ls com hf cache rm model/<repo> --dry-run. Por que apagar arquivos de blob à mão deixa um modelo órfão está em remover restos de ferramentas de IA.

Como se comparam

O limite, dito com clareza

O Mole não é resposta a malware, não é um backup e não substitui um desinstalador do fornecedor em software que traz drivers, componentes de VPN ou extensões de sistema. Ele não apaga pesos de modelo, e o histórico de chat de IA só sai por Limpeza e cuidados de IA, uma sessão marcada de cada vez, então se o seu problema de 200 GB é inteiramente uma biblioteca de modelos, ele mostra a forma dessa biblioteca em Analisar e entrega o trabalho ao Ollama ou ao LM Studio. Modelos do Ollama sem uso por um mês são a exceção: Limpeza e cuidados de IA os lista e remove os que você marca com ollama rm. Esse é um limite deliberado, não uma lacuna para fechar depois.

Escolhendo um

200 GB de saída de build e uma dúzia de cadeias de ferramentas. O volume está em caches, node_modules antigos, DerivedData e Docker, não em nada específico de IA. Comece com uma varredura revisada ou mo clean --dry-run, e depois percorra limpar caches de desenvolvedor para as lojas que precisam do próprio comando de poda. O cc-cleaner é uma boa segunda passada se você ler os níveis de risco primeiro.

Uma biblioteca local grande de modelos. Pule limpadores gerais para os pesos por completo. ollama ls, hf cache ls e a visualização Meus modelos do LM Studio são as únicas ferramentas que conseguem liberar um blob compartilhado com segurança. Use um mapa de disco para achar a loja e a ferramenta dona para mudá-la.

Você acabou de notar que o Cursor ou o Claude Code estão comendo disco. Comece separando caches e logs descartáveis de transcrições e estado de projeto. Versões antigas de CLI só são candidatas depois de conferir lançadores, processos em execução, atualizações e versões fixadas. Mantenha as transcrições e qualquer coisa que você não consiga identificar; a revisão passo a passo está em limpar depois das ferramentas de código com IA.

Perguntas frequentes

Um limpador de Mac com IA apaga com mais segurança do que um normal?

Não, com a evidência disponível. Um modelo pode vencer uma regra ao decidir qual app é dono de uma pasta órfã e ao ordenar o que merece atenção, porque esses são problemas nebulosos com muitos sinais fracos. Decidir se um caminho é seguro de apagar precisa de determinismo e de uma lista auditável, e um modelo não fornece nenhum dos dois. Pergunte a um fornecedor qual passo do pipeline o modelo executa, e trate "ele decide o que é seguro apagar" como um convite a ver a lista.

É seguro deixar o Claude Code limpar o meu Mac?

É a opção mais flexível e a menos limitada. Os comandos são gerados na hora da inferência e rodam contra a sua pasta pessoal, sem pré-visualização a menos que você peça uma. Se fizer isso, faça o agente conduzir uma ferramenta que tenha flag de dry run, em vez de compor rm -rf por conta própria, nunca pré-aprove rm nos ajustes de permissão, envie as remoções para o Lixo e confine-o a um diretório de cada vez.

Um limpador de Mac vai apagar os meus modelos do Ollama ou o histórico do Claude Code?

Depende inteiramente da ferramenta, e por isso é a pergunta a fazer primeiro. A limpeza comum do Mole bloqueia ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface, ~/.claude/projects, ~/.codex/sessions e ~/.grok/sessions no portão de exclusão em qualquer idade, então eles nunca viram candidatos. O cc-cleaner classifica diretórios de modelo e transcrições do Claude Code como risco Moderate e os remove se você passar --force. Leia os níveis de risco de uma ferramenta antes da primeira execução, não depois. A exceção deliberada é a página Limpeza e cuidados de IA do Mole, que pode listar sessões do Codex além de uma janela que você escolhe e sessões do Claude Code cujo projeto sumiu, desmarcadas, para você confirmar uma a uma.

O que está realmente ocupando o espaço depois de um ano de ferramentas de código com IA?

Confira versões antigas de CLI e transcrições, além dos caches. Por exemplo, se cada versão tem cerca de 300 MB e só uma de cinco ainda é necessária, as outras quatro somam cerca de 1,2 GB. Isso é uma ilustração, não uma medição do seu Mac. Transcrições em ~/.claude/projects também podem crescer com o tempo, mas, ao contrário dos caches, podem conter trabalho insubstituível, então exclua-as de uma varredura de limpeza.

Leitura relacionada

• Limpar modelos do Ollama e do LM Studio no Mac para a mecânica das lojas de modelo endereçadas por conteúdo.
• Limpar caches de desenvolvedor sem quebrar builds para lojas de gerenciadores de pacotes e node_modules espalhados.
• Limpar depois das ferramentas de código com IA para a versão passo a passo, caminho por caminho.