250 subagentes contra 4 threads: por que a arquitetura de orquestração importa mais do que o nome chamativo do modelo

• Diferença no OSWorld 2.0: 70,2% de checkpoints concluídos contra 34,7% de tarefas totalmente resolvidas
• Paralelismo de orquestração: 250 subagentes simultâneos e 5 níveis de aninhamento no Claude Code contra 4 threads no Codex
• Gasto por tarefa de migração no Codex: 4,7 bilhões de tokens em uma semana (de um total de 12,7 bilhões em um ano e meio)
• Duração do teste de produção: mais de 12 dias de execução contínua contra 1 dia útil com um enxame de agentes

Cada onda de lançamentos dos grandes laboratórios vem acompanhada do mesmo hipnotismo visual. Com a chegada do GPT-6 Astra, os feeds das redes sociais se encheram de vídeos bonitos: o modelo gira cenas 3D no Blender, faz o desdobramento de texturas, monta uma peça de engenharia com exportação para STEP e passa pelo nível 44 de um captcha de brincadeira, batendo um motor de xadrez. Os profissionais de marketing acertaram em cheio — as pessoas pensam com os olhos, e uma imagem impactante dá origem instantaneamente à lenda de que a superinteligência chegou.

Mas, ao abrir o código-fonte da demonstração de engenharia mais comentada, com os desenhos técnicos, aparece um detalhe que os autores dos repostes esquecem de mencionar: trata-se de um conjunto de habilidades open source de terceiros, o `text-to-cad`, escrito por um desenvolvedor independente. Da mesma forma, meu Claude Code, com uma habilidade especializada, controla o AutoCAD e o Blender sem nenhuma mágica interna nos pesos do modelo.

Por que 72,6% na tabela promocional do OSWorld 2.0 não significam 72%

do trabalho feito?

O segundo truque está na forma como os fornecedores apresentam os números dos benchmarks de uso de computador. Sem dúvida, o reconhecimento visual de interfaces avançou — no ScreenSpot-Pro, o índice chegou a 92,7%. No entanto, o número de 72,6% no OSWorld 2.0, repetido por todos os blogs de tecnologia, aparece marcado em letras miúdas na própria tabela como `partial score`.

Ao abrir o leaderboard independente oficial do OSWorld 2.0, sempre há duas colunas: a proporção de checkpoints intermediários concluídos dentro do cenário e a proporção de tarefas levadas até o resultado final. No exemplo das execuções verificadas do Claude Opus 5, dá para ver como essa proporção funciona: o modelo passa por 70,2% dos checkpoints, mas fecha completamente apenas 34,7% das tarefas. A diferença é exatamente o dobro. Entre "apertei dois botões certos em três" e "entreguei o projeto pronto para o cliente" existe um abismo que nenhum preview bonito consegue atravessar.

O que mostrou o teste de estresse de 12 dias para migrar 369

habilidades e 40 agentes?

Para testar os modelos além de exemplos de brinquedo, eu dou a eles trabalho de infraestrutura real. A tarefa foi definida de forma bem concreta: realizar a migração completa e sem costuras do meu ambiente de trabalho (369 habilidades, 40 agentes, roteamento, scripts e memória em várias camadas) do formato Claude Code para um ambiente isolado no Codex.

Comecei esse experimento ainda no GPT-5.6 Sol e, depois do lançamento, troquei para o GPT-6 Astra em produção. Depois de doze dias seguidos de execução contínua e 4,7 bilhões de tokens consumidos em uma única semana, a tarefa ainda não tinha sido concluída. Para efeito de comparação: um volume equivalente de refatoração no meu ambiente padrão leva um dia útil.

Quando investiguei a documentação e as limitações internas das duas ferramentas, a causa veio à tona:

• No Claude Code, a variável `CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS` aceita qualquer número inteiro — na minha configuração de produção, está definida com 250 subagentes paralelos e até 5 níveis de hierarquia.
• No Codex, o parâmetro `max_threads` fica travado em 4 threads abertas, e um worker já finalizado continua ocupando o slot até que o orquestrador chame explicitamente `close_agent`.
• Em vez de pipelines declarativos com múltiplas ondas, é preciso acionar manualmente, um por um, os primitivos `spawn_agent` e `wait_agent`.

Por que uma semana de trabalho autônomo de um agente é sintoma de

gargalo, e não motivo de orgulho?

Hoje está na moda se encantar com o fato de um agente conseguir trabalhar sozinho, sem parar, durante uma semana inteira numa tarefa. Na prática, isso significa uma coisa só: o sistema não tem um barramento de orquestração decente para dividir a tarefa entre cinquenta mãos independentes e reunir o resultado em duas horas, com verificação de cada pedaço. Até o modelo mais rápido, preso numa fila de quatro threads, perde para um enxame bem projetado.

Análises detalhadas de arquitetura de sistemas multiagente e testes honestos de modelos, sem a casca do marketing, eu publico no canal [@jemal_hamidun](https://t.me/jemal_hamidun). Um orquestrador completo, sem limites artificiais de threads, estamos desenvolvendo no produto [Nomad AI](https://nomadnet.ai). Para aprender na prática a construir ondas de subagentes, há a [Hamidun Academy](https://academy.hamidun.com), com teste gratuito de 72 horas, e para pegar configurações prontas de enxames e mais de 370 habilidades, o [Vibe Club](https://hamidun.com/club).