Executar agentes de IA em servidores me parece uma boa decisão quando você trabalha com várias tarefas em paralelo, porque separa os ambientes e tira essa carga do seu computador. O MonkeyCode organiza esse trabalho em um painel central: cada tarefa tem um ambiente remoto com recursos, arquivos e terminal. Vejo sentido nisso para desenvolvedores e equipes que precisam manter vários trabalhos em andamento sem concentrar tudo em uma máquina.
No meu teste, a versão hospedada criou uma interface para visualizar arquivos Docker Compose e depois a modificou com outra instrução. Também instalei o painel em um VPS próprio, mas essa segunda parte ficou sem executar tarefas: faltava adicionar um host de trabalho. Essa diferença determina o que você precisa configurar e quanto vai pagar.
O que muda ao executar os agentes fora do seu computador
Uso diferentes agentes para programar, entre eles Claude Code, Codex e OpenCode. Quando você acumula terminais e tarefas, gerenciar o que cada um está fazendo começa a ficar complicado. A isso se somam a CPU e a RAM necessárias para o trabalho que eles executam na sua máquina.
O MonkeyCode leva o ambiente de execução para um servidor remoto. Pelo painel, você pode revisar os arquivos que o agente modificou, abrir um terminal e continuar a tarefa. O trabalho fica associado àquele ambiente, com seus próprios recursos.
A vantagem que me interessa é a separação entre tarefas. Se você está mexendo em projetos diferentes, pode manter seus arquivos e processos em ambientes separados. Em uma equipe, essa abordagem também ajuda a centralizar a configuração sem obrigar todo mundo a trabalhar no mesmo espaço.
Isso trata de uma questão diferente de distribuir responsabilidades entre agentes. Em MiniMax Code e o salto de usar um agente para montar uma equipe, explico a separação entre quem implementa e quem verifica. Aqui, o critério é onde cada trabalho roda e quais recursos utiliza.
O que funcionou no meu teste com MonkeyCode
Pedi um front-end simples em que eu pudesse colar um Docker Compose para ver seus serviços de forma estruturada. Queria evitar ter que percorrer o arquivo inteiro para localizar bancos de dados, variáveis e outros componentes.
O agente gerou a aplicação e abriu uma prévia hospedada em um domínio do MonkeyCode. Colei um Compose do próprio projeto e a interface mostrou seus serviços, entre eles um banco de dados, Redis e ClickHouse, junto com as variáveis de ambiente. Para o escopo que eu tinha pedido, atendeu muito bem.
Depois, pedi que adicionasse alertas úteis para o desenvolvedor. O agente modificou a aplicação e os avisos apareceram. Você pode ver o resultado do teste, que deixei publicado.
Há uma distinção que eu manteria ao usar essa aplicação: o fato de o agente gerar um alerta demonstra que ele implementou a função. A gravidade que ele atribui a cada aviso precisa de revisão. No teste, apareciam alertas que ele classificava como críticos, e eu mesmo destaquei que seria necessário verificar esse critério.
Também tive acesso aos arquivos e ao terminal do ambiente. Essa parte me parece mais útil do que ficar só com a prévia: você pode inspecionar o trabalho e continuar fazendo ajustes.
O que executei foi uma tarefa com uma iteração posterior. A conta gratuita que usei permitia apenas uma tarefa simultânea, então o comportamento com vários ambientes trabalhando ao mesmo tempo ficou fora do meu teste.
Quais limites importam mais do que a cota de tokens
No vídeo publicado em 4 de setembro de 2026, o painel mostrava estes planos. São as condições que mostrei na época:
| Plano | Preço exibido | Tarefas simultâneas | Recursos do ambiente | Cota diária |
|---|---|---|---|---|
| Gratuito | Grátis | 1 | 1 núcleo e 4 GB de RAM | 10 milhões de tokens |
| Pro | 15 dólares | 3 | 2 núcleos e 8 GB de RAM | 100 milhões de tokens |
| Ultra | 60 dólares | — | — | 300 milhões de tokens |
Para esse uso, eu olharia primeiro para as tarefas simultâneas. Você pode ter uma cota enorme de tokens e continuar limitado a um único trabalho em andamento. Se quer executar vários agentes ao mesmo tempo, essa restrição pesa mais do que o número grande do plano.
O consumo também não se resume ao que você escreve no chat. Uma tarefa inicial em que eu tinha escrito «olá» já havia consumido cerca de 74.000 tokens. Minha impressão foi que a inicialização e as instruções internas explicavam boa parte desse gasto, embora eu não tenha conferido o detalhamento.
Depois de criar a aplicação e fazer uma nova iteração, eu tinha gastado pouco mais de um milhão de tokens. O painel também diferenciava os créditos destinados a funções como buscas, reconhecimento de imagens, processamento de documentos e chamadas de ferramentas. Antes de escolher um plano, confira qual saldo é consumido pelo tipo de trabalho que você vai pedir.
O self-hosting precisa de painel, modelos e hosts de trabalho
O MonkeyCode é de código aberto e tem um repositório público no GitHub. Para testar a instalação, escolhi um VPS da Hetzner, me conectei por SSH e executei o instalador indicado no projeto. O processo instalou o Docker e pediu os dados do administrador.
Depois, usei o OpenCode para configurar o Traefik e expor o painel com um subdomínio. Configurei o IP do servidor no Cloudflare e consegui acessar a interface do MonkeyCode pelo navegador.
Mas ter o painel instalado era só uma parte da configuração. Ao iniciar uma tarefa, o MonkeyCode informou que não havia hosts adicionados. O servidor que eu acabara de preparar hospedava o gerenciamento central; ainda precisava cadastrar os servidores onde o trabalho seria executado.
Decidi parar por aí porque não queria contratar outro VPS para esse teste. A instalação do painel e o acesso pelo domínio funcionaram, mas não cheguei a executar uma tarefa na minha instalação própria.
A arquitetura separa várias peças: o painel centraliza a configuração, o provedor de IA fornece os modelos e os hosts executam as tarefas. Nas configurações também aparecem repositórios, imagens de ambiente, skills e MCPs. Se você precisa entender o que essa última conexão oferece, encontra a explicação em o que são os servidores MCP.
A objeção: você está trocando carga local por infraestrutura
A objeção mais razoável é que tirar os agentes do PC acrescenta servidores e configuração. Minha tentativa de self-hosting deixa isso bem claro: consegui acessar o painel, configurar um provedor de modelos e, mesmo assim, ainda faltava a máquina que executaria a tarefa.
Por isso, para mim, a versão hospedada é o ponto de entrada mais sensato se você quer testar o fluxo antes de administrar infraestrutura. O self-hosting faz mais sentido quando você quer gerenciar essa instalação e está disposto a manter suas peças.
Você também precisa resolver a inferência. A instalação própria não incluía a cota de modelos do serviço hospedado, então configurei um provedor externo. No teste, usei o serviço experimental de inferência da Hetzner e recebi respostas úteis, embora às vezes fosse lento.
Atenção: durante meus testes, não encontrei um limite de uso, mas isso não demonstra que o serviço seja ilimitado. Para escolhê-lo como provedor habitual, confira as condições e se a velocidade atende às tarefas que você quer executar.
Quando eu continuaria trabalhando localmente
Manteria o trabalho no meu computador se executasse uma única tarefa, a máquina respondesse bem e gerenciar seus processos não me incomodasse. Nessa situação, instalar um painel e adicionar hosts cria trabalho operacional sem resolver uma necessidade concreta.
Eu consideraria mover o trabalho para servidores quando precisasse de vários trabalhos independentes, meu computador não desse conta ou quisesse compartilhar uma configuração central com outros desenvolvedores. O critério é o gargalo que você elimina: recursos locais, ambientes misturados ou gerenciamento da equipe.
Para conferir, acesse o MonkeyCode e leve uma tarefa pequena de um projeto que você conheça. Revise os arquivos, abra o terminal e peça uma modificação; depois, decida se precisa de mais tarefas simultâneas ou se seu ambiente local já dá conta desse trabalho.
O que você achou?
Deixe sua opinião, pergunta ou sugestão. Os comentários são sincronizados com GitHub Discussions .