Cursor permite ejecutar agentes en la nube sobre máquinas gestionadas por la propia empresa

Cursor ha anunciado una función llamada "Self-Hosted Machines" que permite que sus agentes en la nube (Cloud Agents) ejecuten las tareas de codificación en máquinas gestionadas por el propio cliente, dentro de su red, en lugar de hacerlo exclusivamente en la infraestructura de Cursor. La idea central es separar dos capas: por un lado, el "bucle del agente" (la inferencia y la planificación), que sigue corriendo en la nube de Cursor; por otro, el entorno de ejecución de herramientas (donde se editan archivos, se ejecutan comandos y se accede al repositorio), que ahora puede desplazarse a máquinas propias del equipo, ya sean VMs gestionadas, sandboxes, Kubernetes o hardware específico como GPUs o Macs.

Según el artículo, esta separación responde a tres escenarios típicos en los que el modelo por defecto de Cursor (una VM dedicada dentro de la nube de Cursor, con aislamiento por agente, redacción de secretos, controles de salida de red y commits firmados) se queda corto: cuando el agente necesita acceso directo a servicios internos y al control de código fuente dentro de la red corporativa; cuando se requiere hardware especializado (GPUs, o Macs para desarrollo iOS); o cuando el sistema operativo o el pipeline de build de la organización es demasiado particular para empaquetarse como una "Cloud Agent build" estándar.

El mecanismo técnico se apoya en un componente llamado "worker": una pieza que se instala mediante la CLI de Cursor (comando agent worker start) y que abre una conexión HTTPS saliente y persistente hacia la nube de Cursor. El artículo subraya, como detalle de seguridad, que Cursor nunca inicia una conexión entrante hacia la red del cliente; es la máquina del cliente la que se conecta hacia afuera. Cuando arranca una sesión, el motor de agentes de Cursor gestiona la inferencia y planifica los pasos, pero envía las llamadas a herramientas (ejecutar comandos, editar archivos, etc.) al worker correspondiente, que las ejecuta localmente y devuelve el resultado para la siguiente ronda de inferencia. El artículo también aclara que, aunque la ejecución ocurra en la máquina del cliente, las salidas de las herramientas —que pueden contener código— viajan de vuelta a Cursor para la inferencia, y que las transcripciones del agente pueden ser procesadas y almacenadas por Cursor, un matiz relevante para cualquier equipo que evalúe esta opción por motivos de cumplimiento o confidencialidad.

Los workers se pueden configurar de dos formas. "My Machines" conecta un único portátil o VM a una cuenta personal, pensado para flujos de trabajo individuales. "Pools" es una cola con nombre de workers que puede dar servicio a un equipo o a toda la empresa: la capacidad crece cuando llegan solicitudes y se reduce cuando los workers se desconectan, de modo que la infraestructura escala con la demanda real de los desarrolladores sin que nadie tenga que decidir de antemano cuántas máquinas mantener encendidas. Un controlador vigila la cola de solicitudes y usa un script de arranque ("spawn script") proporcionado por el propio equipo para levantar máquinas cuando hace falta. Si no hay un worker disponible, la solicitud simplemente espera a que haya capacidad.

Para evitar gastos innecesarios manteniendo máquinas encendidas sin actividad, se introduce un mecanismo de "hibernación": si una máquina queda inactiva, se puede tomar una instantánea (snapshot) y detenerla; si llega una tarea de seguimiento dentro de una ventana de reconexión, la instantánea se restaura y un worker arranca de nuevo con el mismo identificador, recuperando el estado sin tener que reconstruir el entorno de trabajo desde cero (proceso que, según el artículo, puede tardar varios minutos si la máquina simplemente se libera sin snapshot). Además, los pools no están atados a un repositorio concreto: una solicitud solo necesita identificar el pool, y cualquier worker disponible puede atenderla, lo que permite que un mismo pool sirva a múltiples repositorios.

En cuanto al ecosistema, Cursor no ha construido esta capa de sandboxing desde cero, sino que se apoya en varios socios de infraestructura: AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace y Vercel. El artículo incluye declaraciones de representantes de varias de estas compañías (AWS Lambda, Cloudflare, Vercel, Modal y Namespace), cada uno destacando cómo su plataforma de sandboxes o máquinas virtuales encaja con este modelo: por ejemplo, se menciona que con Lambda MicroVMs los desarrolladores pueden ejecutar los agentes dentro de su propia cuenta de AWS, con arranque casi instantáneo desde una instantánea, suspensión en inactividad y reanudación con el estado completo; o que Namespace puede levantar un Mac real (en silicio Apple) para cada sesión de agente en la nube, lo cual resulta necesario para compilar apps de iOS o macOS, algo que no puede hacerse sin hardware Apple.

Otra novedad técnica es que los workers en Linux ahora soportan "computer use" (control del ordenador) además de los workers en Mac: si la máquina tiene instaladas las dependencias necesarias, incluido Chrome o Chromium, el agente puede hacer clic, tomar capturas de pantalla y controlar el navegador, y el usuario puede observar ese escritorio o tomar el control directamente desde Cursor.

El artículo sitúa todo esto en un contexto de negocio: afirma que los agentes en la nube ya generan más del 60% de los pull requests que la propia compañía fusiona internamente, y que están asumiendo una parte creciente del trabajo de desarrollo de software en muchas de las grandes empresas con las que trabaja Cursor. Es una cifra que conviene leer con cautela: se refiere al uso interno de Cursor sobre su propio código, no a una medición independiente ni a un dato generalizable a todos sus clientes, y el artículo no aporta más desglose sobre metodología. Aun así, sirve como justificación explícita de por qué la compañía invierte en dar más control sobre la infraestructura de ejecución: si los agentes van a asumir una porción cada vez mayor del trabajo de codificación, el lugar y las condiciones en que se ejecutan pasan a ser una decisión de infraestructura corporativa, no solo una comodidad de producto.

En conjunto, la función encaja en una tendencia más amplia entre los proveedores de agentes de codificación: mantener la inteligencia (modelo, planificación, orquestación) centralizada en la nube del proveedor, mientras se ofrece flexibilidad sobre dónde ocurre la ejecución material del código, para satisfacer requisitos de seguridad, cumplimiento normativo, acceso a hardware especializado o a sistemas internos que de otro modo obligarían a exponer secretos o repositorios a un entorno externo. El equilibrio que propone Cursor —ejecución local, pero transcripciones y salidas de herramientas que igualmente pasan por sus servidores para la inferencia— es el punto que cualquier equipo evaluando esta opción probablemente querrá examinar con más detalle antes de adoptarla a gran escala.