Cursor 3: una nueva era de programación con IA y agentes en paralelo

¿Qué hay de nuevo en Cursor 3?

La versión 3.0 prioriza la infraestructura por encima del pulido de UI. Esto es lo que realmente cambió.

Espacio de trabajo unificado para agentes

Toda la actividad de los agentes vive ahora en una sola interfaz. La barra lateral muestra cada agente ejecutándose en tu máquina o en la nube, incluidos los iniciados desde Slack, GitHub, Linear, móvil y la web. Una sola vista.

El espacio de trabajo es multi-repo por diseño. Un agente puede actualizar componentes de frontend mientras otro parchea una librería de backend. Antes de Cursor 3, eso requería ventanas de IDE separadas y cambio de contexto constante.

Dos añadidos a destacar: las pestañas de agentes te permiten ver varios chats de agentes en paralelo o en cuadrícula. Los chats de agentes también son ahora pestañas estándar del editor, así que el panel dividido y los atajos de teclado funcionan como esperas. Nada que reaprender. El modo Diseño tiene su propia sección más abajo.

Ejecución de múltiples agentes en paralelo

El comando /best-of-n se ejecuta en el chat del agente dentro del IDE, no en la ventana de agentes. Para usarlo, abre un repositorio Git, abre Agent Chat en el diseño clásico del editor y ejecuta /best-of-n seguido de una lista de modelos separada por comas y tu tarea. Por ejemplo: /best-of-n sonnet, gpt, composer arregla el test inestable de logout.

Cursor crea un worktree de Git independiente para cada modelo, de modo que las ejecuciones no interfieran entre sí. Cuando termina el trabajo, puedes revisar los resultados, hacer commit y push desde el worktree elegido, o ejecutar /apply-worktree para traer los cambios a tu copia principal. También puedes personalizar la configuración de worktrees por proyecto mediante .cursor/worktrees.json.

Ahora Cursor canaliza las ejecuciones paralelas multi-modelo a través de /best-of-n en el chat del agente del IDE, mientras que el flujo de selección anterior deja de ser la vía recomendada.

El comando /worktree sigue el mismo camino: chat del agente en el IDE, repo Git requerido, worktree aislado por agente.

La elección de "best" refleja las heurísticas de evaluación de Cursor, no necesariamente las tuyas. Lee las salidas tú mismo.

Nota práctica: cada ejecución de modelo se factura de forma independiente a su tarifa normal por tokens, sin descuentos por volumen. Tres modelos implican tres cargos separados. Más adelante cubro el sistema de créditos con más detalle.

Transferencia entre agentes locales y en la nube

Los agentes en la nube se ejecutan en máquinas virtuales Ubuntu aisladas. La transferencia funciona en ambos sentidos.

Pasar de la nube a local te da acceso a tu sistema de archivos, servidor de desarrollo local y herramientas de prueba de escritorio. Empujar una sesión a la nube permite que tareas de larga duración sigan corriendo cuando cierras el portátil. Cuando el agente termina, los resultados te esperan en la ventana de agentes. Los agentes en la nube también generan demos y capturas de su trabajo, que puedes revisar antes de traer nada a local.

Las sesiones de agentes se mueven en ambos sentidos entre local y nube. Imagen del autor.

Para equipos enterprise, los agentes en la nube autogestionados están disponibles desde el 25 de marzo de 2026. El código, la ejecución de herramientas y los artefactos de build permanecen dentro de tu propia infraestructura. Un proceso worker se conecta saliente a la nube de Cursor por HTTPS, sin puertos entrantes ni VPN. Los agentes autogestionados están en el plan Enterprise; los agentes estándar en la nube están disponibles en Pro y superiores.

Puedes definir el entorno en la nube con un archivo .cursor/environment.json en la raíz del repo. Guarda los secretos en la pestaña Secrets de Cursor Settings, no en ese archivo.

Del commit al pull request en un mismo flujo

La nueva interfaz de diffs te permite ver cambios a nivel de palabra, preparar commits y abrir un pull request sin salir de la ventana de agentes. El renderizado de diffs de archivos grandes es más rápido y consume menos memoria en la 3.0.

