Limpiadores de Mac con IA: qué debería decidir un modelo y qué no

"AI Mac cleaner" se resuelve en dos productos distintos. Uno es una app de limpieza con un modelo metido en algún punto, vendida por lo inteligentes que son sus recomendaciones. El otro es una herramienta para recuperar el disco que Claude Code, Cursor, Ollama y sus cachés se han ido tragando en silencio durante el último año. El segundo es lo que quiere la mayoría de la gente que escribe esa frase en 2026. Vale la pena responder primero al primero, porque esa respuesta decide cuánto confiar en cualquier cosa del segundo grupo.

Primera parte: qué está decidiendo realmente el modelo

Un limpiador que anuncia IA está haciendo una afirmación sobre un paso de un proceso que tiene al menos cuatro:

1. Enumerar. Recorrer el disco y medirlo. Trabajo con la forma de du, sin ningún juicio de por medio.
2. Atribuir. Decidir qué app o cadena de herramientas es dueña de cada ruta.
3. Ordenar y explicar. Decidir cuáles doce de cuatro mil candidatos merecen una mirada, y decir en una frase qué es cada uno.
4. Decidir y borrar. Decidir qué es seguro quitar, y luego quitarlo.

Los pasos 2 y 3 son de verdad difusos, y ahí un modelo de verdad ayuda. El paso 4 es un tipo de problema distinto, y un modelo es el instrumento equivocado para él. Casi toda discusión sobre limpiadores con IA es en realidad una discusión sobre a qué paso se refiere el proveedor.

Dónde un modelo se gana su lugar

La atribución es el caso difícil honesto. Supón que encuentras ~/Library/Application Support/Foo Labs con 3 GB dentro y ninguna app llamada Foo Labs en el disco. La evidencia es débil y dispersa: fragmentos de identificador de bundle dentro de los propios plists de la carpeta, un prefijo que coincide en ~/Library/HTTPStorages, un paquete .savedState bajo ~/Library/Saved Application State, un recibo de instalación en /var/db/receipts. La igualdad de nombres falla de inmediato, porque el proveedor escribe Foo Labs en un sitio y com.foolabs.editor en otro, y un catálogo escrito a mano cubre las primeras varias centenas de apps y luego se cae por un precipicio. Esta es exactamente la forma en la que un modelo le gana a una regla: muchas señales débiles, ninguna decisiva, una cola larga que nadie va a terminar de catalogar.

Ordenar tiene la misma forma: un escaneo que devuelve 4.000 rutas y 60 GB es un segundo problema, no un resultado. Explicar es todavía más fácil, porque convertir ~/Library/Caches/com.apple.nsurlsessiond en una frase sencilla es traducción. Una herramienta que usa un modelo para esos tres trabajos, y lo dice, anuncia una función real.

Por qué la última compuerta tiene que ser determinista

La decisión de borrar necesita tres propiedades que un modelo no puede ofrecer.

Determinismo. Mismo disco, misma versión, misma respuesta, siempre. Temperatura cero no compra esto, porque el prompt lleva dentro el contenido de tu máquina: instala una app más, el listado de archivos cambia, y los tokens de los que depende la decisión cambian con él. Una regla de seguridad que se sostiene en tu Mac pero no en el de tu colega no es una regla de seguridad.

Auditable antes del hecho. Una lista de protección es un conjunto de prefijos de ruta, legible por completo en un minuto y comparable entre dos versiones. Los pesos más un prompt no se pueden leer como una lista de lo que se va a rechazar, así que nada te muestra el límite antes de que lo cruces.

Auditable después del hecho. Cuando una regla determinista borra lo que no debía, obtienes un bug reproducible: aquí está la ruta, aquí está la línea que lo permitió, aquí está la prueba que ahora falla. Cuando lo hace un modelo, el artefacto es una transcripción, el arreglo es editar un prompt, y el efecto de ese cambio en todos los demás casos no se mide.

Los modos de fallo también son asimétricos. Un mal ordenamiento cuesta un scroll; un mal borrado de ~/.claude/projects cuesta cada transcripción que tienes. Así que el marco no es "IA buena, IA mala", es una división justo por el medio del proceso: probabilístico donde equivocarse cuesta atención, determinista donde equivocarse cuesta datos.

De qué lado está Mole

