# Cursor con alto uso de CPU o memoria en Mac: encuentra el trabajo que lo consume

> Prueba extensiones, el alcance del espacio de trabajo y los archivos generados para diagnosticar el uso de CPU y memoria de Cursor sin borrar datos del proyecto ni el historial de chat.

Published: 2026-10-23 | Updated: 2026-10-25

Cursor puede hacer que un Mac se sienta lento por varias razones distintas: una extensión ocupada, un espacio de trabajo grande que se está procesando, una tarea de IA de larga duración o un proceso que sigue consumiendo memoria después de que el trabajo termina. Empieza por identificar qué acción provoca el aumento. Una carpeta de caché grande no es prueba de que borrarla vaya a corregir el uso de CPU.

## Mantén una comparación reproducible

Guarda el proyecto y anota la versión de Cursor. Abre el **Monitor de Actividad**, busca Cursor y compara la CPU y la memoria antes de abrir el proyecto, mientras reproduces el problema y después de que la tarea termina. Mantén el mismo repositorio y la misma acción en cada prueba.

Si una carpeta pequeña se comporta con normalidad pero un monorepo no, el alcance del espacio de trabajo es una pista útil. Si un chat nuevo responde con fluidez pero una conversación larga no, pruébalo por separado. Si el uso aumenta de forma constante bajo una carga de trabajo repetida, registra el crecimiento y el tiempo transcurrido. Una sola lectura alta no demuestra una fuga de memoria.

## Separar el editor del trabajo que inicia

Una sesión de Cursor puede incluir la ventana del editor, extensiones, un servidor de lenguaje, terminales y una tarea de IA. Parte de ese trabajo puede continuar mientras el editor está inactivo. Antes de desactivar nada, comprueba si un terminal sigue ejecutando una compilación, un observador de pruebas, un servidor de desarrollo o un modelo. Detén solo una tarea que reconozcas mediante el control normal del terminal o de la aplicación, después de guardar su trabajo.

En el Monitor de Actividad, compara el proceso ocupado en tres momentos: con el espacio de trabajo abierto pero sin ninguna tarea iniciada, durante la acción que se siente lenta y después de que esa acción termine. Registra el nombre del proceso y si el síntoma es retraso en la entrada, CPU alta o memoria en aumento. Un nombre de proceso auxiliar por sí solo rara vez identifica la extensión responsable, así que usa las siguientes comparaciones para acotarlo.

Intenta abrir la carpeta real del proyecto en lugar de su carpeta superior que contiene varios repositorios. No muevas ni elimines el proyecto para realizar esta prueba. Si un espacio de trabajo más pequeño mejora el resultado, determina qué incluía el espacio de trabajo más amplio: recursos generados, dependencias de otro proyecto, un observador activo o una herramienta de lenguaje que analiza más archivos. Esto es evidencia sobre el alcance, no un motivo para excluir todos los directorios grandes.

Por ejemplo, un servidor de desarrollo que escribe salida repetidamente puede ser trabajo activo que el editor observa. Una exclusión de carpeta y detener ese servidor prueban explicaciones distintas. Cambiar ambos a la vez pierde la distinción, así que registra qué cambio individual afecta la acción repetida.

## Prueba las extensiones antes de restablecer el editor

