Dynamic workflows do Claude Code explicados: ultracode, /workflows e o limite de 1.000 agentes (2026)

- Cada número e limite de versão aqui foi conferido, por mim mesma, contra a documentação oficial (code.claude.com/docs/en/workflows) na data em que escrevi (08/2026); esse recurso muda quase a cada release, então confira a documentação ao vivo antes de depender dele.

Este é um conteúdo avançado - escrito para quem já usa o Claude Code com subagents e skills; ele não reensina o básico. Se você não tem certeza do que é um subagent, leia primeiro como os subagents do Claude Code funcionam ou o que é uma skill do Claude Code.

O que um dynamic workflow realmente é

Um dynamic workflow não é um recurso de interface separado - é um mecanismo: uma vez acionado, o Claude escreve um script em JavaScript descrevendo o plano (o que roda primeiro, o que roda em paralelo, o que espera o resultado de um passo anterior). Esse script distribui o trabalho para muitos subagents em segundo plano, e o Claude guarda apenas o resultado final no contexto da sessão principal - não todo o rastro de raciocínio de cada subagent.

Compare isso com um turno normal, mesmo um em que você pediu ao Claude para delegar a um subagent: a sessão principal ainda precisa segurar a saída de cada subagent no próprio contexto para decidir o que vem a seguir, e se você fechar a sessão no meio da tarefa, aquele raciocínio em andamento se perde. Um dynamic workflow tira a decisão de "o que vem a seguir" completamente da conversa e a coloca no script, e é isso que torna possível uma execução com 1.000 agentes sem estourar a janela de contexto da sessão principal.

Um exemplo ilustrativo para deixar o mecanismo concreto (não são dados medidos de verdade, só a lógica): você pede ao Claude para auditar todo o diretório src/ em busca de problemas de segurança. O script que ele escreve pode ser algo como "entregar cada subdiretório a um agente próprio para escanear, qualquer agente que encontrar um problema reporta com evidências, um agente final agrega tudo em uma tabela" - toda essa lógica de ramificação, espera e agregação vive no arquivo de script, e não na memória de trabalho do Claude, como acontece quando você orquestra subagents na mão.

Requisito: Claude Code v2.1.154 ou mais novo (limite de versão - confira a sua própria versão antes de depender disso), disponível em todo plano pago mais API/Bedrock/Vertex/Microsoft Foundry. No Pro, ele não vem ativado por padrão - você liga manualmente na linha "Dynamic workflows" em /config. Não confunda isso com o auto-mode (ativado por padrão desde 2026-08-14) - esse é um recurso completamente diferente, sem relação com dynamic workflows, mesmo que os dois tenham aparecido mais ou menos na mesma leva de releases.

Requer o Claude Code v2.1.154+ (confira sua versão de verdade primeiro); roda em todo plano pago mais API/Bedrock/Vertex/Microsoft Foundry; usuários do Pro precisam ativar manualmente em /config, ele não vem ligado por padrão.

Duas formas de acioná-lo

Existem duas formas de chamar um dynamic workflow, dependendo de você querer ele para uma tarefa só ou para a sessão inteira.

Um detalhe histórico que a maioria dos textos pula: a palavra-chave digitada costumava ser workflow antes da v2.1.160, e depois foi renomeada para ultracode na v2.1.160. Mas a forma em linguagem natural ("usa um workflow pra isso") sempre funcionou nas duas épocas - ela nunca dependeu da palavra-chave exata. Se você vir documentação ou posts antigos dizendo "digite workflow", essa é a nomenclatura anterior à v2.1.160.

Uma pegadinha que vale lembrar: a palavra-chave só dispara a partir de entrada humana, digitada - não pela flag -p, não por entrada não humana do Agent SDK, não por tarefas agendadas, e não por relays de webhook/comentário de PR. Se você está automatizando o Claude Code por qualquer um desses canais, digitar "ultracode" em algum lugar não vai acionar um dynamic workflow sozinho.