Cuando usas /worktree en el editor clásico, cada agente trabaja en su propio worktree aislado, así que los diffs ya llegan limpios a la revisión. Nada de desenredar cambios solapados.

Cursor también anunció un acuerdo definitivo para adquirir Graphite, una herramienta de gestión de pull requests, el 18 de diciembre de 2025. Casi lo omito porque la integración no está confirmada, pero la compra podría redefinir este flujo cuando se cierre.

Modo Diseño y el navegador integrado

Describir un cambio de UI con texto es más lento que señalarlo. El modo Diseño lo soluciona.

Pulsa Cmd+Shift+D para activar una herramienta de selección sobre el navegador integrado. Usa Shift+drag para seleccionar un área, Cmd+L para inyectar un elemento seleccionado en el chat del agente, o Option+click para añadirlo al campo de entrada. El agente recibe el HTML, el CSS aplicado y el bounding box visual. En vez de escribir un párrafo explicando el problema de layout, seleccionas el elemento y le dices "ajusta esto".

El navegador incluye Chrome DevTools. Los agentes pueden levantar un servidor local, hacer clic en botones, leer la consola y verificar que sus cambios funcionan.

Composer 2: el modelo de código integrado de Cursor

Composer 2 se lanzó el 19 de marzo de 2026, dos semanas antes que Cursor 3. Es el modelo que impulsa a los agentes en el nuevo espacio de trabajo.

Está construido sobre una base Kimi K2.5 de Moonshot AI, con preentrenamiento continuo y un refuerzo por aprendizaje 4x por encima. Cursor no desveló el modelo base en el lanzamiento. Un usuario lo encontró en los headers del API al día siguiente. El cofundador Aman Sanger reconoció el olvido: "Fue un error no mencionar la base Kimi en nuestro blog desde el principio. Lo corregiremos para el próximo modelo".

Si los benchmarks no son lo tuyo, la versión corta es: Composer 2 es más rápido y barato que las alternativas de terceros. Salta a la tabla de precios más abajo.

En el propio CursorBench de Cursor, Composer 2 obtiene 61,3 frente a 44,2 de Composer 1.5, alrededor de un 39% más. Corre a más de 200 tokens por segundo, en parte gracias a kernels de GPU a medida que Cursor construye internamente en lugar de depender solo de pilas de inferencia de terceros. CursorBench no está auditado de forma independiente, así que tenlo en cuenta. GPT-5.4 lo supera en tareas más duras, pero en el trabajo de CursorBench (media de 352 líneas en ocho archivos), Composer 2 rinde mejor que Claude Opus 4.6 a un coste por token ~90% menor. Esa brecha de coste es el dato más interesante.

Aquí va el desglose de preciosn:

En planes individuales de pago, Composer 2 tiene su propio pool de uso separado de los créditos para modelos punteros seleccionados manualmente. Es basado en gasto, no por petición. El desglose completo de créditos está en la sección de precios. El modelo tiene una ventana de contexto de 200.000 tokens con auto-resumen: cuando se llena, comprime a ~1.000 tokens y sigue.

Composer 2 está hecho a medida para programación con agentes. Para lo demás no te servirá.

Cursor 3 como entorno de desarrollo con agentes primero

El CEO de Cursor, Michael Truell, ha descrito tres eras del desarrollo de software con IA. Primero llegó el autocompletado por Tab, que rellena código repetitivo. Luego los agentes sincrónicos, dirigiendo el modelo paso a paso. Ahora los agentes en la nube funcionan de forma autónoma durante más tiempo, con los desarrolladores actuando como directores más que como redactores.

Los datos de uso reflejan ese cambio. Como se dijo antes, la proporción agente-Tab se invirtió entre principios de 2025 y principios de 2026.

Según Truell: "Cursor ya no va principalmente de escribir código. Va de ayudar a los desarrolladores a construir la fábrica que crea su software". Es una visión, no una descripción de producto. La mayoría de desarrolladores que usan Cursor 3 hoy siguen revisando y corrigiendo la salida del agente constantemente. No he visto aún un código que se "auto-fabrica". Pero la interfaz está pensada para un futuro que podría estar más cerca de lo que parece.

Funciones clave que se mantienen y mejoran

Las funciones principales de versiones anteriores siguen y apenas cambian.

Archivos y comprensión del código

Se mantiene el soporte completo de Language Server Protocol (LSP). Ir a la definición, búsqueda de símbolos, documentación al pasar el ratón y navegación por archivos funcionan como en VS Code. Se admiten referencias de contexto como @Files, @Folders y @Docs. La ventana de agentes no elimina el acceso a nivel de archivo; añade una capa por encima.

Cursor Marketplace y plugins

El Marketplace de Cursor añade capacidades a los agentes con instalaciones de plugins en un clic. Un plugin agrupa alguna combinación de Skills (prompts que los agentes pueden invocar bajo demanda), Subagents, servidores MCP, Hooks y Rules. Desglose completo en la documentación de Cursor.

Hay plugins para casi todo: AWS, Figma, Linear, Stripe, Vercel, Datadog, Snowflake y más. Los planes Teams y Enterprise pueden configurar marketplaces privados de equipo. En Enterprise, la importación de plugins de terceros viene desactivada por defecto salvo que un admin la habilite.

Un hueco que no debería existir: no hay una UI integrada para definir variables de entorno para los servidores MCP de los plugins del Marketplace. El apaño es añadir el servidor manualmente a ~/.cursor/mcp.json con un campo env y desactivar la entrada duplicada en Cursor Settings. Funciona, pero es el tipo de cosa que no debería requerir un atajo en un producto de pago.

Automations

Automations, lanzadas el 5 de marzo de 2026, son agentes siempre activos que se disparan por eventos externos: horarios, mensajes de Slack, issues de Linear, eventos de GitHub e incidentes de PagerDuty. El agente levanta un sandbox en la nube y sigue instrucciones usando MCPs y modelos configurados. Cuando la memoria está activada, el agente accede a un bloc persistente (archivos de texto pequeños como MEMORIES.md que sobreviven entre ejecuciones). El agente decide qué anotar: progreso, patrones detectados, contexto de ejecuciones previas. La siguiente ejecución lee esas notas y continúa. Puedes ver y editar estos archivos en la sección Automations del panel.

Precios de Cursor 3 y requisitos por plan

No todas las funciones están disponibles en todos los planes. Aquí tienes el desglose actual:

Los agentes en la nube y Composer 2 requieren Pro o superior. Los marketplaces de equipo necesitan Teams o Enterprise, y los agentes autogestionados en la nube son solo para Enterprise.

Cursor maneja dos pools de créditos separados en los planes individuales de pago: uno para Auto mode y uso de Composer, descrito por Cursor como "generoso" sin tope publicado, y otro para modelos punteros seleccionados manualmente como Claude o GPT. Cuando eliges un modelo manualmente, tira del pool de créditos. Auto mode no.

Nota para uso intensivo: desarrolladores en el plan Pro que ejecutan sesiones de agentes con frecuencia informan de un gasto real más cerca de $40 a $50 al mes cuando entran los excesos. Los $20 son el suelo.

Cómo cambia Cursor 3 los flujos de trabajo de desarrollo

Aquí tienes una comparación concreta para una tarea estándar de backend API:

El cambio no es de difícil a fácil. Es de escribir a dirigir. Pasas menos tiempo implementando y más tiempo definiendo requisitos y revisando la salida. Si compensa depende de la tarea y, siendo honestos, de cuánto confíes en el agente ese día.

Las tareas largas son las que más ganan. Un refactor que te llevaría horas en terminal se lo pasas a un agente en la nube, cierras el portátil, el agente continúa y los diffs te esperan a la vuelta.

Cursor 3 vs. versiones anteriores de Cursor

El Cursor temprano (2022 a 2024) era una herramienta con el IDE primero. Edición de archivos asistida por IA en un entorno VS Code.