La [guía de rendimiento](https://cursor.com/help/troubleshooting/performance) de Cursor recomienda una ejecución con las extensiones desactivadas. Después de guardar el trabajo y salir de Cursor con normalidad, inícialo desde Terminal con:

```
cursor --disable-extensions
```

Esto supone que el comando de shell `cursor` está instalado. Si no está disponible, usa la vista de Extensiones de Cursor para desactivar las extensiones no esenciales durante la comparación. Lleva un registro de lo que desactivaste para que la prueba sea reversible.

Repite la misma acción del proyecto. Si mejora, restaura las extensiones una a una hasta que el síntoma vuelva. Si no mejora, restaura el estado anterior de las extensiones y continúa. No tomes una prueba con otros archivos abiertos como prueba en contra de una extensión, y no elimines todo el directorio de datos de usuario como siguiente paso.

## Acotar una prueba de extensión exitosa

Si la ejecución con la extensión desactivada mejora la misma acción, no reinstales todas las extensiones ni descartes sus ajustes. Parte del conjunto habilitado registrado y restaura una a la vez cuando solo haya unos pocos candidatos. Con muchas extensiones, restaurar la mitad a la vez puede acotar el grupo más rápido, siempre que cada prueba abra el mismo proyecto y complete la misma acción.

El método de grupos es un atajo de investigación, no una prueba de que haya exactamente una extensión defectuosa. Dos extensiones pueden interactuar, y desactivar una extensión de lenguaje también puede eliminar funciones que desencadenan la carga de trabajo. Una vez que surja un candidato, repite la prueba con todas las extensiones que realmente necesitas habilitadas excepto ese candidato. Comprueba el autocompletado de código, los diagnósticos y la compilación, además de la capacidad de respuesta.

Si la comparación final sigue apuntando a una extensión, registra su nombre y versión. Desactivarla solo en el espacio de trabajo puede ser más adecuado que cambiar todos los proyectos, donde esa opción exista. Si desactivarla rompe una función necesaria, restáurala y conserva la reproducción para su mantenedor en lugar de tratar un editor más rápido pero incompleto como el resultado deseado.

## Excluye la salida generada que no necesitas

El trabajo asistido por IA puede producir salidas de compilación, paquetes exportados, imágenes generadas y registros grandes. Abrir una carpeta principal que contiene todos los proyectos puede exponer mucho más material del que la tarea necesita. Abre primero la raíz real del proyecto.

Cursor documenta [`.cursorignore`](https://cursor.com/docs/reference/ignore-file) para restringir el acceso de la IA a los archivos del proyecto, con excepciones para la terminal y las herramientas MCP. Su guía de rendimiento recomienda excluir carpetas generadas grandes. Esto es más amplio que un cambio solo de indexación y no detiene todos los servidores de lenguaje ni los observadores del sistema de archivos.

Para un proyecto en el que estos directorios realmente son salida generada, un archivo `.cursorignore` puede contener:

```
dist/
build/
.next/
```

Inspecciona primero las carpetas y conserva las reglas de exclusión existentes. Un directorio llamado `build` podría contener scripts de compilación mantenidos a mano en tu proyecto. Añadir un patrón no borra archivos, pero puede quitar contexto útil de las funciones de IA. Vuelve a comprobar el estado de la indexación y la misma acción del editor después.

## Sigue el proceso que sigue funcionando

| Observación | Qué investigar a continuación |
| --- | --- |
| El problema desaparece sin extensiones | Restaura las extensiones una a una |
| Solo se activa con un espacio de trabajo grande | La raíz del proyecto, la salida generada y las herramientas de lenguaje |
| La CPU se estabiliza cuando termina una tarea de IA | La carga de trabajo de la tarea y la concurrencia |
| La memoria sigue aumentando durante la misma acción repetida | Un informe reproducible con la versión y los tiempos |
| Todo el Mac se ralentiza | La presión de memoria y otras apps activas |

La [guía sobre la presión de memoria en Mac](https://mole.fit/es/blog/mac-memory-pressure-explained) explica por qué la memoria usada por sí sola no es una señal de alarma fiable. Cerrar un espacio de trabajo que no usas puede ayudar a una carga de trabajo activa sin borrar su contenido.

## Comprobar qué cambió una exclusión

Después de cambiar `.cursorignore`, inspecciona el diff del archivo y prueba tanto la acción lenta como una pregunta normal sobre código que debería seguir siendo accesible. Un contexto de proyecto visible más pequeño solo es útil si Cursor todavía tiene el código fuente necesario para la tarea. Elimina solo el patrón nuevo si excluyó algo importante; no reemplaces todo el archivo de ignore por uno vacío.

Mantén estos límites separados. Las reglas de Git ignore rigen el tratamiento de Git de los archivos no rastreados. Las exclusiones de acceso a la IA de Cursor rigen las funciones de IA documentadas. Un servidor de lenguaje, una extensión o un observador de terminal tiene su propio comportamiento. Añadir el mismo patrón en todas partes sin identificar el componente ocupado puede ocultar síntomas y eliminar funcionalidad útil.

Si la CPU es normal pero una respuesta tarda en llegar, investiga la solicitud de IA por separado del uso de recursos del editor. Si la memoria aumenta en cada repetición incluso después de que el trabajo termina, registra varias lecturas comparables y los intervalos transcurridos, luego prueba si reabrir el espacio de trabajo cambia el patrón. Eso es mucho más útil para un mantenedor que informar el número más alto visto durante una compilación.

## Limpia los restos del disco solo cuando el problema sea el espacio en disco

Las cachés de Cursor, las versiones antiguas de herramientas, los historiales de sesión y los worktrees tienen distintos propietarios y necesidades de recuperación. Un worktree puede contener cambios sin confirmar o un commit que no existe en ningún otro lugar. Un historial de chat puede ser trabajo que todavía necesitas.

Usa la [guía de limpieza de herramientas de codificación con IA](https://mole.fit/es/blog/how-to-clean-up-ai-coding-tools-mac) para esa tarea de almacenamiento por separado. Para problemas persistentes de CPU o memoria, envía a Cursor el caso reproducible más pequeño, la versión y la comparación de extensiones. Revisa los registros antes de compartirlos, porque pueden contener nombres de proyectos o código. Así el informe trata sobre la ralentización real y no sobre el resultado de una limpieza no relacionada.

---

Canonical HTML page: https://mole.fit/es/blog/cursor-high-cpu-memory-mac
Blog index for agents: https://mole.fit/es/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt