Workflows dinâmicos no Claude: a conta de muitos agentes

O que mudou em 9 de outubro

As notas de versão da plataforma do Claude registram, em 9 de outubro de 2026, o lançamento em beta dos workflows dinâmicos no Managed Agents. Eles usam o cabeçalho managed-agents-2026-04-01 e são ligados no campo multiagent do agente.

Até então, um agente podia delegar tarefas a subagentes e conversar com cada um. No workflow dinâmico é diferente: o agente escreve um programa que roda muitos agentes em fases, em segundo plano, e combina os resultados. A documentação cita como usos auditorias, migrações, pesquisa extensa e conferência cruzada. O exemplo oficial é justamente o dos 300 contratos.

A mesma documentação dá o aviso que interessa ao bolso: cada agente de uma execução consome tokens. Por isso ela recomenda criar a sessão com um orçamento.

Como a execução é cobrada

A página de workflows é direta: uma execução não tem preço próprio. Os tokens dos agentes são cobrados como os demais tokens da sessão, pelo preço de cada modelo. A página de preços do Managed Agents acrescenta dois pontos:

• o tempo de sessão em estado running também é cobrado (o valor está na página oficial de preços; usamos ele na conta abaixo);
• o desconto da API de Lotes não vale nas sessões do Managed Agents. Os multiplicadores de cache valem do mesmo jeito.

Outro detalhe: um agente definido dentro do workflow usa o modelo do agente principal. Para pôr parte do trabalho num modelo mais barato, é preciso criar esse agente antes e listá-lo em workflows.predefined_agents.

A conta, passo a passo

As premissas abaixo são exemplo, não números da documentação:

Também supomos 1,5 hora de sessão em running.

Com os preços do arquivo do site, atualizado em outubro de 2026:

A leitura responde por 95% do total no cenário Sonnet 5.5. É a parte que se multiplica pelo número de documentos. Por contrato, cada leitor custa US$ 0,0380 no Sonnet 5.5.

Na consolidação, o agente lê 182.000 tokens. Por isso deixamos essa fase no Sonnet 5.5 no cenário misto: no Haiku 5.5, um pedido acima de 100 mil tokens paga a faixa de preço mais alta.

E o cache?

As instruções dos 300 leitores são iguais. Se elas fossem lidas do cache em todos os leitores, a leitura no Sonnet 5.5 cairia de US$ 11,40 para US$ 9,12, no melhor caso. A documentação diz que os multiplicadores de cache valem nas sessões, mas não promete acerto de cache entre agentes que rodam em paralelo. Trate esse número como teto da economia, não como previsão. A calculadora de cache de prompt ajuda a testar taxas de acerto menores.

Os limites que mudam o tamanho da conta

A página de execuções lista limites que valem conferir antes de mandar um lote grande:

Com 300 contratos, o caso cabe numa execução. Um acervo de 2.500 contratos, com um agente por contrato, passa do limite de 1.000 agentes: a execução termina com thread_limit_error. Aí é preciso dividir o trabalho em execuções menores ou agrupar vários contratos por agente.

Os pedidos dos agentes também contam nos limites de taxa da sua organização na Messages API. Com 64 agentes ao mesmo tempo, uma conta com limite baixo vai ver erros de taxa e a execução demora mais. O tempo de sessão continua correndo.

Como pôr um teto no gasto

O orçamento da sessão (budget) é um teto em dólares, escrito em centavos dentro de uma string. Ele soma, pelo preço de tabela, os tokens, as buscas na web e o tempo de sessão. Pontos práticos da documentação:

• o orçamento só pode ser definido na criação da sessão;
• vale para a sessão inteira, com todos os agentes e execuções; não há teto por agente;
• ao chegar no teto, as execuções pausam e a sessão fica idle com budget_reached;
• cada agente termina o pedido que já começou, então o gasto pode passar um pouco do teto;
• o cálculo usa preço de tabela, mesmo que sua empresa tenha desconto negociado.

No caso do Sonnet 5.5, com folga de 30% sobre a estimativa, o teto ficaria em US$ 15,59. Na API, isso vira "amount": "1559".

Erros comuns

• Ligar workflows sem orçamento. O agente decide quando abrir uma execução. Sem teto, uma pergunta mal escrita pode virar centenas de agentes.
• Esquecer que o agente embutido herda o modelo. Se o principal é Opus 5.5, todos os leitores definidos no workflow também serão.
• Contar com desconto de lote. Ele não existe no Managed Agents. Se a tarefa pode esperar e não precisa de agente, a API de Lotes na Messages API sai pela metade do preço.
• Somar o list_cost de cada agente. Essa soma deixa de fora o tempo de sessão e arredonda cada parcela. O número que vale para o teto é o da sessão.

Perguntas frequentes

Quanto custa cada contrato lido no exemplo?

No Sonnet 5.5, US$ 0,0380 por contrato. No Haiku 5.5, US$ 0,0019. No Opus 5.5, US$ 0,0760.

Existe taxa por execução de workflow?

Não. A documentação diz que a execução não tem preço próprio. Você paga os tokens de cada agente e o tempo de sessão. No exemplo com Sonnet 5.5, o tempo de sessão é US$ 0,12 de um total de US$ 11,99.

Quanto economizo pondo os leitores no Haiku 5.5?

No exemplo, o total cai de US$ 11,99 para US$ 1,16, uma redução de 90%. Antes, teste a qualidade da leitura num lote pequeno.

E se eu tiver 1.000 contratos?

Com as mesmas premissas e tudo no Sonnet 5.5, só a leitura sairia por cerca de US$ 38,00. É o limite de agentes de uma execução; acima disso, divida o trabalho.

Em reais, quanto fica o caso?

Pelo dólar de referência do site, R$ 60,09 no Sonnet 5.5, R$ 119,57 no Opus 5.5 e R$ 5,83 no cenário misto.

Quer refazer a conta com o seu volume? Use a calculadora de custo de agentes de código e API com o número de agentes, o contexto e a saída de cada um.