Cursor 1.0 (junio de 2025) fue la primera versión estable. Cursor 2.0 (octubre de 2025) trajo el primer modelo Composer y el navegador integrado. Cursor 2.5 (febrero de 2026) añadió subagentes asíncronos y el marketplace de plugins. Cursor 2.6 (marzo de 2026) añadió marketplaces de equipo.

Cursor 3.0 hace oficial el cambio. Los agentes en la nube se han movido fuera del Editor y ahora viven exclusivamente en la ventana de agentes. El soporte de worktrees también cambió: el antiguo menú desplegable quedó obsoleto y se sustituyó por los comandos /worktree y /best-of-n , que corren en el chat clásico del editor. Si tienes documentación interna sobre cómo usar el desplegable de worktrees o arrancar agentes en la nube desde el Editor, está desactualizada.

Cursor aprovechó la 3.0 para saldar deuda de rendimiento de la 2.x: parches de fugas de memoria y CPU, React Compiler. Robinson describe el resultado como más rápido y menos propenso a tirones de UI. Windows está totalmente soportado y la interfaz maneja múltiples espacios de trabajo en una sola ventana.

El salto de 2.x a 3.0 es más estructural de lo que parece. Las versiones anteriores añadían funciones de agente a un IDE. Cursor 3 añade un IDE a una plataforma de agentes. El orden importa.

Cursor 3 vs. IDE tradicionales

Los IDE tradicionales son file-céntricos. Abres un archivo, editas texto y el IDE te ayuda a teclear más rápido. Incluso con GitHub Copilot, la abstracción sigue siendo el documento.

Cursor 3 relega el archivo a un segundo plano. La interfaz principal es la cola de tareas. El IDE pasa a ser el recurso de apoyo para ediciones demasiado específicas como para describirlas en un prompt.

La comparación, eso sí, se está difuminando. GitHub Copilot ya ofrece agentes en la nube y revisión de código en planes individuales. JetBrains incluye Junie, su agente autónomo, con suscripciones de IA. Y como ya se dijo, Cursor ahora corre dentro de IDEs de JetBrains vía ACP. Todos tienen agentes. La diferencia de Cursor 3 es que el espacio de trabajo se construyó alrededor de ellos, no añadido a un editor existente.

Limitaciones y preguntas abiertas

La experiencia diaria tiene más fricción de la que sugieren los materiales de lanzamiento.

Supervisión del desarrollador

Los agentes se equivocan. En tareas complejas de varios archivos, se equivocan bastante. Revisar su salida requiere conocer el código lo suficiente como para detectar supuestos incorrectos, funciones inventadas y lógica que casi funciona. El tiempo ahorrado escribiendo se mueve a leer y validar. Si no puedes leer el código generado para comprobarlo, no podrás mantener el código funcionando. No es un reproche a Cursor; aplica a cualquier herramienta de programación con agentes.

Fiabilidad de los agentes en la nube

Los fallos de configuración de entornos son un problema documentado y persistente. No se pueden inyectar secretos durante el script de configuración inicial, solo después. Sesiones paralelas prolongadas consumen muchos recursos; hay informes de RAM elevada en máquinas que deberían soportarlo. Mantén las sesiones por debajo de dos horas si puedes, y añade checkpoints de reindexado para algo más largo.

Otro hueco concreto: Plan Mode aún no está disponible en la web de Cursor. Puedes iniciar y ejecutar agentes en la nube, incluido el plan, desde la app de escritorio de Cursor 3, pero no directamente desde cursor.com/agents.

También hay un bug conocido en el que los agentes se quedan colgados cuando la ventana de agentes no está en primer plano. Se reportó poco después del lanzamiento y seguía sin resolverse a principios de abril de 2026. Para una herramienta basada en sesiones largas, es un problema real.

Sobre agentes en paralelo en general: una investigación de Google DeepMind sobre sistemas multiagente encontró amplificación de errores de hasta 17,2 veces en redes no estructuradas. Incluso con un 99% de fiabilidad por agente, diez agentes encadenados caen a ~90% global. El comando /best-of-n usa worktrees aislados, lo que limita parte de esto. No lo elimina.