Qual método escolher depende do que você está fazendo. Para uma tarefa grande dentro de uma sessão que, no resto, é normal (digamos, "ultracode: audite todo o tratamento de erros no diretório api/"), digitar a palavra-chave só naquele turno já basta - o resto da sessão roda como sempre, sem sobrecarga extra de raciocínio nas coisas pequenas. Se você já sabe que a sessão inteira vai ser trabalho pesado (um dia reservado para uma migração ou uma auditoria), o /effort ultracode te poupa de redigitar a palavra-chave a cada turno - mas o trade-off é que toda tarefa substancial daquela sessão é empurrada para o raciocínio xhigh, inclusive coisas que você nunca pretendeu rodar como workflow.

Experimente primeiro o workflow embutido /deep-research

A forma mais rápida de ver um dynamic workflow rodando de verdade, com zero configuração, é o workflow embutido /deep-research:

1. Rode /deep-research <your question>.
2. Aprove o plano que o Claude propõe antes de ele rodar.
3. Acompanhe o progresso com /workflows.
4. Leia o relatório final - ele vem com citações.

A parte interessante: afirmações que não passam na verificação cruzada são filtradas para fora, e afirmações que não dão para verificar são marcadas como não verificadas em vez de simplesmente refutadas - um modo de falha diferente do Claude inventando uma única resposta com toda a confiança. Repare que esse workflow precisa da ferramenta WebSearch ativada. Se você ainda está meio confusa sobre o que é um subagent, leia como os subagents do Claude Code funcionam antes da próxima seção.

Por que vale a pena experimentar primeiro: é o único workflow em que você não precisa escrever o prompt de orquestração - a Anthropic já empacotou a lógica de "achar fontes → verificação cruzada → filtrar afirmações fracas → escrever um relatório com citações" lá dentro. Rode uma vez em uma pergunta técnica concreta (digamos, "compare como o Next.js 16 e o Remix lidam com streaming SSR") e você vai ver o formato geral que todo dynamic workflow segue: um plano aprovado logo no começo, vários agentes rodando em paralelo que você não precisa vigiar passo a passo, e um resultado final que já veio filtrado em vez de uma única resposta não verificada.

Acompanhe e gerencie uma execução - /workflows

Digite /workflows para abrir a visão de acompanhamento ao vivo: fase atual, quantos agentes estão rodando, total de tokens gastos, tempo decorrido - tudo em uma tela só que atualiza em tempo real.

Essa visão importa mais do que parece: é a única forma de saber o quanto uma execução está "comendo" antes que ela coma seu limite semanal - mais sobre custo abaixo. Pense como deixar um pipeline de CI rodar sem um dashboard: pode até terminar bem sozinho, mas vale ficar de olho numa execução grande nas primeiras vezes, pelo menos até você pegar o jeito de quanto token ela queima no tipo de tarefa que você costuma passar para ela.

Os números para saber antes de ligar isso

Esta é a seção que vale ler com atenção antes de apontar esse recurso para qualquer coisa grande, já que nenhum desses números é óbvio pela interface até você ir procurar.

Limites rígidos: até 1.000 agentes por execução (evita que um loop descontrolado rode para sempre), e até 16 agentes simultâneos (menos em máquinas/contêineres limitados de CPU). O número 1.000 é um teto para a execução inteira, não uma meta - a maioria das tarefas reais termina com bem menos agentes; ele existe justamente para impedir que um script mal delimitado gere agentes indefinidamente se uma condição de parada nunca disparar.

As diretrizes de tamanho são orientativas, não um limite rígido (requer v2.1.202+ - limite de versão, confira antes de depender disso). Você pode definir uma se quiser forçar o Claude a manter a contagem de agentes mais baixa que o padrão.

