💸 De $15,00 para $1,80 na mesma feature: a matemática da orquestração de agentes que o orçamento da sua empresa vai adorar · Craverath

Orquestrar agentes é uma das formas mais eficazes de reduzir o custo de tokens no desenvolvimento com IA, desde que cada modelo receba uma função e um objetivo de acordo com sua capacidade e inteligência. Aqui você vai ver por que a orquestração sozinha não economiza nada, como desenhar a arquitetura em que um modelo forte planeja e revisa enquanto agentes baratos executam, uma skill pronta para aplicar esse padrão no seu agente e a conta fechada com preços reais, que fica entre 3x e 8x de economia.

A orquestração por si só não economiza

A própria Anthropic, ao descrever seu sistema de pesquisa multi-agente, mediu que sistemas multi-agente consomem cerca de 15x mais tokens que uma interação de chat simples, e que o uso de tokens sozinho explica 80% da variação de performance. Ou seja: agentes entregam mais porque gastam mais. Quem monta uma orquestração esperando economia automática descobre a fatura no fim do mês.

A economia vem de uma decisão de arquitetura anterior à ferramenta: definir qual é a função de cada modelo no fluxo e qual objetivo ele precisa cumprir. Decidir e validar são tarefas caras por natureza e merecem o modelo de ponta. Executar um plano pronto é tarefa mecânica e cabe em um modelo barato. Sem essa separação, a orquestração só multiplica chamadas de modelo caro.

Inteligência tem preço por token

Os provedores vendem modelos em camadas de capacidade, e a diferença de preço entre o topo e a base chega a mais de 30x. Preços de referência em agosto de 2026, por milhão de tokens, conforme as páginas oficiais de preço da Anthropic, da OpenAI e da DeepSeek:

Modelo	Papel típico	Input $/1M	Output $/1M
Claude Opus 5	planejador / revisor	$5,00	$25,00
GPT-5.5	planejador / revisor	$5,00	$30,00
Claude Sonnet 5	agente intermediário	$3,00	$15,00
Claude Haiku 4.5	agente econômico	$1,00	$5,00
DeepSeek V4-Flash	agente econômico	$0,14	$0,28

Um modelo caro não é caro por igual em todas as tarefas. Planejar uma refatoração pede o modelo de ponta. Renomear variáveis em quarenta arquivos seguindo um plano pronto não pede. Pagar preço de Opus por trabalho de Haiku é o desperdício que a orquestração elimina.

Desenho arquitetural

A arquitetura tem três papéis. O planejador (modelo forte) explora o problema, decide a estratégia e decompõe o trabalho em subtarefas autocontidas, classificadas por complexidade. Os agentes de execução (modelos baratos) resolvem cada subtarefa em contexto isolado. O revisor (o mesmo modelo forte) valida os resultados contra o plano antes da entrega.

                    ┌─────────────────────────┐
                    │        Planejador       │
                    │  modelo caro · decompõe │
                    └────────────┬────────────┘
          ┌──────────────────────┴──────────────────────┐
          ▼                      ▼                      ▼
 ┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
 │     Agente A     │   │     Agente B     │   │     Agente C     │
 │ barato · boiler. │   │ barato · testes  │   │  médio · lógica  │
 └────────┬─────────┘   └────────┬─────────┘   └────────┬─────────┘
          └──────────────────────┬──────────────────────┘
                                 ▼
                    ┌─────────────────────────┐
                    │         Revisor         │
                    │   modelo caro · valida  │
                    └─────────────────────────┘

        (reprovado na revisão volta ao Planejador e refaz o plano)

Subtarefas descem com contexto mínimo; só o diff ou resumo sobe de volta. É essa fronteira estreita que impede o custo de explodir.

Aqui vale uma regra simples: quanto menos informação circula entre os agentes, mais barata fica a conta. O planejador não repassa a conversa inteira para o agente, envia só a subtarefa e o necessário para executá-la. O agente, por sua vez, pode ler quantos arquivos precisar, porque isso acontece no contexto dele e não volta para o planejador. No fim, ele devolve apenas o resultado, um diff ou um resumo curto. Essa disciplina de decidir o que entra e o que sai do contexto de cada agente tem nome, engenharia de contexto, e é ela que sustenta a economia da arquitetura.

Outra economia fácil é o prompt caching. Toda chamada de agente repete um mesmo bloco inicial, com as instruções e a descrição do projeto. Os provedores permitem guardar esse bloco em cache, e reler do cache custa cerca de 10% do preço normal de input. Como os agentes são chamados muitas vezes, esse desconto se acumula rápido.

