Un agente alojado se ejecuta en la nube de un proveedor. Le das una copia de tus repositorios y un conjunto de credenciales, y trabaja a partir de ahí. Un agente local-first se ejecuta en tu propia máquina, donde ya residen el runtime, la suscripción, los archivos y las claves, y de donde solo sale la conversación.
Ambos diseños son válidos. Sitúan tu código, tu identidad y tu factura en lugares distintos, y las diferencias cobran mayor importancia en cuanto empiezas a compartir el agente con otras personas.
Los aciertos del modelo alojado y sus costes
Los ejemplos concretos en 2026 son Claude Code on the web y OpenAI’s Codex cloud tasks. Ambos ejecutan el agente en el sandbox del proveedor sobre un clon de tu repositorio y se autentican en git con tokens emitidos para el proveedor mediante la integración OAuth de GitHub, de modo que el agente nunca tiene acceso a tus credenciales locales, claves SSH o variables de entorno. Se trata de una propiedad de seguridad real: el portátil comprometido de un desarrollador no puede filtrarse al entorno del agente, y una tarea mal acotada no puede tocar archivos fuera del sandbox.
Un agente alojado está siempre activo. No hay ningún portátil que mantener despierto ni nada que instalar. Para flotas desatendidas que funcionan las 24 horas, esto resulta decisivo.
Sus costes son estructurales y no remediables.
- Una segunda copia de todo. El proveedor almacena tus repositorios y, a menudo, tu entorno para que el agente pueda trabajar. Esa copia tiene sus propios controles de acceso, retención y superficie de exposición ante brechas de seguridad.
- Un segundo conjunto de credenciales. Los tokens para GitHub, cuentas en la nube y API internas se emiten para el proveedor. Rotarlos implica rotarlos también allí.
- Una segunda factura. Pagas por el runtime alojado además de, o en lugar de, la suscripción que ya tienes.
- La elección del modelo en manos de terceros. El proveedor decide qué modelos están disponibles y cuándo cambian.
Los aciertos del modelo local-first y sus costes
Un agente local-first utiliza lo que ya tienes en tu máquina: la suscripción a Claude Code o Codex que pagas, los repositorios que ya has descargado, las claves que ya están en tu llavero. No se copia nada en ningún sitio. Cuando compartes el agente, la otra persona puede hacer consultas; tu máquina sigue haciendo el trabajo.
El coste es la disponibilidad. Si la máquina duerme, el agente duerme.
Las soluciones son prácticas más que arquitectónicas: registra el daemon como servicio para que arranque al iniciar sesión y se reinicie tras un fallo, mantén la máquina despierta durante el horario laboral y pon las solicitudes en cola en un inbox para que no se pierda nada mientras esté desconectada. Las solicitudes se ejecutan en orden cuando vuelve a estar disponible.
Dos lugares donde situar el límite de confianza: alrededor del sandbox del proveedor, o alrededor de tu propia máquina con una sala fuera de ella.
Hasta qué punto puede ser ligera la capa en la nube
muti es local-first, y la cuestión de diseño interesante era qué se le permite albergar a la nube. La respuesta es: la sala, y nada que permita a la sala suplantar a la máquina.
Tres mecanismos hacen que esto se sostenga.
Solo conexiones salientes. El daemon de tu máquina busca trabajo mediante una conexión saliente. No hay ningún puerto abierto, ningún túnel ni ninguna ruta de entrada. Si la nube de muti se viera comprometida, el atacante podría poner en cola solicitudes que tus reglas de permisos y aprobaciones seguirían controlando; no podría acceder a tus archivos.
Eventos, no archivos. El daemon emite eventos de timeline describiendo lo que ha ocurrido. No sube el árbol de trabajo y nunca lee variables de entorno ni archivos de claves para enviarlos a ninguna parte.
Aprobaciones de por medio. Al ser la máquina tuya, los cuatro tipos de acciones peligrosas se detienen para pedirte confirmación en cada solicitud que haga otra persona. Un agente alojado con tus credenciales no tiene a quién preguntar.
Tabla de decisión
Por qué muti no aloja runtimes
Sería fácil añadir un botón de «ejecutar esto en nuestra nube». No lo hemos hecho, y es un no-objetivo deliberado. En el momento en que el runtime se traslada, las credenciales y los repositorios van detrás, y el propietario deja de ser quien aprueba. Cada una de las garantías de las cuatro acciones que siempre piden confirmación depende de que la máquina pertenezca al propietario.
muti aloja salas. Tu agente se queda donde está.
Preguntas frecuentes
¿Es «local-first» lo mismo que «offline»? No. El agente necesita conexión a la red para comunicarse con el proveedor del modelo, y muti la necesita para entregar mensajes. Local-first describe dónde residen el trabajo y los secretos, no si la máquina está conectada.
¿Puedo autoalojar la nube de muti? El autoalojamiento de la capa de salas está en la hoja de ruta como un modo individual y con soporte offline. El daemon y la nube ya se comunican mediante una API estándar.
¿Y si tengo varias máquinas? Conecta cada una de ellas. Los agentes están vinculados a una máquina y a un directorio de trabajo, y puedes distinguir tus máquinas por las direcciones que comunica el daemon.
Si ya pagas por un buen agente y quieres mantenerlo donde está, dale una sala.
Publicado el · Actualizado el