O aviso de workflow grande (Large): dispara quando uma execução ultrapassa 25 agentes OU 1,5 milhão de tokens projetados (o 25 muda se você definiu sua própria diretriz de tamanho). Ele é apenas orientativo - não pausa a execução. Sessões que já estão rodando /effort ultracode não mostram esse aviso, já que optar por esse modo significa que você aceitou execuções grandes desde o começo.

Juntando os números: uma auditoria limitada a um diretório com algumas dezenas de arquivos, na diretriz de tamanho padrão medium (abaixo de 15 agentes), quase nunca vai encostar no limiar de aviso de 25 agentes. Mas uma migração que abrange mais de 200 arquivos em um repositório inteiro pode facilmente estourar tanto os 25 agentes quanto o 1,5 milhão de tokens - a esse ponto é melhor definir a diretriz de tamanho para large de propósito (ou aceitar o aviso) do que ser surpreendida no meio da execução. Dito de outro jeito, os números 1.000/16/25 não estão ali para te afastar do recurso - estão ali para você conseguir estimar "o quão grande é isso que estou prestes a entregar" antes de apertar enter.

Workflows vs subagents vs skills vs agent teams - quem segura o plano

Essa é a pergunta mais importante se você já usa subagents e skills: esses quatro diferem em quem segura o plano de orquestração, não em qual deles é "mais forte".

Em termos simples: subagents e skills deixam o Claude decidir cada passo sozinho, limitado pela janela de contexto daquela sessão. Agent teams (experimental - veja agent teams para colaboração entre múltiplas sessões) é um agente líder supervisionando agentes pares através de uma lista de tarefas compartilhada, feito para sessões colaborativas longas. Um dynamic workflow é diferente porque o plano vive em um script, não no contexto do Claude - então o contexto principal só precisa segurar a resposta final, não o processo inteiro.

Escolha rápida: delegação de rotina → subagents/skills. Uma sessão longa e colaborativa que precisa de supervisão contínua → agent teams. Uma tarefa maior que uma janela de contexto, ou que precisa de verificação cruzada adversarial (vários agentes checando o resultado uns dos outros) → um dynamic workflow. Quer definir seu próprio subagent reutilizável? Veja o guia de subagents; precisa do básico de skills primeiro? Veja o que é uma skill do Claude Code.

A confusão mais fácil entre esses quatro: subagents e skills ambos deixam o Claude da sessão principal tomar a decisão - eles diferem só em que uma skill é um pacote de instruções carregado pelo contexto, enquanto um subagent é uma "persona" separada invocada para fazer um trabalho e devolver os resultados. Ambos vivem e morrem pela janela de contexto daquela sessão: interrompa a sessão no meio e o progresso se foi. Agent teams e dynamic workflows ambos escapam desse limite, mas de formas diferentes - agent teams escapam deixando várias sessões colaborarem através de uma lista de tarefas compartilhada que sobrevive ao contexto de qualquer agente sozinho; dynamic workflows escapam tirando o plano completamente do contexto e transformando-o em um objeto que você pode salvar, versionar no git e rodar de novo igualzinho a qualquer momento - que é exatamente por que ele combina mais com trabalho grande e repetível do que com uma conversa exploratória.

Salve um workflow que você gostou como um comando reutilizável

Curtiu uma execução? Salve para não ter que fazer o Claude reescrever o script do zero na próxima vez:

1. Abra o /workflows, selecione a execução que você quer guardar.
2. Aperte s para salvar.
3. Escolha onde: .claude/workflows/ (compartilhado, no escopo do projeto) ou ~/.claude/workflows/ (pessoal).
4. O workflow salvo vira um comando /<name>, e pode receber entrada através de um parâmetro args.

Se você trabalha em equipe, um workflow também pode ser distribuído dentro de um plugin (um diretório workflows/), chamado com um /plugin-name:workflow-name com namespace - ótimo para compartilhar um script de orquestração com o time inteiro em vez de ficar copiando e colando comandos.

A parte boa de salvar um workflow como arquivo: como ele vive como um arquivo de texto puro dentro de .claude/workflows/, você faz commit dele no git como qualquer outra coisa do repositório. Um colega que der pull na branch recebe o mesmo workflow automaticamente - o Claude não precisa "reaprender" a abordagem de auditoria ou migração que você já ajustou. Essa também é a diferença mais clara em relação a subagents e skills: um subagent que você gosta de usar não vira automaticamente algo que um colega possa invocar igualzinho - um dynamic workflow salvo, sim.

A realidade do custo em tokens

Vou ser direta: a documentação oficial não dá nenhum valor fixo em dólares para dynamic workflows, e eu não vou inventar um só para fazer esta seção parecer completa. Tem uma história circulando - algo tipo "um plano Max de $200/mês queimou 20% de um limite semanal em um dia" - eu mesma fui checar, e ela remonta a um post de blog que sintetiza um relato de rede social, não a uma fonte primária nem verificável de forma independente, então não vou repetir esse número aqui.

O que a documentação de fato diz com clareza: os dois limites rígidos (1.000 agentes / 16 simultâneos) existem justamente para conter custo descontrolado. Todo subagent usa o modelo da sessão principal, a menos que o script ou a variável CLAUDE_CODE_SUBAGENT_MODEL o direcione para outro lugar.

Conselho prático, apoiado na documentação:

• Teste primeiro em uma fatia pequena (um diretório, não o repositório inteiro) antes de uma execução completa.
• Acompanhe os totais de tokens por agente ao vivo no /workflows enquanto a execução está em andamento.
• Baixe a diretriz de tamanho para small se quiser forçar uma contagem de agentes menor que o padrão.

Por que eu não invento uma estimativa própria: o custo real depende de variáveis demais ao mesmo tempo - quanto tempo cada subtarefa roda, para qual modelo a sessão está configurada, quantos agentes o próprio script decide gerar por ramificação - então qualquer número "médio" único enganaria mais do que ajudaria. Uma abordagem bem mais segura é medir sua própria carga: rode uma passada pequena, leia a contagem de tokens no /workflows, e escale de forma aproximadamente linear até o tamanho que você realmente planeja rodar - em vez de confiar num número que alguém pescou nas redes sociais.

O AgentKit te dá isso? (a resposta honesta)

Uma pergunta que vale fazer se você já usa o AgentKit: o AgentKit tem uma coisa de "workflow" própria, e ela é a mesma coisa que isto? Resposta direta: não. Dynamic Workflows é um motor nativo do Claude Code - exatamente o mecanismo de distribuição de agentes por script JavaScript que este artigo descreve. O AgentKit não traz esse motor, e não tem um equivalente do lado do ak.

Eu mesma conferi docs.agentkit.best/en/beta/reference/cli direto (08/2026): a palavra "workflow" no site do AgentKit é texto de marketing genérico para o pacote de skills dele, e o comando ak orchestrate é um recurso completamente diferente - um grafo de jobs para ferramentas de CLI externas, só para macOS, sem relação com os dynamic workflows do Claude Code.

Então o que o AgentKit de fato te dá? Um conjunto curado e licenciado de skills e personas de subagent (chamado através de /ak:cook e comandos parecidos) para o qual você pode apontar um dynamic workflow - seja você escrevendo o script, seja deixando o Claude escrever - usados como tarefas de agente individuais, igual a qualquer outro subagent. Resumindo: compre o AgentKit pela camada pronta de skill/persona; use Dynamic Workflows (grátis, nativo) pela camada de orquestração em escala. Eles se somam, não competem. Leia a análise completa do AgentKit para mais.

Um exemplo ilustrativo de como as duas camadas se encaixam (não é um resultado medido, só um padrão de uso): um dynamic workflow auditando segurança em cinco microsserviços poderia entregar cada serviço a um agente rodando a skill ak-security do AgentKit, e depois ter um agente final agregando os achados dos cinco. O script de orquestração (o que roda em paralelo, o que espera o quê) pertence ao Dynamic Workflows; o conhecimento de domínio dentro de cada agente pertence à skill que você comprou. Tire o AgentKit e o workflow ainda roda - cada agente só recorre ao conhecimento geral do Claude em vez de uma skill feita sob medida para aquele trabalho.