Como isso funciona na prática

Provavelmente o harness que você usa já consegue ajudar na orquestração. Kiro, Codex e Cursor têm ferramentas de invocação de agentes, cada um com sua sintaxe. O exemplo aqui vai ser com o Claude Code, e para não ficar só na teoria escrevi uma skill que implementa o padrão, pronta para copiar e usar no seu agente:

skill /orquestrar — copie e use no seu agente

O que ela faz: primeiro garante que quem está no comando é um modelo forte. A partir do pedido, o orquestrador monta uma lista de tasks, cada uma com objetivo, arquivos envolvidos, critério de aceite e formato de resposta. Cada task passa por uma rubrica de três níveis:

mecânica: existe padrão pronto para copiar; vai para o modelo econômico.
delimitada: lógica nova de escopo fechado; vai para o modelo médio.
crítica: envolve ambiguidade ou arquitetura; não é delegada, fica com o modelo forte.

Definido o nível, o orquestrador invoca um sub-agente por task com o modelo daquele tier, em paralelo quando as tasks são independentes. Há também um backup: se uma task reprova duas vezes na revisão, sobe um tier e é reexecutada. Como os níveis são bem definidos e cada task é designada com critério, isso raramente acontece, mas a rede de segurança evita que uma task travada queime tokens em repetição. No fim, o modelo forte revisa todas as mudanças e reporta quantos sub-agentes rodaram, qual modelo executou cada task e o resultado de cada uma.

┌────────────────┐   ┌────────────────┐   ┌────────────────┐   ┌────────────────┐
│ Lista de tasks │──▶│ Classificação  │──▶│  Sub-agentes   │──▶│ Revisão final  │
│  modelo forte  │   │define o modelo │   │  um por task   │   │ forte · relata │
└────────────────┘   └────────────────┘   └────────────────┘   └────────────────┘

   (task reprovada duas vezes sobe um tier e volta para os Sub-agentes)

O fluxo da skill: o modelo forte decide no começo e valida no fim; o meio roda no modelo mais barato que a task permitir.

Essa é uma das formas de orquestrar agentes, não a única. Se você já trabalha com spec driven development (SDD), metade do caminho está feita: a especificação escrita antes do código já é a sua lista de tasks, e basta classificar cada item para saber em qual modelo ele roda. Outros métodos comuns:

roteamento por descrição: cada sub-agente declara quando deve ser acionado e a ferramenta escolhe sozinha.
roteador na entrada: um classificador barato lê o pedido e decide o modelo antes de qualquer chamada cara.
cascata: tenta primeiro no modelo barato e só escala para o caro se o resultado não passar.

O método muda, o princípio fica: alguém precisa decidir, task a task, qual inteligência ela merece.

A economia na prática

Cenário: implementar uma feature média com agentes, consumindo 2M de tokens de entrada e 200K de saída na sessão inteira. Na versão orquestrada, o planejador e o revisor ficam com cerca de 10% do volume (planejamento e revisão de diffs) e os agentes de execução com os 90% mecânicos.

Arquitetura	Custo da sessão	Economia
Tudo no Opus 5	$15,00	base
Opus planeja/revisa + Haiku executa	$4,20	3,6x
Opus planeja/revisa + DeepSeek V4-Flash executa	$1,80	8,3x

Abrindo a conta com Haiku: o Opus fica com 0,2M de input ($1,00) e 20K de output ($0,50); o Haiku com 1,8M de input ($1,80) e 180K de output ($0,90). O total de $4,20 contra $15,00 bate com a faixa de 5x a 10x relatada em relatos de uso do padrão orquestrador com sub-agentes baratos. Quanto mais mecânica a fatia dos agentes, mais perto do teto. Com caching no prefixo dos agentes dá para arranhar mais 20% a 30%, já que leitura de cache custa cerca de 10% do preço de input nas tabelas dos provedores.

Fechamento

Orquestração de agentes não economiza tokens por mágica. Um sistema multi-agente ingênuo gasta mais que um agente único. O ganho vem de dar a cada modelo uma função e um objetivo alinhados ao seu preço: planejamento e revisão no modelo de ponta, execução mecânica no modelo barato, contexto isolado e caching no meio. O próximo passo natural deste tema é instrumentar a medição, porque sem visibilidade de tokens por subtarefa não há como saber se a sua orquestração está do lado certo dessa conta.