Cursor lanzó Projects el 10 de septiembre de 2026. En lugar de abrir un chat nuevo para cada tarea, trabajas en un hilo persistente con un agente coordinador que planifica un gran volumen de trabajo y entrega la programación real a una flota de subagentes que se ejecutan en paralelo, sobre todo en la nube.
Lo interesante no es «más agentes». Es el cambio en lo que pasa a ser tu trabajo. Dejas de vigilar a un solo agente y empiezas a dirigir el trabajo a un nivel más alto, revisando resultados terminados en lugar de ver cómo se escribe el código. Cursor lo llama la «tercera era del desarrollo de software» y dice internamente que los usuarios que trabajan sobre todo en Projects hacen merge de seis veces más PR.
Es realmente útil para trabajo que sobrevive a un solo chat: grandes funcionalidades, migraciones largas y mantenimiento sin fin. También es una cuestión real de coste y control, porque un coordinador que lanza muchos subagentes en la nube factura a tarifas de API y pone más líneas de código entre tú y la última persona que las leyó. Construyo sistemas de agentes para ganarme la vida en eesel, así que a continuación repaso cómo funciona exactamente Projects, cuánto cuesta, dónde tienen razón los escépticos y cómo se ve este modelo de «tú diriges, los agentes trabajan» fuera del código.
Qué es realmente Cursor Projects
Un Project es un contenedor para un trabajo grande. El planteamiento de Cursor: te permite «abordar volúmenes de trabajo mayores, como una funcionalidad, una migración o una aplicación completa». Mientras que un chat lo olvida todo en cuanto lo cierras, un Project mantiene el contexto durante meses, puede delegar en muchos agentes e incluso actuar sobre trabajo recurrente sin que se lo pidas.
Empiezas uno desde la navegación izquierda, describes lo que quieres construir y el coordinador se encarga del resto. Está en beta y se despliega a todos los usuarios desde la fecha de lanzamiento.
Si has usado Cursor como una herramienta de autocompletado más chat, esto es un salto mayor de lo que sugiere el changelog. La unidad de trabajo pasa de «un mensaje» a «un proyecto», y lo que gestionas pasa de «el código» a «los agentes».
El verdadero cambio: de un agente a un coordinador
Cursor lleva tiempo construyendo hacia esto. Ya en febrero de 2026 describió una «tercera era» en la que «flotas de agentes asumen volúmenes enteros de trabajo» y el desarrollador dirige el trabajo en lugar de cada agente. Projects es esa visión hecha realidad.
Esta es la trayectoria, porque es la forma más clara de ver qué cambió:
En la era uno, tú escribías el código y la IA sugería la siguiente línea. En la era dos (donde siguen la mayoría de las herramientas de programación agéntica), le das un prompt a un agente por tarea y lo ves trabajar. Projects es una apuesta por la era tres: diriges a un coordinador y el coordinador maneja la flota. El coordinador no escribe código él mismo; como delega en lugar de ejecutar, «nunca está bloqueado y siempre responde a la dirección».
Ese último detalle importa más de lo que parece. Un solo agente resulta frustrante porque se concentra en su tarea y tú esperas. Un coordinador sigue libre para hablar contigo mientras sus subagentes trabajan, y eso es lo que hace que «dirigir, no vigilar» se sienta realmente distinto en la práctica.
Cómo funciona un Project por dentro
Bajo el marketing, Projects es una capa fina de orquestación sobre cuatro cosas que Cursor ya tenía: el coordinador, los subagentes, la ejecución en la nube y los disparadores de automatización. Así encajan.
El coordinador planifica y delega
Supervisas un Project chateando con su agente coordinador. «Planifica el trabajo, lo delega en agentes que lo implementan y te devuelve el trabajo terminado para que lo compruebes», creando y gestionando agentes en tu nombre y ejecutando en paralelo tantos como requiera el trabajo. Por debajo, cada subagente trabaja en su propia ventana de contexto, se ejecuta de forma autónoma y devuelve su resultado al agente padre. Desde Cursor 2.5, los subagentes pueden incluso lanzar sus propios subagentes hijos, aunque el árbol se detiene a un nivel de profundidad.
Una advertencia honesta que la documentación deja clara: el paralelismo no es velocidad gratis. Ejecutar cinco subagentes en paralelo consume aproximadamente cinco veces los tokens de un solo agente, e incluso pueden ser más lentos en tareas simples porque cada uno empieza con un contexto limpio. La ventaja es el aislamiento y la escala, no el ritmo bruto.
En la nube por defecto, en local cuando hace falta
Projects se ejecuta sobre Cloud Agents (las máquinas virtuales aisladas en la nube antes llamadas Background Agents). Un Project «se ejecuta en su propio ordenador, así que cerrar tu portátil no lo detiene», lo que le permite ejecutar muchos más subagentes en paralelo de los que soportaría tu máquina. Cuando algo debe ejecutarse en tu equipo, el coordinador lanza un agente local para ello.
Lo que realmente importa aquí es el entorno. Como lo dice Cursor, «no configurar un entorno de desarrollo para tus agentes en la nube es como no darles un ordenador a tus ingenieros». Lo defines mediante una configuración guiada por el agente, una instantánea guardada o un Dockerfile, y los agentes en la nube clonan desde GitHub, GitLab, Azure DevOps o Bitbucket y hacen push a una rama para el traspaso. Si has configurado la integración de Claude Code con GitHub o algo similar, te resultará familiar.
Contexto compartido que se acumula
Esta es la pieza que me parece más infravalorada. La frase de Cursor es «no deberías tener que formar a un agente cada vez que empiezas una tarea». Cada Project mantiene un conjunto de archivos que se sincronizan entre todas las máquinas locales y en la nube que usan sus agentes, y los agentes escriben allí investigaciones, artefactos y lo que aprenden sobre tu base de código. El ejemplo: «si un agente descubre cómo probar un servicio, todos los agentes futuros pueden usar esas instrucciones».
El resultado es que el contexto crece con el Project y el coordinador se vuelve más eficaz con el tiempo. Es el mismo principio que darle a un agente de soporte con IA una base de conocimiento real en lugar de explicarle tu producto en cada sesión, solo que aplicado a una base de código.
Las suscripciones lo ejecutan sin prompt
El coordinador puede vigilar un canal de Slack, ejecutarse según un calendario o seguir todos tus PR, arreglando la CI y actuando cuando se abren o se fusionan. Cursor lo comercializa como «suscripciones»; en la documentación es el sistema de Automations, que lanza agentes en la nube según calendarios o eventos de GitHub, GitLab, Slack, webhooks, Linear, Sentry y PagerDuty. Apúntalo a un canal de reporte de errores y empieza a delegar cada vez que entra un bug. Esta es la capa de automatización que convierte Projects de una herramienta que abres en algo que funciona solo, la misma idea basada en disparadores que hay detrás de un chatbot de IA para Slack o un chatbot de IA para helpdesk que actúa ante mensajes nuevos.
Los tres tipos de trabajo para los que está hecho Projects
Cursor es refrescantemente concreto sobre dónde encaja, y se resume en tres patrones. Esto vale la pena interiorizarlo, porque Projects realmente no es para un arreglo de cinco minutos.
- Desarrollo de funcionalidades. Los agentes investigan el sistema y registran lo que aprenden como contexto compartido, el coordinador lo planifica y los subagentes construyen y prueban partes en paralelo. Tras el lanzamiento, el mismo Project puede monitorizar logs y atender reportes de errores con todo el contexto detrás de las decisiones originales.
- Migraciones. La expresión de Cursor es trabajo «fácil de empezar y difícil de terminar». Acuerdas un enfoque seguro con el coordinador y este lo aplica de forma incremental en toda la base de código. Revisas cada PR de cerca al principio y aflojas a medida que el patrón se sostiene.
- Gardening. Trabajo que nunca termina del todo, como la calidad del código y las regresiones. El ejemplo propio de Cursor es un Project de sistema de diseño cuyo coordinador escanea cada PR nuevo, extrae componentes y añade una regla de lint cuando ve el mismo error dos veces, y va camino de tocar entre 20 y 100 PR al día.
El hilo común: compensa cuando el trabajo «sobrevivirá a un solo chat». Para un arreglo rápido, un agente simple es más rápido y barato.
¿No sabes en cuál de estos grupos cae tu trabajo? Esta es una forma rápida de comprobarlo antes de lanzar un Project.
Encaje sólido. Deja que los agentes investiguen primero, que el coordinador planifique, y luego construyan y prueben partes en paralelo; mantén el Project vivo para atender bugs más adelante.
El caso clásico de Projects: fácil de empezar, difícil de terminar. Fija un enfoque seguro con el coordinador, revisa de cerca los primeros PR y afloja a medida que el patrón se demuestre.
Configura una suscripción para que el coordinador vigile cada PR nuevo, extraiga patrones y añada reglas de lint. Este es el punto ideal de «funciona sin ti».
Usa en su lugar un agente simple de Cursor. Un arreglo puntual no necesita un coordinador, contexto compartido ni máquinas virtuales en la nube, y un Project costaría más tokens sin ningún beneficio.
Cuánto cuesta Cursor Projects
No hay precio de lista para Projects, y ese es el titular honesto. Projects se ejecuta sobre Cloud Agents, y los Cloud Agents se cobran a precio de API del modelo que seleccionas. Se requiere un plan de pago de Cursor para ejecutar agentes en la nube, y un administrador debe conectar primero el control de código fuente. Este es el panorama de costes en términos sencillos.
| Qué | Cómo funciona | La trampa |
|---|---|---|
| Requisito de plan | Se necesita un plan de pago de Cursor para ejecutar agentes en la nube | El plan gratuito no puede ejecutar Projects en la nube |
| Unidad de facturación | Los agentes en la nube facturan a precio de API del modelo elegido | El coste sigue a los tokens usados, no a una cuota mensual fija |
| Paralelismo | El coordinador ejecuta tantos subagentes como requiera el trabajo | Cinco subagentes en paralelo ≈ cinco veces los tokens |
| Control del gasto | Fijas un límite de gasto en el primer uso | El límite es la protección; por defecto no hay un tope fijo |
| Automatizaciones | Las suscripciones se facturan según el uso de agentes en la nube y usan la ventana de contexto máxima de cada modelo | Sin opción de contexto, así que las ejecuciones en segundo plano pueden consumir muchos tokens |
Un ejemplo práctico lo hace concreto. El Project de «gardening» del sistema de diseño que describe Cursor va camino de tocar entre 20 y 100 PR al día. Cada una de esas ejecuciones es un agente en la nube (a menudo varios subagentes) que factura a tarifas de API del modelo, todo el día, lo estés mirando o no. Eso puede ser un gran negocio frente al tiempo de un ingeniero, o una factura sorprendente, dependiendo por completo de tu límite de gasto y de lo verbosos que sean los modelos. Por eso el panorama completo de precios de Cursor importa más que nunca con Projects, y por eso las preocupaciones por el coste basado en uso son el tema recurrente en las reacciones de la comunidad, lo que nos lleva a la parte interesante.
¿Es un «cockpit para flotas de agentes» lo que los desarrolladores realmente quieren?
Aquí quiero ser justo, porque la reacción el día del lanzamiento no fue solo aplauso. El post de lanzamiento logró 5.861 me gusta, pero la respuesta más sonora al principio fue cansancio, no asombro:
"can you pls just merge the subscriptions instead of just adding extra features?"
Ese es el comentario principal del propio anuncio. Refleja una preocupación real: Projects apila otra superficie de pago y medida en la nube sobre un producto que ya está muy cargado. Y en abril de 2026, el redactor de producto Aakash Gupta resumió con claridad la apuesta estratégica (escribiendo sobre la dirección de Cursor, no sobre este lanzamiento concreto):
"Cursor's move is to go vertical on the orchestration layer... They're saying: the model is a commodity, the workflow is the moat. The question is whether developers want a dedicated cockpit for managing agent fleets, or whether the terminal where the model lives is enough."
Ese es todo el debate en dos frases. A algunos desarrolladores les encanta la superficie estructurada y revisable. Elliot Arledge, escribiendo en julio de 2026, expuso bien el argumento a favor:
"for most important dev and contracts I've been doing, cursor is my go-to and its not even close... being able to inspect code and ensure that production systems don't get slopified is super important to me."
La contra-ansiedad, en una respuesta dentro de ese mismo hilo, es la que creo que más merece tomarse en serio: «I really fear losing control over my codebase» (Temo de verdad perder el control de mi base de código). Cuanto más delega el coordinador, menos líneas ha leído realmente un solo revisor. Eso no es motivo para evitar Projects. Es un motivo para mantener tu disciplina de revisión exactamente donde estaba el primer día, sobre todo cuando el patrón «se sostiene» y te tienta ojear por encima. Si lo estás comparando con otras herramientas, nuestras comparativas de alternativas a Cursor y Cursor vs Windsurf explican dónde queda cada una.
Cómo se ve este modelo de «dirigir la flota» más allá del código
Esto es lo que más me llamó la atención construyendo sistemas de agentes en eesel: Cursor Projects es una instancia específica de programación de un patrón que aparece por todas partes. Un coordinador que planifica y delega, subagentes que hacen el trabajo, contexto compartido que se acumula y disparadores que lo ejecutan sin prompt. Cambia «base de código» por «cola de soporte» o «flujo de contenidos» y la arquitectura es la misma.
Así es exactamente como está construido eesel, solo que enfocado en otros trabajos. eesel es una plataforma de compañeros de equipo con IA, y contratas compañeros listos para trabajar en un rol concreto en lugar de un bot de propósito general. La plantilla actual es un compañero de helpdesk con IA y un redactor de blog con IA, cada uno con las habilidades, integraciones y contexto de empresa para su trabajo. El compañero de helpdesk se incorpora a tu cola actual y redacta o resuelve tickets; el redactor de blog investiga y escribe contenido extenso tal como se construyó este artículo. Es el mismo cambio de «tú diriges, el agente trabaja» que vende Cursor, pero dirigido a la automatización del servicio de atención al cliente y a los equipos de contenido SEO en lugar de a los pull requests.
Y como este artículo trata en realidad de flujos de trabajo agénticos basados en terminal, vale la pena explicar el paralelismo con la CLI. Cursor te deja manejar subagentes en la nube desde tu editor con comandos como /in-cloud y /autopilot. eesel ofrece el mismo tipo de superficie programable para sus compañeros: la CLI de eesel (@eesel/cli) es un binario real de npm cuya documentación dice literalmente «everything on this site can be done from the terminal». Puedes usar eesel integrations connect, editar las reglas permanentes del agente con eesel instructions, controlar acciones de riesgo con eesel approvals y ver cada ejecución, de más reciente a más antigua, con eesel activity. Cada comando imprime JSON y admite --dry-run, así que encaja directamente en la CI, y cada workspace es además un servidor MCP, conectado como cualquier otra integración MCP, lo que significa que un agente de programación como Cursor, Claude Code o Codex puede operar directamente a tu compañero de soporte o de contenido. Esa vista de observabilidad eesel activity se corresponde casi uno a uno con el «bring the finished work back to you to check» de Cursor.
El único punto en el que un compañero de soporte o de contenido tiene que ir más lejos que un coordinador de código: no puedes «revisar cada PR» cuando el agente habla con un cliente real. Por eso eesel te permite simular a un compañero con tus tickets históricos reales antes de que responda nunca, y mantener las acciones tras aprobaciones hasta que confíes en él. Es la misma lección que señalan los escépticos de Cursor, aplicada a un trabajo que llega directo a una persona.
Prueba eesel
Si Cursor Projects te convenció del modelo de «dirigir una flota de agentes, no vigilarlos» y gestionas un equipo de soporte o de contenido, eso es exactamente lo que eesel hace para esos trabajos. Conectas un compañero de helpdesk con IA a Zendesk, Freshdesk, Gorgias o Slack, aprende tu historial y tu centro de ayuda y empieza a redactar y resolver tickets; o apuntas el redactor de blog con IA a tu flujo de contenidos en lugar de unir por separado varias herramientas de escritura con IA. Se maneja desde el panel o por completo desde el terminal con la CLI y el servidor MCP de eesel, y puedes simularlo con datos reales antes de ponerlo en marcha. Es gratis probarlo.
Preguntas frecuentes
¿Qué son Cursor Projects?
Cursor Projects, lanzado el 10 de septiembre de 2026, es una forma de llevar un gran volumen de trabajo (una funcionalidad, una migración, mantenimiento continuo) a través de un único hilo de Cursor. En lugar de abrir un chat nuevo por tarea, hablas con un agente coordinador que planifica el trabajo y lo delega en varios agentes que se ejecutan en paralelo.
¿Cuánto cuestan Cursor Projects?
No hay un precio aparte para Projects. Se ejecutan sobre los Cloud Agents de Cursor, que se cobran a precio de API del modelo que elijas, y necesitas un plan de pago para ejecutar agentes en la nube. Como un coordinador puede lanzar muchos subagentes a la vez, el coste depende del uso, no de una tarifa fija. Consulta nuestro desglose completo de los precios de Cursor para ver los detalles de los planes.
¿En qué se diferencia el agente coordinador de un chat normal de Cursor?
Un chat normal hace el trabajo delante de ti. El coordinador no escribe código él mismo; planifica, delega en subagentes y te devuelve el trabajo terminado para que lo revises. Es el mismo giro hacia la programación agéntica que ves en herramientas como OpenAI Codex y GitHub Copilot.
¿Pueden Cursor Projects funcionar sin que yo los vigile?
Sí. Projects usa «suscripciones» para que el coordinador pueda vigilar un canal de Slack, ejecutarse según un calendario o seguir tus PR y arreglar la CI sin necesidad de un prompt. Es la misma idea que los flujos de trabajo de agentes automatizados en otras herramientas. Para el soporte, los flujos de atención al cliente con IA de eesel funcionan con el mismo modelo basado en disparadores.
¿Son seguros Cursor Projects en una base de código de producción?
Pueden serlo, si mantienes a una persona en el circuito. Los subagentes pueden trabajar en ramas aisladas o en sus propias máquinas virtuales en la nube, y el coordinador devuelve el trabajo terminado para su revisión antes del merge. El riesgo real es revisar menos a medida que confías más. Si usas agentes en trabajo de cara al cliente, una herramienta como eesel te permite simular con historial real y condicionar las acciones a aprobaciones antes de empezar.