Mole no trae ningún modelo ni corre inferencia. Si una ruta puede llegar a ser candidata a borrado lo decide un arreglo fijo de prefijos relativos bloqueados, compilado dentro de la app, con entradas como .ollama/models, .lmstudio/models, .cache/huggingface, .cache/torch, .claude/projects, .codex/sessions, .grok/sessions y Library/Caches/com.apple.e5rt.e5bundlecache. La mitad editable por el usuario es un archivo de texto plano que puedes leer con cat ~/.config/mole/whitelist. El Mole CLI, gratis, es de código abierto bajo GPL-3.0 y aplica la misma lista, así que el código que la hace cumplir es público.

Esa última entrada es el argumento en miniatura. com.apple.e5rt.e5bundlecache vive en ~/Library/Caches y la palabra en su nombre es "cache", así que cualquier heurística del mundo lo clasifica como desechable. Contiene modelos compilados del Apple Neural Engine, y borrarlo mientras una app tiene modelos cargados rompe las llamadas de reconocimiento hasta que la máquina se reinicia. Está protegido porque alguien tuvo ese fallo y escribió la línea.

Así que la prueba práctica para cualquier herramienta se reduce a una pregunta: ¿cuál de los cuatro pasos realiza el modelo? Enumeración, atribución, ordenamiento y explicación son respuestas creíbles. "Decide qué es seguro borrar" es una respuesta que hay que seguir pidiendo ver la lista, y si no hay lista no hay nada que revisar.

Segunda parte: herramientas para limpiar los restos de las herramientas de IA

Esto es lo que la mayoría quiere decir con esa búsqueda. La huella se divide en cuatro tipos de datos con cuatro reglas distintas, y confundirlos es donde ocurren los accidentes:

• Cachés y logs de la herramienta. ~/Library/Caches/claude-cli-nodejs, las cachés de Electron de Cursor, directorios de telemetría y depuración bajo ~/.claude. Regenerables y sin interés.
• Transcripciones y estado de proyectos. ~/.claude/projects, ~/.codex/sessions, ~/.grok/sessions. Con frecuencia la sorpresa más grande de un escaneo, e irremplazables.
• Versiones antiguas del CLI. Los CLI de agentes que se autoactualizan dejan atrás versiones anteriores. En Codex esto mide alrededor de 300 MB por versión, así que cinco versiones acumuladas llegan a 1,2 GB con solo una en uso.
• Pesos de modelos. ~/.ollama/models, ~/.cache/huggingface/hub, el directorio de modelos de LM Studio. Con diferencia lo más grande, propiedad de la herramienta que los descargó.

Mide antes de elegir una herramienta:

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

Mole, para una pasada revisada que ya conoce estas rutas

La herramienta Clean escanea primero y muestra un resultado que revisas antes de que se mueva nada. Cada fila candidata lleva su ruta exacta, propietario y tamaño, y todo aquello de lo que el escáner no está seguro llega desmarcado, así que el clic por defecto es la acción más pequeña. Los borrados van a la Papelera en vez de desvincularse, y cada operación se añade a ~/Library/Logs/mole/operations.log, donde TRASHED y DELETED son palabras distintas.

Dos comportamientos importan específicamente para las herramientas de IA. Se ofrecen los directorios de versiones antiguas del CLI de un agente, pero la versión en uso nunca se convierte en candidata: el objetivo del lanzador se resuelve y se fija primero, así que la versión que estás corriendo queda excluida por construcción y no por una suposición sobre el número de versión. Y desinstalar razona sobre la propiedad en vez de emparejar por nombre, así que quitar una app de un proveedor no ofrece el padre compartido de Application Support que sigue siendo de una app hermana instalada.

Para hacer el trabajo: abre Clean, deja que termine el escaneo, expande los grupos que se vean grandes, desmarca lo que quieras conservar, y luego limpia y revisa el espacio liberado. Escanear es gratis y cada herramienta de pago corre dos veces gratis, así que toda la revisión se puede verificar antes de decidir si los $19 valen la pena.

El Mole CLI, cuando prefieres quedarte en la terminal

Un producto independiente y gratuito, de código abierto bajo GPL-3.0, se instala con brew install mole. Previsualiza primero, siempre:

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

mo clean se encarga de cachés y logs, mo purge apunta a artefactos de build de proyectos antiguos, y todo comando destructivo acepta --dry-run así que primero lees la lista exacta de rutas. Comparte la lista de protección y el log de operaciones con la app de Mac. Una diferencia antes de que quites la bandera: la limpieza de caché del CLI borra archivos de forma permanente, mientras que desinstalar y quitar restos sigue yendo a la Papelera.

cc-cleaner, la opción de terminal de código abierto hecha para este problema

cc-cleaner tiene licencia MIT, requiere Python 3.10 o posterior, y se instala con pipx install cc-cleaner. Trae 22 limpiadores, incluyendo Claude Code, npm, uv, cargo, Docker, Playwright, cachés de navegador, y un grupo de modelos de IA/ML que cubre Hugging Face, PyTorch, Whisper y Ollama. cc-cleaner status imprime una tabla de tamaños, cc-cleaner clean abre un selector interactivo, -n es un dry run.

Su modelo de riesgo es explícito: los elementos Safe se limpian por defecto mientras que los Moderate y Dangerous requieren --force, y su README pone "transcripciones de conversación, almacenes compartidos" en el nivel Moderate. El código fuente cuenta el resto. Su limpiador de Ollama borra todo ~/.ollama/models como un solo directorio, su limpiador de Hugging Face hace lo mismo con ~/.cache/huggingface/hub y datasets, y su limpiador de Claude ofrece las transcripciones *.jsonl bajo ~/.claude/projects. El borrado es shutil.rmtree y Path.unlink, así que nada llega a la Papelera. Su capa de seguridad es un conjunto congelado de rutas del sistema prohibidas más el requisito de que cada objetivo esté bajo tu directorio de inicio: una lista determinista que escribió una persona, exactamente como debe ser. La diferencia está en dónde se traza la línea, no en el rigor. cc-cleaner pone los almacenes de modelos y las transcripciones detrás de una bandera; Mole los rechaza.

DevCleaner, si quieres una app de barra de menús para el mismo terreno

DevCleaner es una utilidad de barra de menús para macOS 14+, actualmente en la versión 1.9.0, que cubre 23 ecosistemas desde Xcode DerivedData y Gradle hasta npm y Docker, con escáneres dedicados para Claude, ChatGPT, Cursor, Ollama y LM Studio. Los elementos Safe se borran por defecto, los Warning son "decisión tuya", los Danger nunca vienen premarcados, y mantiene una lista de rechazo fija para credenciales y archivos de sesión, más una advertencia antes de tocar las cachés de una app en ejecución. La limpieza básica es gratis y Pro se vende como compra única o suscripción anual; revisa las cifras actuales en la página del proveedor. Su sitio no dice si los borrados van a la Papelera, que es lo primero que vale la pena preguntar antes de una primera corrida.

MacPaw también publica un CleanMyMac CLI como beta pública, vía un cask de Homebrew, apuntando a los mismos artefactos. Es propietario, su repositorio es un rastreador de issues y no código fuente, y su comportamiento todavía está cambiando de forma explícita, así que lee lo que te muestra su paso de confirmación en vez de cualquier descripción publicada.

Apuntar un agente a tu propio disco

La última vía es saltarse las herramientas de limpieza y pedirle a Claude Code o a un agente parecido que limpie el disco directamente, opcionalmente a través de uno de los skills de limpieza publicados. Su ventaja es real y ninguna otra opción de esta lista la tiene: un agente puede razonar sobre una estructura que nadie ha catalogado, ya sea un framework publicado el mes pasado, una cadena de herramientas privada, o un directorio de inicio ordenado como solo tú lo ordenas.

La evaluación tiene que ser igual de clara. Los comandos de shell se generan en el momento de la inferencia contra tu sistema de archivos real, así que lo que corre nunca lo revisó nadie antes de correr. No hay dry run a menos que lo exijas. El radio de impacto es tu directorio de inicio, y un rm -rf compuesto a partir de una variable que resultó vacía es un modo de fallo con una larga historia. La primera parte aplica con la red de seguridad quitada: la decisión es probabilística y está conectada directo a la última compuerta.

Cuatro barandillas cuestan casi nada:

• Haz que maneje una herramienta con bandera de previsualización en vez de componer los borrados él mismo. Un skill público de Claude Code envuelve el CLI mo y hace obligatorio mo clean --dry-run antes de mo clean, imprime la salida completa del dry run, y exige una confirmación escrita. El agente elige el objetivo, una herramienta determinista ejecuta el borrado.
• Nunca preapruebes rm en tus ajustes de permisos. Aprueba cada comando de borrado individualmente, y lee la ruta en vez del resumen que se hace de ella.
• Haz de la Papelera el destino por defecto. trash de Homebrew, o mv hacia ~/.Trash, convierte cada error en uno recuperable.
• Acota el conjunto de trabajo. Apúntalo a un solo directorio, y pide du -sh antes y df -h después para que lo recuperado se mida en vez de estimarse.

Los almacenes de modelos pertenecen a la herramienta que los descargó

