OpenHuman agent harness: 500 agentes em $10/mês? O que o código revela
Toda semana aparece um repositório novo no GitHub prometendo rodar centenas de agentes de IA numa VPS de cinco ou dez dólares. Essa semana foi a vez do openhuman agent harness, escrito em Rust pela tinyhumansai, com a promessa estampada na descrição do repo: “Run more than 500 agents on a $10 VPS”. Antes de repetir esse número como se fosse fato estabelecido, fui ler o README inteiro e separar o que é economia real de recursos do que é só contagem de processos parados esperando alguma coisa acontecer. O projeto é interessante, mas o README é generoso com adjetivo e econômico com metodologia.
O que o README promete e o que ele deliberadamente não define
A claim central do openhuman, segundo o próprio README, é que “a maioria dos harnesses de agente roda um processo pesado por agente e reenvia um prompt grande a cada chamada. O OpenHuman faz o mesmo trabalho com muito menos.” É uma frase de posicionamento, não uma especificação técnica. Ela não diz o que conta como “um agente rodando”: é um agente em loop ativo de raciocínio, consumindo tokens de um LLM a cada segundo? É um agente em modo de espera, escutando um evento via MCP (Model Context Protocol, que está entre os tópicos do repo) e só “acordando” quando algo chega?
Essa distinção não é picuinha semântica. É a diferença entre ter 500 unidades de trabalho real acontecendo ao mesmo tempo e ter 500 structs em memória esperando um gatilho. O README linka páginas de documentação com “benchmark results”, “fleet measurements” e “methodology”, mas no texto principal, que é o que a maioria das pessoas vai ler antes de decidir se testa o projeto, a definição operacional de “agente rodando” simplesmente não aparece. É um padrão recorrente em todo README que quer ser citado rápido: números grandes na primeira dobra, metodologia enterrada em outro link que poucos vão clicar.
Specs reais de um VPS de $10: quanto dá pra dividir entre 500 processos
Vamos à aritmética que o README não faz por você. Um VPS de $10/mês em provedores como Hetzner ou DigitalOcean entrega, tipicamente, algo entre 1 e 2 vCPU e 2 a 4GB de RAM (faixas de entrada publicadas nas tabelas de preço desses provedores, não um benchmark específico do openhuman). Divida 2GB de RAM por 500 “agentes” e você tem cerca de 4MB por agente. Isso é plausível para uma struct leve em Rust com estado mínimo (um ponteiro de contexto, uma fila de eventos, talvez um buffer pequeno). É completamente implausível se cada um desses 500 “agentes” estiver com uma janela de contexto de LLM carregada na memória local, ou se cada um mantiver uma conexão de rede persistente aberta esperando resposta de um provedor de modelo.
Em CPU a conta é ainda mais apertada: 1 a 2 vCPU divididos por 500 processos dá, no limite teórico, uma fatia de tempo de CPU ridiculamente pequena por unidade. Isso só fecha se a esmagadora maioria desses 500 estiver em estado de espera, sem consumir ciclo de CPU algum, e apenas um punhado estiver de fato processando algo no momento da medição. O que não é mentira, mas também não é “500 agentes trabalhando”. É 500 agentes existindo, dos quais talvez 5 ou 10 estejam trabalhando a qualquer instante.
Onde mora o truque comum desse tipo de claim: idle vs ativo
Esse é o ponto mais importante do artigo inteiro, então vale separar dois conceitos que o mercado de agent orchestration adora borrar. O agente idle (ocioso) é uma estrutura de dados alocada, talvez com um listener de evento ou um polling de baixa frequência, sem consumir CPU relevante nem fazer chamada a LLM. Custa quase nada. Já o agente ativo está, naquele milissegundo, processando um prompt, chamando um modelo, esperando resposta de API e consumindo tokens, e portanto dinheiro e CPU de verdade.
Não tenho uma fonte documentada apontando o dedo pra um caso específico, mas é um padrão que eu já vi se repetir em outras ferramentas de orquestração multiagente: contar “agentes simultâneos” sem deixar claro quantos estavam de fato em execução ativa versus quantos estavam só em espera num loop ocioso. O número de agentes “instanciados” sempre foi mais fácil de inflar do que o número de agentes “trabalhando”, porque instanciar uma struct é barato e trabalhar com um LLM é caro: em tokens, em latência, em CPU para serializar e desserializar contexto.
O openhuman não inventou esse truque, mas também não se livra dele só porque é escrito em Rust e usa um runtime assíncrono eficiente. Rust ajuda muito na parte de overhead de processo (não é a mesma coisa que rodar 500 processos Python com interpretador próprio cada um, isso é real e mensurável). Mas ajuda zero na parte em que o agente de fato precisa de um LLM respondendo. Essa parte é limitada pela rede, pela API do provedor de modelo e pelo custo por token, não pela eficiência do harness.
O que o projeto documenta sobre como ele economiza recursos (ou não)
Pelo README, o openhuman se define como “a desktop app for people, a Rust library for developers”, ou seja, ao mesmo tempo um app desktop pronto pra usuário final e uma biblioteca Rust embarcável, pensada para “chamar um agente como qualquer outra função”. Não encontrei confirmação de qual framework específico roda por trás da interface desktop (então não vou chutar um nome aqui), mas a arquitetura de biblioteca embutida é o ponto mais promissor tecnicamente: em vez de cada agente ser um processo do sistema operacional com espaço de memória isolado, o padrão sugerido é de tasks leves dentro de um único processo Rust, compartilhando runtime assíncrono (o ecossistema Rust tradicionalmente usa Tokio para isso, embora o README não cite explicitamente qual runtime usa).
Esse padrão, várias tasks cooperativas num processo só em vez de um processo por agente, é genuinamente mais barato em memória e em troca de contexto do sistema operacional. É o mesmo motivo pelo qual um servidor web assíncrono em Rust ou Go aguenta dezenas de milhares de conexões simultâneas onde um modelo de thread por conexão travaria. Isso não é hype, é arquitetura de sistemas estabelecida há décadas.
O README também menciona “compressão de tokens” como uma das peças que reduz custo, com link para uma página de documentação específica sobre o assunto. Isso ataca um gargalo diferente e real: o tamanho do prompt reenviado a cada chamada. Harnesses mais simples mandam o histórico inteiro da conversa a cada turno; se o openhuman de fato comprime ou poda esse contexto antes de enviar, isso reduz custo de token e de CPU de serialização. Mas, de novo, o quanto isso se traduz em “agentes simultâneos” depende de quantos desses agentes estão, no momento da medição, de fato chamando um modelo.
As perguntas que faltam responder antes de acreditar no número
Antes de reproduzir a claim “500 agentes num VPS de $10” num post, numa thread ou numa reunião de arquitetura, as perguntas que eu faria, e que o texto do README por si só não responde, são estas:
- Dos 500 agentes do teste, quantos estavam em chamada ativa de LLM no mesmo segundo, em vez de em espera?
- A medição de memória e CPU inclui o processo do modelo de linguagem (se local) ou só o overhead do harness, assumindo chamadas a uma API externa?
- Qual é a taxa de requisição por agente durante o teste? Um agente por minuto é uma carga completamente diferente de um agente por segundo.
- O benchmark citado roda num cenário de workload real (tarefas variadas, latência de rede real) ou num ambiente sintético controlado?
- O runtime assíncrono usado reaproveita conexões de rede entre agentes, ou cada um abre uma conexão própria para a API do modelo?
Nenhuma dessas respostas está no corpo do README principal. Podem estar na página de métricas linkada na documentação, mas até isso ser lido e entendido por quem pretende citar o número, a honestidade técnica manda tratar “500 agentes” como claim de marketing, não como fato medido de forma transparente no texto que todo mundo lê primeiro.
Quando essa arquitetura faz sentido de verdade (e quando é só número bonito pra README)
Faz sentido real para cenários onde a maioria dos agentes passa a maior parte do tempo esperando evento: automações pessoais, assistentes de memória persistente, monitoramento disparado por webhook, triagem de mensagens que chegam esporadicamente. A própria tinyhumans descreve o OpenHuman como “a local-first brain with persistent memory”, o que casa com esse tipo de uso. Nesses casos, ter centenas de agentes “existindo” e baratos em repouso é genuinamente útil.
Não faz sentido, e aí o número vira só ornamento de README, se a sua carga de trabalho é 500 agentes processando tarefas pesadas de SWE ou análise em paralelo o tempo todo. Nesse cenário o gargalo sempre vai ser a API do modelo e seu orçamento de tokens, não a eficiência do harness em Rust. Nenhum harness, por mais otimizado que seja, resolve o fato de que GPU e inferência de LLM custam dinheiro proporcional ao uso real, não ao número de agentes alocados em memória.
Para quem está decidindo infraestrutura, ferramentas de observabilidade de processo (htop, ou coisas mais finas como cargo-flamegraph para profiling em Rust) continuam sendo o jeito mais honesto de verificar uma claim dessas na prática, rodando sua própria carga de trabalho antes de redimensionar o VPS para baixo.
Fontes consultadas
- Repositório oficial: github.com/tinyhumansai/openhuman
- README do projeto (seções “Why OpenHuman?” e “Major innovations”), consultado na branch principal
- Site do projeto: tinyhumans.ai/openhuman
- Tabelas de preço de entrada de VPS de provedores como Hetzner e DigitalOcean, para estimativa de specs típicas de uma instância de $10/mês
Minha posição
Eu não acho que o openhuman esteja mentindo. Acho que ele está fazendo o que praticamente todo projeto trending de agent orchestration faz: colocando o número mais impressionante na primeira linha e deixando a definição chata (o que exatamente conta como “agente rodando”) para quem tiver paciência de ir atrás. A arquitetura de biblioteca Rust embarcada com tasks leves é uma escolha de engenharia que eu respeito e que tem fundamento real para reduzir overhead comparado a um processo por agente. Mas “500 agentes num VPS de $10” sem definir idle versus ativo é frase de outdoor, não spec. Se você trabalha com infraestrutura, a regra não muda: leia o código antes do README, e quando não conseguir ler o código, pelo menos exija que o benchmark linkado defina os termos que o texto principal evitou definir.