Você deveria ligar isso hoje

Não existe uma resposta universal aqui, o que, honestamente, é uma conclusão mais útil do que um sim/não categórico - a decisão certa depende do quão grande e do quão repetível sua próxima tarefa realmente é, não de o recurso ser novo e empolgante. Veredito curto: experimente a palavra-chave ultracode em uma tarefa real e delimitada primeiro (uma auditoria de um único diretório, não uma migração do repositório inteiro), antes de decidir configurar /effort ultracode para a sessão toda. Boa pedida para: migrações grandes, auditorias em toda a base de código, pesquisa que precisa de verificação cruzada entre fontes. Pule para: pequenas edições de rotina, ou se você está num plano Pro sensível a custo sem folga.

Um checklist rápido antes de apertar enter: (1) a tarefa é grande o suficiente para dividir em ramificações independentes, ou é na verdade uma cadeia sequencial que você faria mais rápido na mão; (2) você vai mesmo manter o /workflows aberto para acompanhar, ou está planejando sair de perto; (3) se essa execução falhar no meio, você fica tranquila com os tokens já gastos. Se as três respostas forem "sim", pode ligar; se a pergunta um for "não", um subagent simples geralmente ainda é mais rápido e mais barato.

FAQ

O que é o ultracode no Claude Code?

Ultracode é a palavra-chave (e configuração de effort) que aciona um dynamic workflow - o Claude escrevendo um script em JS que distribui uma tarefa para até 1.000 subagents em segundo plano. Digitar "ultracode" ou fraseá-lo de forma natural, tipo "usa um workflow pra isso", ambos acionam.

Quantos agentes um dynamic workflow consegue rodar?

Até 1.000 agentes por execução, com até 16 rodando ao mesmo tempo (menos em máquinas/contêineres limitados de CPU). Esses são limites rígidos, não recomendações.

O que dispara o aviso de workflow grande (Large)?

Uma execução ultrapassando 25 agentes ou 1,5 milhão de tokens projetados (o 25 muda conforme sua própria diretriz de tamanho). É apenas orientativo e não pausa a execução.

Um dynamic workflow é a mesma coisa que agent teams?

Não. Agent teams é um agente líder supervisionando agentes pares através de uma lista de tarefas compartilhada, feito para sessões colaborativas longas (um recurso experimental). O plano de um dynamic workflow vive em um script escrito de antemão em vez do contexto do Claude, e pode ser salvo e rodado de novo igualzinho - agent teams geralmente não dá para reproduzir da mesma forma duas vezes.

Eu preciso de um plano pago?

Sim. Ele roda em todo plano pago mais API/Bedrock/Vertex/Microsoft Foundry. Usuários do Pro precisam ativar manualmente na linha "Dynamic workflows" em /config; ele não vem ligado por padrão.

O AgentKit inclui os dynamic workflows do Claude Code?

Não. Dynamic Workflows é um motor nativo e gratuito do Claude Code. O AgentKit é um conjunto separado e pago de skills e personas de subagent que você pode usar como tarefas de agente individuais dentro de um dynamic workflow - os dois se complementam, não são a mesma coisa.

Conclusão

Dynamic workflows é um recurso para usuárias avançadas: limites reais (1.000 agentes/16 simultâneos), um aviso orientativo em 25 agentes/1,5 milhão de tokens, e ele se junta a - em vez de substituir - a camada de skills do AgentKit. Experimente em algo pequeno antes de ligar para uma sessão inteira, e mantenha o /workflows aberto para você sempre saber quanto está gastando. Os portões de versão se movem rápido, então trate cada limite deste artigo como um ponto de partida, não como verdade absoluta - reconfira a documentação ao vivo no dia em que você realmente ligar isso para algo que importa.