Cursor Projects, que se lanzó el 10 de septiembre de 2026, es la respuesta de Cursor a un problema real: un chat de IA normal lo olvida todo en cuanto lo cierras. Un Project mantiene un agente coordinador en marcha durante semanas, y ese coordinador no escribe código él mismo. Planifica el trabajo, lo delega en una flota de subagentes en la nube y te devuelve pull requests para revisar. También puede funcionar solo, vigilando un canal de Slack o tus PR abiertos.
Como trabajo construyendo agentes de IA que hacen trabajo real, mi lectura honesta es esta: el modelo de coordinador es la idea correcta, y el "contexto compartido que crece" es la parte que de verdad importa. El problema es el modelo de costes. Pagas tarifas de API por cada subagente, y un coordinador que lanza muchos en paralelo es una cuestión de facturación, no productividad gratis. Ideal para migraciones y mantenimiento de largo plazo; excesivo para un arreglo rápido.
Un matiz que conviene tener claro antes de seguir: Cursor es infraestructura para construir software, no un compañero que hace un trabajo. Si quieres una IA que asuma un rol desde el primer día (soporte, contenido), es otra categoría, y explicaré dónde se encuentran ambas.
Qué es realmente Cursor Projects
Si has usado Cursor, conoces la forma de una sesión: abres un chat, describes una tarea, el agente edita archivos, revisas y sigues adelante. Cierras la pestaña y ese contexto desaparece. Para un arreglo de 20 minutos, está bien. Para una migración de tres semanas, acabas reexplicando tu código a un agente nuevo una y otra vez.
Projects está pensado para el segundo caso. Cursor lo describe como una forma de "abordar trabajos más grandes, como una función, una migración o una app completa", donde el Project "mantiene el contexto durante meses de trabajo" y "realiza trabajo recurrente sin que se lo pidan". Es el producto concreto detrás de la visión de la "tercera era del desarrollo de software" que Cursor lanzó en febrero: dirigir una flota de agentes en lugar de cuidar un solo chat.
Cursor dice que lleva meses usando Projects internamente, incluidas migraciones de varios cientos de PR, y que con uno envió el propio Projects. Su cifra principal: los usuarios nuevos fusionan un 30 % más de PR, y los usuarios intensivos de Projects fusionan seis veces más. Es una cifra interna y autodeclarada, así que trátala como cualquier estadística de productividad de un proveedor, pero sí indica qué optimiza el producto: el volumen de trabajo fusionado, no las líneas tecleadas.
Todo está en beta y se está desplegando para todos los usuarios desde el día del lanzamiento. Empiezas uno desde la navegación izquierda, describes lo que quieres construir y el coordinador se encarga del resto.
El agente coordinador: el verdadero cambio
Esta es la parte que subrayaría. Cuando abres un Project, no hablas con un agente de programación. Hablas con un coordinador, y según el changelog de Cursor, "el agente coordinador de un project no escribe código él mismo; planifica el trabajo, lo delega en agentes que lo implementan y te devuelve el trabajo terminado para que lo revises."
Parece una distinción pequeña. No lo es. Como el coordinador delega en lugar de ejecutar, Cursor dice que "nunca está bloqueado y siempre responde a las indicaciones." Quien haya visto a un único agente masticar una tarea larga conoce la frustración: quieres redirigirlo, pero está en plena edición y no hay forma de alcanzarlo. Un coordinador lo evita porque nunca es quien tiene las manos en el código. Crea y gestiona agentes en tu nombre, ejecutando en paralelo tantos como el trabajo necesite, y Cursor plantea el techo como dirigir "miles de agentes a través de un coordinador".
Por debajo, esto se apoya en el sistema de subagentes que Cursor ya tenía, y conviene entenderlo porque explica tanto la potencia como el coste. Cada subagente "opera en su propia ventana de contexto", empieza de cero, trabaja de forma autónoma y "devuelve su resultado al agente padre". Pueden ejecutarse en paralelo, y desde Cursor 2.5 un subagente puede incluso lanzar sus propios subagentes hijos, aunque el árbol termina ahí: un subagente hijo no puede lanzar más. Si pides aislamiento, cada uno recibe su propio Git worktree o una VM en la nube dedicada con su propio clon del repositorio, de modo que los agentes en paralelo no se pisan. Los cambios permanecen en ramas separadas hasta que el padre los fusiona.
La contrapartida honesta, directa de la documentación de Cursor: ejecutar cinco subagentes en paralelo usa aproximadamente cinco veces los tokens de un solo agente, y en tareas simples pueden ser más lentos, porque cada uno empieza de cero. Lo que compras es aislamiento de contexto, no velocidad. Es justo que Cursor lo diga en voz alta, y es la frase a la que yo asociaría una alerta de gasto.
Nube por defecto: dónde se ejecuta realmente el trabajo
Un Project se ejecuta en la nube, no en tu portátil. La fórmula de Cursor es "nube por defecto, local cuando haga falta." Un Project "se ejecuta en su propio ordenador, así que cerrar tu portátil no lo detiene", lo que le permite "ejecutar más subagentes en paralelo de los que soportaría tu portátil". Cuando algo realmente necesita tu máquina, el coordinador lanza un agente local para ejecutarlo allí.
Esto se construye sobre los Cloud Agents, la infraestructura que Cursor llamaba Background Agents: VM aisladas con entornos de desarrollo completos que clonan tu repositorio desde GitHub, GitLab, Azure DevOps o Bitbucket, trabajan en una rama y devuelven PR listos para fusionar con artefactos como capturas de pantalla y registros. Incluso puedes controlar el escritorio remoto de un agente para probar el software modificado sin descargar la rama en local.
El paso de configuración que la gente subestima es el entorno. Cursor lo dice sin rodeos: "no configurar un entorno de desarrollo para tus agentes en la nube es como no darle un ordenador a tus ingenieros." Lo configuras con un Dockerfile o una instantánea guardada, y si lo omites, tus agentes trabajan a ciegas. Si alguna vez has incorporado a un nuevo empleado y has visto cómo pierde un día por una configuración local rota, ya sabes por qué importa; es el mismo impuesto, pagado una vez por Project.
Contexto compartido: lo que se acumula
Esta es la función que creo que está realmente infravalorada, y la que hace que Projects sea más que "agentes en segundo plano con un nombre más bonito".
La frase de Cursor es que "no deberías tener que incorporar a un agente cada vez que empiezas una tarea." Así que cada Project mantiene un conjunto de archivos que se sincronizan en todas las máquinas, en la nube y locales, que usan sus agentes. Los agentes escriben investigación, artefactos y "lo que aprenden sobre el código y cómo prefieres que se haga el trabajo" en ese contexto compartido. El ejemplo de Cursor: si un agente descubre cómo probar un servicio, todos los agentes futuros pueden usar esas instrucciones.
Ese es el efecto acumulativo. El contexto "crece con el Project y hace al coordinador más eficaz con el tiempo". Es la diferencia entre contratar a un colaborador que olvida tu código cada mañana y uno que lleva un mes en el equipo. He construido sistemas donde todo el juego consiste en dar a un agente el contexto correcto de la empresa desde el principio, y puedo decirte que la segunda versión vale mucho más de lo que parece en una diapositiva de lanzamiento. También es la función menos llamativa del anuncio, lo que suele ser señal de que es la importante.
Subscriptions: Cursor Projects en piloto automático
El otro titular es que un Project puede actuar sin ti. Cursor lo llama Subscriptions, y el coordinador puede "vigilar un canal de Slack, ejecutarse según un horario o seguir todos tus PR, arreglando la CI y actuando cuando se abren o se fusionan." El ejemplo concreto del changelog: conectar Slack, apuntarlo a un canal de reportes de errores, y el coordinador empieza a delegar un arreglo cada vez que llega un error.
Por debajo está el sistema de Automations de Cursor, que es más capaz de lo que deja ver el blog de Projects. Los disparadores pueden activarse con un horario cron, con eventos de control de código fuente (PR abierto, enviado, fusionado, CI completada), con mensajes de Slack o reacciones con emoji, con un webhook al que envíes datos o con eventos de Linear, Sentry y PagerDuty. Una automatización puede entonces abrir PR, comentar, solicitar revisores, publicar en Slack, usar servidores MCP y mantener notas persistentes en un archivo MEMORIES.md entre ejecuciones.
Dos límites que conviene conocer antes de apoyarte en ello: solo los canales públicos de Slack son visibles para los disparadores de Slack por ahora, y los disparadores de PR no se ejecutan en PR de forks (salvo el disparador de fusionado). Ninguno es un impedimento, pero es el tipo de cosa que quieres descubrir antes, no después, de montar un flujo de trabajo alrededor.
Los tres trabajos para los que está pensado Cursor Projects
Cursor es refrescantemente específico sobre dónde encaja, y coincide con para lo que yo lo usaría realmente.
- Desarrollo de funciones. Un Project empieza con agentes investigando el sistema y registrando lo que aprenden; después el coordinador planifica y envía agentes a construir y probar partes en paralelo. Tras el lanzamiento, el mismo Project puede monitorizar registros y atender reportes de errores "con todo el contexto detrás de las decisiones originales". Esa última parte es la recompensa del contexto compartido.
- Migraciones. Cursor las llama "fáciles de empezar y difíciles de terminar", que es exactamente así. Estableces un enfoque seguro con el coordinador, y este lo aplica de forma incremental en todo el código. Revisas cada PR con atención al principio y luego te relajas a medida que los arreglos se sostienen.
- Gardening (mantenimiento). Trabajo que nunca termina: calidad del código, vigilar regresiones. El ejemplo real de Cursor es un Project de sistema de diseño donde el coordinador “escanea cada PR nuevo, extrae los componentes que pertenecen al sistema de diseño y añade una regla de lint cada vez que ve el mismo error dos veces”, en camino de tocar de 20 a 100 PR al día.
Si tu trabajo no se parece a uno de esos tres, probablemente un Project sea la herramienta equivocada. Aquí tienes la comprobación rápida que haría antes de abrir uno.
Cuánto cuesta Cursor Projects
Aquí frenaría un poco. No hay un precio de lista para Projects, y no es que Cursor esconda algo: es realmente por uso. Projects se ejecuta sobre Cloud Agents, y la facturación se deriva de ahí.
| Componente | Cómo se factura | Qué necesitas |
|---|---|---|
| Cursor Projects (la función) | Sin cargo independiente; en beta | Un plan de pago de Cursor |
| Subagentes en la nube | Precio de API del modelo seleccionado; fijas un límite de gasto en el primer uso | Control de código fuente conectado por un administrador |
| Subagentes en paralelo | Aproximadamente 5 veces los tokens para 5 agentes frente a 1 | Ser consciente de que el paralelismo multiplica el coste |
| Automations / Subscriptions | Se facturan como uso de agentes en la nube, al contexto máximo de cada modelo | Un plan de pago; las automatizaciones del equipo se cargan al fondo del equipo |
Lo que debes interiorizar: un coordinador que lanza muchos subagentes en paralelo es un multiplicador de costes, no una comida gratis. En un Project muy activo, "miles de agentes" es un techo de marketing, pero incluso un puñado de agentes en la nube en paralelo a tarifas de modelos de vanguardia suma rápido. Es justo la preocupación que apareció en las reacciones de la comunidad, y es legítima. Si ya eres de los equipos que vigilan el coste por resolución de un agente de IA, querrás la misma disciplina aquí: fija límites de gasto y trata las Subscriptions automatizadas como un contador en marcha.
Lo que dice la gente
El tuit de lanzamiento tuvo mucho éxito, 5.861 me gusta el primer día. Pero la reacción que me pareció más reveladora fue la respuesta más votada, publicada once minutos después:
"can you pls just merge the subscriptions instead of just adding extra features?"
Es la tensión del día del lanzamiento en una línea. Cursor va apilando capacidades, y algunos de sus usuarios más activos preferirían que simplificara lo que ya existe en lugar de lanzar otra superficie de pago. No es tanto una crítica a la función como una señal de que el paquete de coordinador, nube y subscriptions es mucha superficie nueva de golpe.
La pregunta estratégica más afilada vino del responsable de producto Aakash Gupta, que escribió sobre la dirección de Cursor hacia flotas de agentes en abril de 2026:
"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."
Creo que esa es la verdadera apuesta de Projects. Los modelos son cada vez más intercambiables, así que Cursor apuesta a que la capa de orquestación, el coordinador, el contexto compartido y los disparadores, es donde puede fidelizar. Que prefieras una cabina o una línea de comandos es cuestión de gustos, y ingenieros razonables acaban en ambos lados. Si estás sopesando esa decisión, nuestra comparativa de alternativas a Cursor y la comparación Cursor vs Windsurf cubren el espectro de "cabina vs terminal", igual que cualquier comparación con OpenAI Codex o la CLI de Claude Code.
Dónde encaja Projects y dónde no
Mi opinión tras revisar la documentación: Cursor Projects es la versión más coherente de "gestionar una flota de agentes" que he visto lanzarse, y el diseño del contexto compartido es la razón. El modelo de coordinador resuelve una molestia real, la ejecución en la nube es sensata, y la honestidad de la documentación sobre los costes de tokens y la lentitud de los subagentes genera confianza.
Donde frenaría: está en beta, el modelo de costes premia la moderación y todo asume que tu trabajo es grande y duradero. Para un desarrollador en solitario con ediciones rápidas, es más maquinaria de la que el trabajo necesita, y un chat simple es mejor herramienta. También agudiza una ansiedad real que una respuesta del hilo de lanzamiento expresó bien: cuanto más delega un coordinador, menos líneas de código ha escrito y revisado una persona. Projects depende mucho de que seas disciplinado al revisar los PR que te devuelve. Eso es una característica, no un fallo, pero depende de ti.
Y hay un punto de categoría que vale la pena señalar, porque fue en lo que más pensé mientras leía el anuncio.
Cursor es infraestructura; un compañero es otra cosa
Cursor Projects es infraestructura de programación agéntica. Construye tu software. No es un compañero que aparece y hace por ti un trabajo definido, y tampoco intenta serlo. Es una distinción real, no una crítica.
Así es exactamente como pienso en lo que construimos en eesel. eesel es una plataforma de compañeros de IA, y contratas compañeros listos para trabajar en tareas concretas: un compañero de IA para el helpdesk que se une a tu cola de soporte y un redactor de blog con IA. Cada uno llega con las habilidades, integraciones y contexto de empresa de su rol, y trabaja desde el día cero. Donde Cursor te da una cabina para construir software, eesel te da un colega que ya hace el trabajo.
Lo interesante es dónde se encuentran. Porque a Cursor Projects le encantan una CLI y un disparador, y a eesel también. La CLI de eesel es una forma amigable para agentes de operar el mismo compañero y espacio de trabajo de eesel que usarías desde el panel: una persona puede ejecutarla desde una terminal, los scripts pueden automatizarla y agentes de programación como Cursor, Claude Code y Codex pueden manejarla. Así, un Cursor Project que arregla tu app puede, de paso, pedirle a la CLI de eesel que inspeccione las instrucciones de tu compañero de soporte, proponga un cambio acotado y revise las respuestas de prueba antes de que una persona lo apruebe. El mismo instinto de contexto compartido, aplicado al compañero que atiende a tus clientes en lugar de al código que los sirve.
Si Projects te hace pensar en agentes que hacen trabajo real mientras duermes, ese es el instinto correcto. Para la parte de soporte y contenido de ese trabajo, ese es el hueco que llena eesel, y es gratis de probar.
Prueba eesel para el trabajo que un agente de programación no hará
Cursor Projects reconstruirá encantado tu flujo de facturación. Lo que no hará es responder a los 400 tickets de "¿dónde está mi reembolso?" que esas decisiones generan. Ese es el trabajo para el que se contrata a un compañero eesel de IA para el helpdesk: se conecta en minutos a Zendesk (y Freshdesk, Gorgias, Slack y más), aprende de tus tickets anteriores y tu centro de ayuda, y empieza a redactar o resolver desde el primer día. Es un agente de IA contratado para la cola, con un precio fijo por ticket en lugar de por puesto.
Y si vives en una terminal, no tienes que salir de ella. La CLI de eesel permite que tu agente de programación inspeccione y ajuste el mismo compañero eesel que usa el panel, de modo que la IA que envía tu código también pueda ayudar a afinar la IA que atiende a tus clientes. Puedes probar eesel gratis, sin tarjeta de crédito, y simularlo con tus tickets históricos reales antes de que toque una sola conversación en vivo.
Preguntas frecuentes
¿Qué es Cursor Projects?
Cursor Projects es una función lanzada el 10 de septiembre de 2026 que te permite llevar un trabajo largo (una función, una migración, una app entera) a través de un único agente coordinador. En lugar de abrir un chat nuevo por tarea, hablas con el coordinador, que planifica el trabajo, lo delega en subagentes en la nube y te devuelve los pull requests terminados.
¿Cuánto cuesta Cursor Projects?
Projects no tiene un precio aparte. Funciona sobre los Cloud Agents de Cursor, que se facturan a precio de API según el modelo que elijas, y necesitas un plan de pago de Cursor para ejecutarlos. Ejecutar cinco subagentes en paralelo consume aproximadamente cinco veces los tokens de un solo agente, así que fija un límite de gasto antes de escalar.
¿Vale la pena Cursor Projects para equipos pequeños?
Brilla en trabajos que duran más que un solo chat: migraciones, mantenimiento continuo o una función que vas a supervisar durante semanas. Para un arreglo puntual, un chat normal de Cursor es más barato y sencillo. Lee nuestra reseña completa de Cursor antes de comprometer a un equipo.
¿Puede Cursor Projects funcionar sin que yo le dé instrucciones?
Sí. Su capa de automatización, llamada Subscriptions, puede vigilar un canal público de Slack, ejecutarse según un horario o seguir tus pull requests y actuar cuando se abren o se fusionan. Es el mismo motor que las Automations de Cursor, que también se conectan con GitHub, GitLab, Linear, Sentry y PagerDuty.
¿Cuál es la diferencia entre Cursor Projects y un compañero de IA como eesel?
Cursor Projects es infraestructura de agentes para construir software. eesel es un compañero que contratas para un trabajo definido, como un compañero de IA para el helpdesk o un redactor de blog con IA, y que funciona desde el primer momento. Se complementan: un agente de programación como Cursor incluso puede manejar a un compañero eesel mediante la CLI de eesel.