Agentes de IA autohospedados en Cursor: herramientas dentro de tu red
Cursor permite ejecutar herramientas de agentes de IA dentro de una red privada. Analizamos qué datos salen, cuánto cuesta y cuándo conviene autohospedar.
El cambio que Cursor presentó el 2 de septiembre de 2026 mueve a la vez el límite de seguridad y la factura de infraestructura: el equipo puede mantener la ejecución de herramientas de sus agentes de IA autohospedados en máquinas bajo su control, pero también pasa a administrar esos workers. El modelo, la planificación y el bucle del agente siguen ejecutándose en la nube de Cursor.
Cómo divide Cursor el entorno de los agentes de IA autohospedados
Un Cloud Agent de Cursor tiene dos mitades. El bucle del agente decide qué hacer a continuación e invoca el modelo. La ejecución de herramientas es la parte que modifica archivos, ejecuta comandos en la terminal, abre un navegador, se comunica con un servidor MCP local y accede a servicios internos.
Cursor Self-Hosted Machines separa esas dos mitades. Cursor conserva el bucle, la inferencia, la planificación, la interfaz y la coordinación de la sesión. Un worker administrado por el cliente ejecuta las herramientas.
Ese worker puede ser un equipo portátil, una máquina virtual, una Mac, un pod de Kubernetes o un sandbox de un socio de integración. Abre una conexión HTTPS saliente hacia Cursor, recibe las llamadas a herramientas, las ejecuta localmente y devuelve los resultados. Cursor no necesita ningún puerto de entrada ni una IP pública en el worker.
Así se reparten las responsabilidades.
Cursor ofrece dos modalidades de worker. My Machines vincula una máquina con la cuenta de una persona y encaja con un entorno de desarrollo o un flujo personal acotado. Team Pools son colas con nombre para equipos Enterprise. Cada solicitud espera en un pool hasta que un worker disponible la toma, y cada worker del pool atiende una sola sesión de Cloud Agent a la vez.
Esto no convierte a Cursor en una solución on-premise. Es un entorno dividido cuya mitad de ejecución pertenece al cliente. Esa diferencia determina si la función cumple o no con las políticas de la organización.
Qué permanece dentro de la red y qué datos siguen saliendo
El checkout completo, la caché de compilación y las credenciales locales de la máquina permanecen en el worker. Allí también se ejecutan los comandos, las operaciones del repositorio, las compilaciones y las llamadas a servicios internos. Así puede evitarse copiar un repositorio entero a una máquina virtual de ejecución administrada por un proveedor.
El agente sigue necesitando contexto para decidir. Durante una ejecución, el worker envía a Cursor el contenido de los archivos que el agente necesita, la salida de la terminal, los diffs, las capturas de pantalla, los resultados del MCP local y los metadatos de enrutamiento. También pueden cargarse capturas, videos y referencias de logs en el almacenamiento de artefactos administrado por Cursor para que aparezcan en los pull requests y en el panel.
Es posible bloquear el host de artefactos sin detener el agente, pero entonces esos artefactos dejan de aparecer en el pull request y en el panel. Privacy Mode también se aplica: Cursor y sus proveedores de modelos no usan para entrenamiento el código enviado desde el worker. Eso no convierte la sesión en una experiencia sin conexión.
Esa es la primera consecuencia para el negocio. Ahora una revisión de seguridad puede aprobar por separado el lugar de ejecución y el procesamiento del modelo, pero todavía debe aprobar ambos.
Quién puede aprovecharlo y qué implica para cada equipo
Un equipo de backend empresarial con servicios internos
Un equipo de backend puede necesitar un registro privado de paquetes, una base de datos de staging y endpoints de servicios inaccesibles desde una máquina virtual administrada. Un Team Pool puede operar en la misma red controlada y ejecutar la compilación sin abrir una ruta de entrada desde Cursor.
El beneficio está en el control de acceso, no en una privacidad automática. El equipo de plataforma puede conservar sus políticas de red y su almacén de secretos, mientras el equipo de seguridad revisa con precisión qué resultados atraviesan la conexión saliente.
Un equipo de iOS que depende de equipos Mac
Los Cloud Agents administrados por Cursor se ejecutan en máquinas virtuales Ubuntu. Un equipo que necesite hardware Mac para desarrollar en iOS puede registrar equipos Mac como workers, añadir los permisos necesarios para controlar el equipo y permitir que un agente haga clic, escriba, tome capturas o maneje el navegador en esa máquina.
La ventaja es que el agente remoto utiliza la misma clase de hardware que la compilación. El costo resultará familiar para cualquiera que opere una flota de Mac para compilaciones: las diferencias entre imágenes, los permisos, la disponibilidad, la limpieza y la sustitución siguen siendo responsabilidad del equipo.
Un equipo de plataforma con picos de demanda de agentes
Un equipo de plataforma puede colocar Cloudflare Containers detrás de un Team Pool. La plantilla de referencia inicia un contenedor aislado por cada sesión tomada, usa un Durable Object como propietario de ese contenedor y puede almacenar en caché snapshots del repositorio en R2.
El pool se mantiene disponible aunque no haya workers conectados, por lo que la capacidad puede reducirse a cero. Cuando vuelve el trabajo, el controlador toma la solicitud e inicia un contenedor. La ventaja es pagar capacidad de cómputo según el uso, en lugar de mantener una flota activa de forma permanente.
Una persona con un entorno de desarrollo persistente
My Machines encaja con quien mantiene un proyecto que depende de herramientas o estado local difíciles de recrear. Varios agentes pueden compartir esa máquina: resulta práctico en un equipo personal, pero supone una advertencia para trabajos sensibles.
La ventaja es la rapidez de configuración. El riesgo son los residuos entre ejecuciones, porque Cursor no borra ni reconstruye el equipo entre sesiones. El directorio de trabajo, las credenciales, la limpieza de procesos y el estado de la máquina quedan bajo responsabilidad del propietario.
Configuración funcional en Cloudflare
La opción de Cloudflare resulta útil porque hace visible el nuevo reparto de responsabilidades. Requiere Cursor Enterprise, una clave de cuenta de servicio del equipo con permisos de agente, una cuenta Cloudflare Workers Paid con Containers y R2, Node.js 20 o posterior, y Docker.
Registrar un Team Pool
Instala la CLI de Cursor, comprueba que funciona y conecta un worker local temporal para que el pool aparezca en Cursor.
Bashcurl https://cursor.com/install -fsS | bash agent --version export CURSOR_API_KEY="<team service-account API key>" CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test startDetén ese worker con
Ctrl+Ccuando aparezca el pool y después ejecutaunset CURSOR_API_KEY. Mientras pruebas Cloudflare, mantén detenido el worker local para evitar que tome primero la solicitud.Desplegar la plantilla de referencia de Cursor
Clona la plantilla, instala sus dependencias, inicia sesión en Cloudflare y crea el bucket opcional para snapshots.
Bashgit clone https://github.com/anysphere/cloudflare-workers.git cd cloudflare-workers npm install npx wrangler login npx wrangler r2 bucket create cursor-pool-worker-snapshotsGuardar las credenciales
Guarda la clave de la cuenta de servicio de Cursor en los secretos del Worker. Añade credenciales de Git únicamente si los contenedores necesitan acceder a repositorios privados.
Bashnpx wrangler secret put CURSOR_API_KEY npx wrangler secret put GIT_USERNAME npx wrangler secret put GIT_TOKENUna clave personal de la API de Cursor no funciona con un Team Pool. Es el error de configuración que más fácilmente puede confundirse con un problema de infraestructura, porque el controlador responde con
401.Definir el pool y la capacidad
En
wrangler.jsonc, cambiaCURSOR_POOLporcloudflare-test. Configuracontainers[].max_instancescon el máximo de sesiones simultáneas que el equipo esté dispuesto a ejecutar, no con el número de desarrolladores.El archivo de referencia establece de forma predeterminada
max_instancesen 10 y usa un contenedorstandard-1con 0.5 vCPU, 4 GiB de memoria y 8 GB de disco. Las compilaciones reales pueden requerir una configuración más grande.Desplegar y observar la primera ejecución
Despliega el proyecto y mantén abiertas las vistas del controlador y de los contenedores mientras inicias un Cloud Agent y seleccionas el pool autohospedado.
Bashnpx wrangler deploy npx wrangler tail npx wrangler containers listLa primera ejecución programada del controlador puede tardar hasta cinco minutos en comenzar. Si una sesión tomada no se inicia, las causas habituales son la capacidad de los contenedores, la clonación del repositorio o las credenciales de Git.
El costo cambia de lugar, pero no desaparece
Los Cloud Agents administrados por Cursor incluyen la infraestructura de ejecución. Self-Hosted Machines sigue utilizando el modelo seleccionado con las tarifas de Cursor y añade la factura del worker. Team Pools también exige un contrato Enterprise, cuyo precio es personalizado.
Cloudflare permite ver cómo se comporta ese costo adicional. Su producto Containers forma parte del plan Workers Paid de $5 al mes. Incluye 25 GiB-hora de memoria, 375 minutos de vCPU y 200 GB-hora de disco. Superados esos límites, la memoria cuesta $0.0000025 por GiB-segundo, la CPU activa cuesta $0.000020 por vCPU-segundo y el disco aprovisionado cuesta $0.00000007 por GB-segundo.
Tomemos la configuración standard-1 de la plantilla de referencia y modelemos 100 sesiones que trabajan una hora cada una, utilizan toda la CPU disponible mientras están activas y después atraviesan la ventana de inactividad de cinco minutos de la plantilla. Una vez descontado el uso incluido, el cálculo de los contenedores ronda los $12 al mes:
$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993
Es un ejemplo del costo de infraestructura, no la factura total de Cursor. No incluye el uso de Worker ni de Durable Object, los logs, la salida de datos, R2, el contrato Enterprise, el uso del modelo ni el personal que mantiene la flota. También supone que basta con la configuración más pequeña de la plantilla. Un repositorio con compilaciones intensivas puede exigir un contenedor mayor.
La decisión más costosa no suele ser la tarifa por segundo, sino la política de capacidad activa. El worker genérico de un pool de Cursor establece de forma predeterminada una ventana de reconexión de 3,600 segundos, mientras que la plantilla de Cloudflare la reduce a 300 segundos. Una ventana más larga acelera los prompts posteriores y mantiene la facturación de la memoria y el disco aprovisionados. Una ventana más corta reduce el gasto durante la inactividad, a cambio de más arranques en frío.
La capacidad también queda en manos del cliente. La plantilla admite 10 contenedores simultáneos. La siguiente solicitud espera o no logra iniciarse cuando la capacidad configurada, el límite de la cuenta o el host subyacente no están disponibles. Cursor puede enviar trabajo a un pool, pero no crear una capacidad que el cliente no haya aprovisionado.
El aislamiento sigue la misma regla. La plantilla de Cloudflare asigna un contenedor propio a cada sesión. Una máquina personal puede ejecutar varios agentes en un mismo host. Si la política exige una máquina virtual nueva, un disco borrado, separación entre tenants o un límite limpio para los secretos después de cada ejecución, el equipo debe construir y verificar ese comportamiento.
La aplicación de parches pasa a formar parte del calendario operativo. El equipo se hace cargo de la imagen base, la CLI de Cursor, las herramientas de compilación, los certificados, las dependencias y el despliegue de nuevas versiones. En Cloudflare, desplegar una imagen de contenedor nueva detiene los contenedores activos; por eso, una actualización debe esperar a que terminen las sesiones o aceptar la interrupción.
Qué conviene hacer ahora
Conviene actuar esta semana si un Cloud Agent necesita hardware específico, una imagen personalizada o acceso a herramientas que la red administrada no puede ofrecer. El primer paso debe ser un pool acotado y un repositorio de bajo riesgo. El procesamiento del modelo y los datos que devuelven las herramientas deben permanecer en la revisión de seguridad, porque trasladar la ejecución no los elimina.
Conviene esperar si el único requisito es acceder a código fuente privado o a un servicio interno. Cursor recomienda probar primero entornos administrados, controles de red, Tailscale, AWS PrivateLink o Cloudflare Tunnel antes de asumir la operación de una flota de workers. Con esas opciones, Cursor sigue encargándose del ciclo de vida y el aislamiento del host.
Nada cambia si los Cloud Agents administrados ya cumplen las políticas y reproducen la compilación. El autohospedaje no añade capacidades nuevas al modelo; cambia el lugar de ejecución y quién asume la operación.
La acción concreta para el lunes es elegir un repositorio representativo, documentar qué código, secretos, resultados de herramientas y artefactos pueden cruzar el límite, y ejecutar la misma compilación tanto en un agente administrado como en un pool autohospedado con capacidad estrictamente limitada. Hay que registrar la espera en cola, las horas de contenedor, los cambios aceptados, los problemas de limpieza y el tiempo dedicado a mantener la imagen. La flota solo debe aprobarse si la necesidad de control justifica esa segunda factura.
Recibe en el newsletter el próximo análisis práctico de flujos de trabajo con IA.
3 sept 2026
Prefiera este sitio en Google
Marque omidsaffari.com como fuente preferida y Google lo destacará para usted en Top Stories, AI Overviews y AI Mode.