Consideraciones de seguridad

Se encontraron y parchearon dos CVEs en 2025. CVE-2025-54136 (MCPoison) permitía que herramientas MCP aprobadas tuvieran sus comandos modificados en silencio; parcheado en la versión 1.3. CVE-2025-64106 era una vulnerabilidad RCE por deep-link con severidad 8,8, parcheada en dos días. Workspace Trust también está desactivado por defecto. Si conectas herramientas MCP en un entorno sensible, importa.

Los agentes en la nube autogestionados, como comenté, mantienen el trabajo del agente dentro de tu red, pero la plataforma Cursor no está disponible como despliegue on‑prem completo. Cursor no tiene certificación FedRAMP ni HIPAA. La disponibilidad de BAA no está documentada públicamente, así que confirma directamente con Cursor antes de tomar decisiones de compliance. Si tu entorno requiere FedRAMP o despliegue totalmente on‑prem, Cursor 3 no encaja.

Otras dos limitaciones prácticas: el modo Diseño solo funciona en Chrome; Firefox y Safari no están soportados. Y en los días posteriores al lanzamiento de Cursor 3, la comunidad reportó consumos de tokens de Composer 2 ~10 veces superiores a lo normal para algunos usuarios, ligados a problemas de lectura de caché.

El modelo de créditos

Como comenté en la sección de agentes en paralelo, cada modelo en /best-of-n se cobra por separado. Una comparación de tres modelos en una tarea compleja puede agotar gran parte de tu pool mensual en una sola sesión.

¿Quién debería usar Cursor 3?

Si ya trabajas con flujos asistidos por agentes y quieres tenerlo todo en un mismo sitio, esto está hecho para ti. Tiene más sentido para equipos que trabajan en múltiples repos, para tareas largas que puedes delegar a la nube y para equipos enterprise que necesitan que el código permanezca en su infraestructura.

No lo recomendaría para principiantes. No porque sea difícil de usar, sino porque los agentes generan código que tienes que leer con criterio. Si no detectas cuándo está mal, no podrás arreglarlo, y seis meses después el repositorio lo mostrará. Para scripts simples o tareas puntuales, la preparación tampoco compensa. Y si tu entorno está regulado por HIPAA o es aislado, revisa la sección de seguridad antes de seguir.

Los monorepos heredados y muy grandes también son un problema real. Las ventanas de contexto siguen rompiéndose en ellos.

El futuro de la programación con IA en Cursor

En febrero de 2026, Cursor publicó "Towards Self-Driving Codebases", describiendo experimentos con miles de agentes orquestados en grandes bases de código. El objetivo declarado: "hasta que las bases de código se autoconduzcan".

Las ventanas de contexto siguen rompiéndose en monorepos grandes. Los agentes alucinan con frecuencia. La visión está lo bastante lejos como para no planificar en torno a ella.

Lo que sí hace Cursor 3 es poner las piezas principales: un modelo (Composer 2), una interfaz (ventana de agentes), VMs en la nube como runtime y opciones autogestionadas para enterprise. La base de código autodirigida depende de mejoras de modelo que Cursor no controla del todo.

La idea de la "fábrica" de Truell aún está lejos. Por ahora, sigues siendo tú quien supervisa la línea.

Conclusión

El gran cambio de Cursor 3 no es una función. Es que la interfaz se ha reconstruido sobre otra premisa: que el agente, y no el archivo, es la unidad de trabajo. Hace dos años era una apuesta. Los datos de uso apuntan a que sale bien.

Que encaje o no en tu flujo depende de cosas que no puedo saber desde aquí: tamaño del código, requisitos de seguridad y si puedes convivir con un producto recién lanzado que aún tiene aristas. Si dudas, vuelve a leer la sección de limitaciones antes de decidir.

Si quieres ir más allá con Cursor en la práctica, nuestro curso Software Development with Cursor cubre prompting, refactorización, testing y flujos con agentes.