Ningún limpiador general debería ser tu instrumento aquí, incluyendo los de arriba. Ollama y Hugging Face mantienen almacenes direccionados por contenido donde los modelos comparten blobs, así que solo la herramienta propietaria sabe qué blob sigue referenciado. Usa ollama ls y ollama rm <model>, y hf cache ls con hf cache rm model/<repo> --dry-run. Por qué borrar archivos de blob a mano deja huérfano a un modelo se explica en quitar restos de herramientas de IA.

Cómo se comparan

El límite, dicho sin rodeos

Mole no responde a malware, no es una copia de seguridad, y no sustituye al desinstalador del proveedor para software que instala drivers, componentes VPN o extensiones del sistema. No borra pesos de modelos ni historial de chat de IA, así que si tu problema de 200 GB es enteramente una biblioteca de modelos, te muestra la forma de esa biblioteca en Analyze y le pasa el trabajo a Ollama o LM Studio. Ese es un límite deliberado, no un hueco por cerrar más adelante.

Elegir una

200 GB de salidas de build y una docena de cadenas de herramientas. El volumen está en cachés, node_modules viejos, DerivedData y Docker, no en nada específico de IA. Empieza con una pasada revisada o mo clean --dry-run, y luego revisa limpiar cachés de desarrollo para los almacenes que necesitan su propio comando de poda. cc-cleaner es una buena segunda pasada si primero lees sus niveles de riesgo.

Una biblioteca de modelos locales grande. Sáltate por completo los limpiadores generales para los pesos. ollama ls, hf cache ls y la vista My Models de LM Studio son las únicas herramientas que pueden liberar un blob compartido de forma segura. Usa un mapa de disco para encontrar el almacén y la herramienta propietaria para modificarlo.

Acabas de notar que Cursor o Claude Code se está comiendo el disco. El caso más manejable: las cachés y los logs se regeneran, las versiones antiguas del CLI son desperdicio puro, y las transcripciones son lo único que no hay que tocar. Cualquier herramienta revisada de esta lista lo resuelve, y la versión paso a paso está en limpiar después de las herramientas de codificación con IA.

Preguntas frecuentes

¿Un limpiador de Mac con IA borra de forma más segura que uno normal?

No, según la evidencia disponible. Un modelo le puede ganar a una regla al decidir qué app es dueña de una carpeta huérfana y al ordenar qué merece atención, porque son problemas difusos con muchas señales débiles. Decidir si una ruta es segura de borrar necesita determinismo y una lista auditable, y un modelo no ofrece ninguna de las dos cosas. Pregúntale a un proveedor en qué paso del proceso corre su modelo, y toma "decide qué es seguro borrar" como pie para pedir ver la lista.

¿Es seguro dejar que Claude Code limpie mi Mac?

Es la opción más flexible y la menos acotada. Los comandos se generan en el momento de la inferencia y corren contra tu directorio de inicio, sin previsualización a menos que la pidas. Si lo haces, haz que el agente maneje una herramienta con bandera de dry run en vez de componer rm -rf él mismo, nunca preapruebes rm en tus ajustes de permisos, envía los borrados a la Papelera, y confínalo a un solo directorio a la vez.

¿Un limpiador de Mac va a borrar mis modelos de Ollama o mi historial de Claude Code?

Depende por completo de la herramienta, por eso es la pregunta que hay que hacer primero. Mole bloquea ~/.ollama/models, ~/.lmstudio/models, ~/.cache/huggingface, ~/.claude/projects, ~/.codex/sessions y ~/.grok/sessions en la compuerta de borrado sin importar su antigüedad, así que nunca se convierten en candidatos. cc-cleaner clasifica los directorios de modelos y las transcripciones de Claude Code como riesgo Moderate y los borra si pasas --force. Lee los niveles de riesgo de una herramienta antes de la primera corrida, no después.

¿Qué es lo que realmente ocupa el espacio después de un año usando herramientas de codificación con IA?

Normalmente las versiones antiguas del CLI y las transcripciones, y no las cachés que la gente espera. Un CLI de agente que se autoactualiza puede dejar atrás varios cientos de megabytes por versión, y en Codex cinco versiones acumuladas llegan a unos 1,2 GB con solo una en uso. Las transcripciones bajo ~/.claude/projects se acumulan en silencio y son el elemento con más probabilidades de sorprenderte en un escaneo, y por eso mismo deberían quedar excluidas de una pasada en vez de incluidas.

Lecturas relacionadas

• Quitar modelos de Ollama y LM Studio en Mac para la mecánica de los almacenes de modelos direccionados por contenido.
• Limpiar cachés de desarrollo sin romper builds para almacenes de gestores de paquetes y node_modules dispersos.
• Limpiar después de las herramientas de codificación con IA para la versión paso a paso, ruta por ruta.