Ejecutar agentes de IA en servidores me parece una buena decisión cuando trabajas con varias tareas en paralelo, porque separas sus entornos y sacas esa carga de tu ordenador. MonkeyCode organiza ese trabajo desde un panel central: cada tarea tiene un entorno remoto con recursos, archivos y terminal. Le veo sentido para desarrolladores y equipos que necesitan mantener varios trabajos abiertos sin concentrarlo todo en una máquina.
En mi prueba, la versión alojada construyó una interfaz para visualizar archivos Docker Compose y después la modificó con otra instrucción. También instalé el panel en un VPS propio, aunque esa segunda parte se quedó sin ejecutar tareas: faltaba añadir un host de trabajo. Esa diferencia determina qué necesitas montar y qué vas a pagar.
Qué cambia al ejecutar los agentes fuera de tu ordenador
Uso distintos agentes para programar, entre ellos Claude Code, Codex y OpenCode. Cuando acumulas terminales y tareas, gestionar qué está haciendo cada uno empieza a complicarse. A eso se suma la CPU y la RAM que necesita el trabajo que ejecutan en tu máquina.
MonkeyCode lleva el entorno de ejecución a un servidor remoto. Desde el panel puedes revisar los archivos que ha modificado el agente, abrir una terminal y continuar la tarea. El trabajo queda asociado a ese entorno, con sus propios recursos.
La ventaja que me interesa es la separación entre tareas. Si estás tocando proyectos distintos, puedes mantener sus archivos y procesos en entornos diferentes. En un equipo, ese planteamiento también ayuda a centralizar la configuración sin obligar a todos a trabajar dentro del mismo espacio.
Esto aborda una cuestión distinta de repartir responsabilidades entre agentes. En MiniMax Code y el salto de usar un agente a montar un equipo explico la separación entre quien implementa y quien verifica. Aquí el criterio es dónde corre cada trabajo y qué recursos utiliza.
Qué funcionó en mi prueba con MonkeyCode
Le pedí un frontal sencillo al que pudiera pegar un Docker Compose para ver sus servicios de forma estructurada. Quería evitar tener que recorrer el archivo entero para localizar bases de datos, variables y otros componentes.
El agente generó la aplicación y abrió una vista previa alojada en un dominio de MonkeyCode. Pegué un Compose del propio proyecto y la interfaz mostró sus servicios, entre ellos una base de datos, Redis y ClickHouse, junto con las variables de entorno. Para el alcance que había pedido, cumplió bastante bien.
Después le pedí que añadiese advertencias útiles para el desarrollador. El agente modificó la aplicación y aparecieron los avisos. Podéis ver el resultado de la prueba, que dejé publicado.
Hay una distinción que mantendría al usar esa aplicación: que el agente genere una advertencia demuestra que ha implementado la función. La gravedad que asigna a cada aviso necesita revisión. En la prueba aparecían advertencias que calificaba como críticas, y yo mismo señalé que habría que comprobar ese criterio.
También tuve acceso a los archivos y a la terminal del entorno. Esa parte me parece más útil que quedarse únicamente con la vista previa: puedes inspeccionar el trabajo y seguir iterando sobre él.
Lo que ejecuté fue una tarea con una iteración posterior. La cuenta gratuita que usé admitía una sola tarea concurrente, así que el comportamiento con varios entornos trabajando a la vez quedó fuera de mi prueba.
Qué límites importan más que la cuota de tokens
En el vídeo publicado el 4 de septiembre de 2026, el panel mostraba estos planes. Son las condiciones que enseñé entonces:
| Plan | Precio mostrado | Tareas concurrentes | Recursos del entorno | Cuota diaria |
|---|---|---|---|---|
| Gratuito | Gratis | 1 | 1 core y 4 GB de RAM | 10 millones de tokens |
| Pro | 15 dólares | 3 | 2 cores y 8 GB de RAM | 100 millones de tokens |
| Ultra | 60 dólares | — | — | 300 millones de tokens |
Para este uso, miraría primero las tareas concurrentes. Puedes tener una cuota de tokens enorme y seguir limitado a un único trabajo abierto. Si buscas ejecutar varios agentes a la vez, esa restricción pesa más que el número grande del plan.
El consumo tampoco equivale únicamente a lo que escribes en el chat. Una tarea inicial en la que había puesto «hola» llevaba unos 74.000 tokens consumidos. Mi impresión fue que el arranque y las instrucciones internas explicaban buena parte de ese gasto, aunque no comprobé el desglose.
Tras crear la aplicación e iterarla había gastado algo más de un millón de tokens. El panel distinguía también los créditos destinados a funciones como búsquedas, reconocimiento de imágenes, procesamiento de documentos y llamadas a herramientas. Antes de elegir un plan, comprueba qué bolsa consume el tipo de trabajo que vas a pedir.
El self-hosting necesita panel, modelos y hosts de trabajo
MonkeyCode es de código abierto y tiene un repositorio público en GitHub. Para probar su instalación elegí un VPS de Hetzner, me conecté por SSH y ejecuté el instalador indicado en el proyecto. El proceso instaló Docker y me pidió los datos del administrador.
Después utilicé OpenCode para configurar Traefik y exponer el panel con un subdominio. Asigné la IP del servidor en Cloudflare y pude entrar en la interfaz de MonkeyCode desde el navegador.
Pero tener el panel instalado era solo una parte del montaje. Al lanzar una tarea, MonkeyCode me indicó que no había hosts añadidos. El servidor que acababa de preparar alojaba la gestión central; aún tenía que registrar los servidores donde se ejecutaría el trabajo.
Decidí parar ahí porque no quería contratar otro VPS para esa prueba. La instalación del panel y el acceso por dominio funcionaron, pero no llegué a ejecutar una tarea en mi despliegue propio.
La arquitectura separa varias piezas: el panel centraliza la configuración, el proveedor de IA aporta los modelos y los hosts ejecutan las tareas. En los ajustes también aparecen repositorios, imágenes de entorno, skills y MCPs. Si necesitas entender qué aporta esa última conexión, tienes la explicación en qué son los servidores MCP.
La objeción: estás cambiando carga local por infraestructura
La objeción más razonable es que sacar los agentes del PC añade servidores y configuración. Mi intento de self-hosting lo deja bastante claro: pude entrar al panel, configurar un proveedor de modelos y aun así me faltaba la máquina que iba a ejecutar la tarea.
Por eso, para mí, la versión alojada es el punto de entrada sensato si quieres comprobar el flujo antes de administrar infraestructura. El self-hosting encaja mejor cuando buscas gestionar esa instalación y estás dispuesto a mantener sus piezas.
También necesitas resolver la inferencia. La instalación propia no incluía la cuota de modelos del servicio alojado, así que configuré un proveedor externo. En la prueba utilicé el servicio experimental de inferencia de Hetzner y encontré respuestas útiles, aunque a veces iba lento.
Ojo: durante mis pruebas no encontré un límite de uso, pero eso no demuestra que el servicio sea ilimitado. Para elegirlo como proveedor habitual, comprueba sus condiciones y si su velocidad te sirve para las tareas que quieres ejecutar.
Cuándo seguiría trabajando en local
Mantendría el trabajo en mi ordenador si ejecuto una sola tarea, la máquina responde bien y gestionar sus procesos no me molesta. En esa situación, montar un panel y añadir hosts introduce trabajo operativo sin resolver una necesidad concreta.
Me plantearía moverlo a servidores cuando necesito varios trabajos independientes, mi equipo se queda corto o quiero compartir una configuración central con otros desarrolladores. El criterio es el atasco que eliminas: recursos locales, entornos mezclados o gestión del equipo.
Para comprobarlo, entra en MonkeyCode y lleva una tarea pequeña de un proyecto que conozcas. Revisa los archivos, abre su terminal y pide una modificación; después decide si necesitas más concurrencia o si tu entorno local ya cubre ese trabajo.
¿Qué te ha parecido?
Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .