Ejecuta cloud agents en máquinas que tú gestionas
Los cloud agents de Cursor pueden ejecutarse en grupos de máquinas asignados dinámicamente dentro de tu red. Tú gestionas la infraestructura subyacente, mientras que los agentes se siguen iniciando y gestionando desde Cursor.
Así, los equipos ganan más control sobre dónde se ejecutan los agentes y qué infraestructura usan. Los agentes pueden trabajar junto a servicios internos y al control de versiones, ejecutarse en hardware personalizado o usar sistemas operativos y pipelines de compilación difíciles de empaquetar como un Cloud Agent build.
Los cloud agents ya crean más del 60 % de las PR que fusionamos internamente y asumen una parte cada vez mayor del trabajo de software en muchas de las mayores empresas con las que trabajamos. A medida que crece su papel, también cobran más importancia las máquinas en las que se ejecutan. Estas nuevas capacidades hacen viable que los equipos proporcionen y gestionen esa infraestructura a gran escala.
Con las MicroVMs de Lambda como capa de compute para los Cloud Agents de Cursor, los desarrolladores pueden ejecutar agentes de programación con IA en su propia cuenta de AWS. Cada máquina se inicia casi al instante desde un snapshot, se suspende cuando está inactiva y se reanuda con todo su estado. Tus agentes de programación se benefician del arranque rápido de Lambda, un aislamiento sólido y cero gestión de flotas, mientras Cursor orquesta el trabajo.
Controla dónde se ejecutan los agentes
Los entornos alojados por Cursor siguen siendo la opción predeterminada para los cloud agents. Cada sesión se ejecuta en una VM dedicada dentro de la nube de Cursor, con sus dependencias instaladas y sus propios controles de red. El aislamiento por agente, la redacción de secretos, los controles de egress y los commits firmados cumplen los requisitos de seguridad de la mayoría de los equipos.
Por lo general, los equipos recurren a las Máquinas autoalojadas cuando:
- La ejecución de herramientas del agente debe producirse dentro de su red, con acceso directo al control de versiones, los servicios internos y los repositorios de código.
- Los agentes necesitan hardware personalizado, como GPU o Macs para desarrollo en iOS, o infraestructura como Kubernetes, sandboxes o VM gestionadas.
- Su sistema operativo o pipeline de compilación es difícil de empaquetar como un Cloud Agent build.
Con las Máquinas autoalojadas solo se traslada el entorno de ejecución: el agent loop, la inferencia y la planificación permanecen en la nube de Cursor. Los resultados de las herramientas vuelven a Cursor para la inferencia y pueden contener código, y Cursor puede procesar y almacenar las transcripciones del agente. Los equipos pueden seguir accediendo a los cloud agents desde la aplicación de escritorio, cursor.com, el móvil, Slack, GitHub y Linear.
Los workers conectan tu infraestructura al agent loop de Cursor
Con las Máquinas Autoalojadas, la ejecución de herramientas pasa de una VM alojada por Cursor a una máquina de tu entorno. Esa máquina contiene la copia de trabajo del repositorio, edita archivos y ejecuta comandos. Un worker es lo que la conecta con el resto del sistema del agente.
Para registrar una máquina, ejecuta un worker instalando el Cursor CLI y ejecutando agent worker start. Así se abre una conexión HTTPS saliente de larga duración con la nube de Cursor. Cuando comienza una sesión, el agent harness de Cursor se encarga de la inferencia y la planificación, y después envía las llamadas a herramientas a un worker dedicado para que las ejecute. El worker devuelve los resultados para la siguiente ronda de inferencia. Cursor nunca inicia una conexión hacia tu red.
Los workers se pueden configurar de dos maneras.
- Mis Máquinas. Esta configuración conecta un único portátil o VM a tu cuenta y resulta ideal para flujos de trabajo personales.
- Grupos. Un grupo es una cola de workers con nombre que puede dar servicio a un equipo o a una empresa. La capacidad aumenta a medida que llegan solicitudes y disminuye cuando los workers se desconectan, de modo que tu infraestructura en la nube actual escala con la demanda de los desarrolladores.
Los desarrolladores deberían tener la flexibilidad de ejecutar agentes de programación en la plataforma que mejor se adapte a su flujo de trabajo, y las empresas no deberían renunciar al control sobre dónde se ejecutan los agentes ni a qué pueden acceder. El futuro del desarrollo se construirá sobre agentes potentes, que se ejecutan en entornos seguros y aislados.
Los cloud agents se adaptan a tu infraestructura
Los grupos de workers ahora pueden escalar según las solicitudes en cola y atender trabajo de cualquier repositorio. También agregamos compatibilidad con varios proveedores de sandbox y con el uso del ordenador en Linux, además de Mac.
Los grupos escalan con la demanda y sirven a cualquier repositorio
La demanda de cloud agents suele llegar en ráfagas, y los grupos de Máquinas autoalojadas se ajustan a ellas automáticamente. Esto ocurre gracias a un controller que vigila la cola de solicitudes y utiliza un spawn script proporcionado por el equipo para iniciar máquinas según sea necesario.
Si un grupo tiene un worker disponible, ese worker toma la solicitud. De lo contrario, la solicitud espera hasta que se libere más capacidad, de modo que los equipos no tienen que decidir cuántas máquinas dejar en ejecución.
Los equipos pueden establecer un timeout de inactividad para cada conexión de worker. Cuando expira, la máquina puede reiniciarse y volver a incorporarse al grupo. Los equipos también pueden conservar su workspace por si el agente recibe un seguimiento.
Las Máquinas autoalojadas dan a los equipos el control sobre dónde se ejecutan los agentes de Cursor, y Vercel Sandbox lo hace muy sencillo. Cada tarea obtiene un sandbox aislado bajo demanda, sin una flota que gestionar y sin nada inactivo.
Dejar una máquina en ejecución mientras su agente está inactivo puede salir caro. Pero si se libera la máquina, el agente puede tardar varios minutos en reconstruir su workspace cuando llega un seguimiento. Con la hibernación, los equipos pueden tomar un snapshot y detener la máquina inactiva. Si llega un seguimiento dentro de la ventana de reconexión, se restaura el snapshot y un worker arranca con el mismo ID. De lo contrario, la solicitud puede pasar a una máquina nueva.
Los grupos no están ligados a repositorios concretos. Una solicitud solo necesita identificar el grupo, y cualquier worker disponible puede tomarla. Así, un mismo grupo puede servir a muchos repositorios.
Los workers se ejecutan en los proveedor de sandbox compatibles
Máquina autoalojada no requiere crear una capa de sandbox personalizada desde cero. Colaboramos con AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace y Vercel, lo que permite iniciar y orquestar workers allí donde ya se ejecutan los sandboxes del equipo.
Máquina autoalojada de Cursor en Modal asigna a cada sesión de Cloud Agent un Modal Sandbox, de modo que puedes entregarle una máquina hecha a medida para su tarea.
Los Agentes controlan navegadores en Linux y Mac
Los workers de Linux ya admiten el uso del ordenador, al igual que los Mac. Con las dependencias necesarias de uso del ordenador instaladas, incluido Chrome o Chromium, un agente puede hacer clic, tomar capturas de pantalla y controlar el navegador. Puedes ver su escritorio o tomar el control directamente desde Cursor.
No puedes crear aplicaciones de iOS o macOS sin un Mac. Los Devboxes de Namespace levantan un Mac real para cada Cloud Agent de Cursor, que ahora puede realizar ese trabajo en Apple silicon.
Lleva los cloud agents a tu entorno
Los equipos llevan años dando forma a su infraestructura en función de cómo crean software. Las máquinas autoalojadas permiten que los cloud agents encajen de forma más natural en ella, y nos entusiasma ver hasta dónde los llevarán los equipos.
Para conectar una máquina o configurar un grupo, empieza en la documentación.
