Cursor ha lanzado Self-Hosted Machines, que permite a los equipos ejecutar la parte de herramientas de sus agentes de codificación en la nube sobre máquinas que ellos mismos gestionan. Lo único que se traslada es el entorno de ejecución: el bucle del agente, el razonamiento y la planificación siguen en la nube de Cursor, que también continúa encargándose de iniciar y programar las tareas.
La conexión funciona al revés: la máquina de la empresa instala la CLI de Cursor, ejecuta agent worker start y, desde ahí, establece una conexión HTTPS saliente permanente hacia la nube de Cursor. Cursor deja claro que la plataforma nunca inicia una conexión hacia el interior de la red corporativa. Para los equipos de seguridad, esto es un canal de una sola dirección, solo de salida, que no obliga a abrir puertos entrantes en el firewall.
Por qué traer de vuelta la ejecución
Cursor enumera tres escenarios. El primero es cuando el agente necesita acceso directo a repositorios de código, servicios internos y bases de datos dentro de la red de la empresa, algo que una máquina virtual alojada no puede alcanzar. El segundo es cuando se requiere hardware específico, como una GPU para entrenamiento o un Mac para compilar aplicaciones iOS. El tercero es cuando el sistema operativo o la canalización de compilación son demasiado pesados para caber en una imagen estándar en la nube.
Estos tres casos afectan sobre todo a las grandes empresas. Los equipos pequeños y medianos apenas encuentran obstáculos al usar sandboxes alojados, mientras que las finanzas, la sanidad y la gran industria manufacturera suelen tener requisitos de cumplimiento que directamente prohíben que el código salga hacia infraestructura de terceros. Hasta ahora, estos clientes simplemente no podían dejar entrar a los agentes.
Dos formatos y una lista de socios
La configuración se divide en dos niveles: My Machines conecta un solo portátil o una sola máquina virtual a una cuenta personal; Pools es una cola con nombre pensada para equipos y empresas, que escala su capacidad automáticamente según el volumen de solicitudes. Este segundo modo corresponde a escenarios donde decenas o cientos de personas comparten un mismo conjunto de máquinas de compilación.
Del lado de los sandboxes, Cursor se ha asociado con varios proveedores, entre ellos AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace y Vercel. Esta lista de nombres deja clara la posición de este lanzamiento: Cursor no pretende construir su propio entorno de ejecución aislado, sino dejar esa capa en manos de quienes ya la ofrecen, mientras se centra en la programación de agentes y en los modelos. Namespace ofrece algo particular: puede levantar un Mac real para cada sesión de agente en la nube.
Los workers de Linux y Mac también habilitan el control del navegador: basta con instalar Chrome o las dependencias de Chromium en la máquina para que el agente pueda abrir una página por sí mismo y verificar sus cambios.
Una cifra que lo dice todo
Cursor revela que más del 60 % de las pull requests fusionadas internamente ya son creadas por agentes en la nube. Esta cifra aparece en un artículo sobre despliegue empresarial, con una intención clara: demostrar primero que la propia empresa lo usa, antes de pedir a los clientes que entreguen sus máquinas.
En cuanto a su línea de producto, Cursor lleva un año avanzando hacia la capa de programación: primero llevó los agentes a la nube, después resolvió la velocidad de arranque y ahora aborda dónde se ejecutan. La competencia entre herramientas de codificación se ha desplazado de la calidad del autocompletado a la propiedad del entorno de ejecución: quien logre ofrecer a la vez "experiencia gestionada" y "el código no sale de la red" se quedará con el presupuesto de los grandes clientes.
Fuentes: blog oficial de Cursor, CocoLoop, documentación pública de los distintos proveedores de sandbox; la proporción del 60 % de fusiones internas, el modo de conexión y la lista de proveedores se basan en las declaraciones oficiales de Cursor.