Claude Code Workflows: 41 agentes, 5M tokens, testados
Quarenta e um agentes. Foi quantas instâncias de Haiku um dos meus workflows do Claude Code lançou na semana passada, todas ao mesmo tempo, para auditar e pontuar cada skill que eu tinha instalada. Assisti o contador subir no terminal — 12, 28, 41 — cada um uma chamada completa e independente ao Claude avaliando uma receita diferente contra critérios que eu havia passado ao orquestrador. O processo todo consumiu aproximadamente 5 milhões de tokens de entrada antes de terminar.
Esse número me parou. Cinco milhões. Na maioria dos cálculos de preço, soa como uma conta que induz pânico. Mas aqui está a virada que reenquadrou toda a funcionalidade para mim: a saída foi minúscula. Um relatório classificado, algumas centenas de linhas. Todo aquele gasto de tokens foi em leitura — rastreamento, análise, pontuação — não em geração. Computacionalmente pesado, com certeza. Excessivamente caro? Na verdade não. Tokens de entrada do Haiku são baratos, e 41 deles lendo em paralelo terminaram em uma fração do tempo real que um único agente teria precisado para processar sequencialmente a mesma pilha.
Esse é o momento em que os workflows do Claude Code clicaram para mim. Não como um buzzword do lançamento do Opus 4.8. Como uma ferramenta específica com uma forma específica — uma que é genuinamente diferente de skills, subagentes e equipes de agentes, e uma que é absurdamente fácil de usar errado se você não entender essa forma.
Então é isso que este post é. Não um anúncio de funcionalidade. Um guia de campo. No final você saberá exatamente qual dos cinco primitivos de orquestração pegar — skill, subagente, equipe de agentes, workflow ou o loop /goal — e aproximadamente quanto cada um te custa em tokens e complexidade. Aprendi a maioria disso da maneira um pouco cara. Você não precisa.
O que a Anthropic realmente lançou com Workflows em 28 de maio
Workflows dinâmicos chegaram em 28 de maio de 2026, incluídos no lançamento do Claude Opus 4.8 como research preview. Se você já leu minha análise dos níveis de esforço do Opus 4.8, pense nos workflows como a outra metade desse lançamento — o modelo ganhou um dial de pensamento, e o Claude Code ganhou uma maneira de distribuir esse pensamento por centenas de agentes ao mesmo tempo.
Você precisa do Claude Code v2.1.154 ou posterior para rodá-los. Funcionam na CLI, no app desktop e na extensão do VS Code. E a forma como você dispara um é quase suspeitosamente casual: simplesmente coloque a palavra workflow em algum lugar do seu prompt. Diga "rode um workflow para auditar cada rota de API em busca de verificações de auth faltantes" e o Claude faz algo que nunca fez antes — escreve um script de orquestração em JavaScript na hora, passa para um runtime em segundo plano, e esse runtime lança os agentes.
Dois limites rígidos que vale gravar na memória: o runtime roda até 16 agentes simultaneamente, e limita um único workflow a 1.000 agentes no total. Minha auditoria de 41 agentes de skills não chegou perto do teto. Mas é muito fácil escrever um prompt que chegue — "analise cada arquivo neste monorepo" contra alguns milhares de arquivos vai saturar esse limite rápido e manter a fila processando. Voltaremos a isso, porque é a principal maneira de queimar dinheiro com essa funcionalidade.
Aqui está o detalhe arquitetural que realmente importa. O que torna os workflows diferentes e não simplesmente "subagentes mas mais." Deixe-me mostrar.
O que torna os workflows diferentes: o plano vive fora da cabeça do Claude
Todas as outras ferramentas de orquestração no Claude Code mantêm seu plano dentro da janela de contexto do modelo. A sessão principal lembra o que delegou, rastreia o que voltou, mantém o estado em sua própria memória de trabalho. Isso funciona para um punhado de tarefas. Desmorona em escala, porque janelas de contexto são finitas e cada resultado delegado que você enfia de volta consome espaço que precisa para raciocínio real.
Workflows quebram essa regra completamente. O plano e o estado de execução vivem em um arquivo JavaScript externo, não no contexto do Claude.
Leia isso de novo, porque é todo o jogo. Quando você inicia um workflow, o Claude não apenas decide lançar agentes — ele escreve um script real: loops, lógica de ramificação, quantos agentes lançar, o que cada um recebe, como combinar os resultados, quais rodadas de verificação rodar. Esse script é salvo em uma pasta que você especifica. Um runtime separado o executa em um ambiente isolado, completamente separado da sua sessão de chat. Os resultados intermediários — cada saída bruta de cada agente, cada cálculo auxiliar — ficam nas variáveis do script. Nunca tocam sua conversa.
O que volta para sua sessão é apenas a resposta final combinada.
Imagine a diferença fisicamente. Com subagentes, sua sessão principal é um gerente segurando uma prancheta, rastreando pessoalmente cada relatório conforme chega. Com um workflow, sua sessão principal escreve um programa, entrega a um servidor de build, vai embora, e volta a um único artefato terminado. A prancheta nunca enche. Por isso minha auditoria de 41 agentes não estourou a janela de contexto embora tenha processado 5 milhões de tokens de entrada — 99% desses tokens viveram e morreram dentro das variáveis do script. Minha sessão só viu o relatório classificado no final.
Isso tem duas consequências que não apreciei até rodar alguns. Primeiro, como a orquestração é um arquivo salvo, workflows são re-executáveis e controlados por versão. Você pode commitar o script, fazer diff, passar a um colega. Salve um útil e ele vira um comando slash — seu workflow de revisão de branch vira /my-review, repetível para sempre. Segundo, e isso é crítico para o modelo mental: os agentes gerados não conversam entre si. Cada um é uma chamada completamente independente ao Claude com seu próprio contexto isolado. Eles se espalham, fazem sua única tarefa, retornam um resumo, e é isso. Sem conversa cruzada. Sem debate. A combinação acontece na lógica do script, não em uma conversa entre agentes.
Guarde esse detalhe de "agentes não conversam." É a linha exata que separa um workflow de uma equipe de agentes — e traçar essa linha errado é como pessoas escolhem a ferramenta errada e pagam por isso.
Skill vs subagente vs equipe de agentes vs workflow vs /goal: o modelo mental
Certo. Aqui está a parte pela qual você veio. Cinco primitivos, e a verdade honesta é que a maioria das pessoas só precisava de dois e por entusiasmo foi para os caros. Eu também. Deixe-me percorrer cada um como realmente os uso agora, do mais barato ao mais caro, porque custo e complexidade sobem juntos em uma escada limpa: skills → subagentes → equipes de agentes → workflows. O loop /goal fica de lado como um eixo completamente diferente, e vou explicar por quê.
O que é uma skill no Claude Code?
Uma skill é uma receita reutilizável que roda dentro da sua sessão pessoal do Claude Code. É uma automação de agente único — um conjunto salvo de instruções que o Claude pode invocar sob demanda, por você ou por outras ferramentas, sem lançar nada em paralelo.
Esse é o degrau mais baixo, e deveria ser seu padrão. Uma skill não se espalha. Não ganha seu próprio contexto separado. Roda ali na sua sessão, como uma função que você pode chamar pelo nome. Minha rotina de verificação SEO, meu formatador de mensagens de commit, minha receita de "audite este arquivo para queries N+1" — tudo skills. Baratas de rodar, triviais de manter e reutilizáveis em tudo. Escrevi um argumento completo para construir skills antes de recorrer a agentes, e apoio isso agora mais do que quando publiquei. A grande maioria dos instintos de "preciso de um agente para isso" são na verdade "preciso de uma skill para isso."
Use uma skill quando a tarefa é pequena, repetível e autocontida. Se pode descrevê-la como uma receita, é uma skill. Pronto.
O que é um subagente?
Um subagente roda em paralelo à sua sessão principal mas não compartilha sua janela de contexto, não pode falar com outros subagentes, e reporta seu resultado apenas à sessão principal.
Esse é o próximo degrau, e a palavra-chave é descarregar. Um subagente é para quando você quer que uma tarefa secundária seja feita sem poluir a memória da sua thread principal. Digamos que estou profundo em um refactoring e quero a explicação da suite de testes resumida sem descarrilar meu contexto — passo para um subagente. Ele vai, faz a coisa, volta com uma resposta, e a memória de trabalho da minha sessão principal fica limpa. O trade-off que elimina é overhead de comunicação. Um subagente não coordena, não negocia, não avisa mais ninguém. É um recado de ida. Isso é uma feature, não uma limitação — torna subagentes baratos e previsíveis.
Use um subagente quando tem uma tarefa secundária simples e independente e quer tirá-la do seu contexto principal. Sem colaboração necessária. Apenas "vá resolver isso e reporte."
O que é uma equipe de agentes?
Uma equipe de agentes é um pequeno grupo de agentes que se comunicam, compartilham tarefas e colaboram em direção a um objetivo, dentro de sua própria janela de contexto compartilhada — agentes debatem, coordenam e constroem sobre o trabalho uns dos outros.
Agora estamos no degrau caro, e a palavra que distingue é conversar. Diferente dos subagentes, os membros de uma equipe de agentes podem se ver e trocar informações. Compartilham contexto. A descoberta de um agente informa a do outro. Debatem, transferem, convergem. Detalho exatamente como e quando agentes devem conversar entre si em um post dedicado, e a versão curta é: essa conversa é todo o ponto, e também é por que equipes custam dinheiro real. Contexto compartilhado mais ida e volta significa mais tokens, mais rodadas, mais computação.
Use uma equipe de agentes quando a tarefa é genuinamente colaborativa — quando a discussão entre agentes produz algo que nenhum agente sozinho poderia, e quando compartilhar contexto entre eles é vital. Debates de arquitetura. Revisões de múltiplas perspectivas onde a crítica de um agente afina a proposta do outro. Não para throughput. Para deliberação.
O que é um workflow?
Um workflow é um sistema orquestrado por JavaScript que lança muitos agentes independentes — possivelmente centenas — rodando em paralelo em pedaços diferentes de uma tarefa, depois combina seus resultados em lógica de script. Os agentes não se comunicam; o plano vive em um arquivo externo, não no contexto do Claude.
Degrau mais alto. Mais poderoso, mais complexo, mais caro. Tudo que descrevi duas seções atrás. O traço definidor, o que o separa de uma equipe de agentes: largura sem conversa. Uma equipe são poucos agentes conversando. Um workflow são muitos agentes não conversando — cada um processando sua própria fatia, resultados combinados por código. Meus 41 avaliadores Haiku foram um workflow de livro-texto: 41 trabalhos independentes, zero conversa cruzada, um ranking combinado no final.
Use um workflow quando uma tarefa naturalmente se fragmenta em muitos pedaços independentes e paralelizáveis. Rastrear uma codebase inteira. Pontuar um dataset grande. Pesquisa ampla por dezenas de ângulos. O tipo de trabalho onde os pedaços não precisam saber uns dos outros — só precisam ser todos feitos, rápido, e consolidados.
O que o comando /goal faz?
/goal roda um processo em loop onde um agente continua iterando no mesmo problema até que uma condição de conclusão seja atingida — pode rodar muitos ciclos e levar muito tempo.
Aqui é por que disse que /goal está em um eixo diferente. Tudo acima é sobre quantos agentes e se conversam. /goal é sobre quantas vezes um esforço itera. É um loop. Você dá um alvo e uma definição de pronto, e ele processa — tenta, avalia, refina, tenta de novo — até a condição ser satisfeita. Pode rodar uma dúzia de ciclos. Pode levar bastante tempo. Isso é esperado.
Use /goal quando a tarefa precisa de profundidade — refinamento iterativo em direção a um alvo difícil — em vez de largura.
E essa palavra, profundidade, é a chave de todo o mapa. Deixe-me tornar concreto.
Largura vs profundidade: o framework que finalmente fez isso clicar
Aqui está a frase que reorganizou como penso sobre tudo isso:
Workflows são largura. /goal é profundidade.
Um workflow se espalha — muitos agentes, cada um lidando com um pedaço diferente, todos ao mesmo tempo. Largura. Você usa quando o trabalho é largo: cem arquivos para escanear, cinquenta afirmações para verificar, uma pilha grande e plana de tarefas independentes. O ganho é paralelismo. Você troca tokens por tempo real e faz um trabalho largo rapidamente.
O loop /goal se aprofunda — um esforço, refinado repetidamente, até estar certo. Profundidade. Você usa quando o trabalho é profundo: um único problema complicado que precisa ser martelado ciclo após ciclo até passar uma barra. O ganho é persistência. Você troca tempo por qualidade em uma coisa difícil.
Uma vez que tive esse framework, escolher a ferramenta parou de ser adivinhação. Largo e raso? Workflow. Estreito e profundo? /goal. Precisa de ambos — um trabalho largo onde cada pedaço também precisa de refinamento iterativo? É onde você os combina cuidadosamente, e serei honesto sobre como isso funciona em um momento, porque é poderoso e é uma ótima maneira de queimar uma fortuna.
Essa lente de largura versus profundidade também explica as duas funcionalidades destaque que a Anthropic enviou em cima dos workflows. Ambas são workflows por baixo, mirando nos dois extremos desse espectro.
Ultra Code e /deep-research: workflows sem luvas
Duas coisas ficam em cima do motor bruto de workflows, e você deveria saber que existem antes de decidir se precisa delas.
Ultra Code (/effort ultracode) é a configuração máxima: maior esforço de raciocínio mais orquestração automática de workflows. Ligue e o Claude decide, para cada tarefa substancial na sessão, se planeja um workflow para ela. Um único pedido pode se desdobrar em vários workflows consecutivos — um para entender o código, um para fazer a mudança, um para verificar. É o modo mais capaz que o Claude Code tem. Também é, sem surpresa, a coisa mais cara que você pode rodar. Maior esforço queima mais tokens de pensamento, e embrulhar isso em orquestração automática multiplica a contagem de agentes. Recorro ao ultracode quando estou fazendo algo genuinamente difícil e genuinamente valioso. Não o deixo ligado por padrão. É assim que se consegue uma conta surpresa.
/deep-research é o workflow embutido voltado para a forma de pesquisa. Faça uma pergunta e ele espalha buscas web por múltiplos ângulos, obtém e cruza as fontes, faz agentes votarem em afirmações concorrentes, e sintetiza um único relatório citado. É um workflow construído para largura de investigação — largura aplicada ao conhecimento em vez de código. Se você já usou as diversas ferramentas de deep-research por aí, é esse padrão, nativo no Claude Code, rodando no mesmo motor de orquestração da minha auditoria de 41 agentes.
Você gerencia tudo com um comando: /workflows. Rode a qualquer momento para ver o que está rodando, o que terminou, e para abrir uma visualização de progresso — ou para parar um workflow que claramente está saindo dos trilhos. Já apertei esse botão de parar. Mais de uma vez. O que me leva à parte deste post que mais quero que você leia.
O que errei: os erros de tokens sobre os quais ninguém te avisa
Serei direto — meu primeiro instinto com workflows foi jogá-los em tudo, e isso foi um erro que me custou tokens e me ensinou as regras reais.
Erro um: usei um workflow para um trabalho que não era largo. No início, lancei um workflow para uma tarefa que realmente eram só três passos sequenciais em um arquivo. Montar a orquestração, escrever o script, lançar agentes — todo aquele overhead, para algo que uma única skill teria resolvido em um quarto dos tokens. Workflows são exagero para trabalhos pequenos ou simples, ponto. A orquestração custa algo mesmo antes dos agentes rodarem. Se a tarefa genuinamente não se fragmenta em muitos pedaços independentes, você está pagando o imposto de configuração por nada.
Erro dois: fui vago, e um workflow me levou ao pé da letra. Pedi a um para "revisar a codebase em busca de problemas." Sem escopo, sem entregável, sem limites. Felizmente se espalhou por muito mais arquivos do que me importava, cada agente uma chamada completa ao Claude, o medidor de tokens de entrada girando como caça-níqueis. Esse é o modo de falha. Workflows podem queimar tokens de entrada absurdamente rápido em trabalhos largos precisamente porque são projetados para rastrear largo. Um workflow faz exatamente o que você disse — e na escala de centenas de agentes paralelos, "exatamente o que você disse" inclui cada interpretação solta de um prompt descuidado.
A solução para ambos é a mesma, e é chata, e funciona: seja explícito e específico. Defina o entregável. Limite o escopo. "Audite os 14 arquivos em app/Http/Controllers para middleware de autorização faltante e retorne uma tabela de arquivo, rota e a verificação faltante" dá ao orquestrador uma parede onde parar. "Revise o código" dá um continente.
Aqui está a regra pela qual agora realmente vivo. Um workflow é a ferramenta certa somente quando tudo isso é verdade: a tarefa é grande, os pedaços são independentes, e esses pedaços são paralelizáveis. Erre em qualquer um e você escolheu o primitivo errado. Grande mas sequencial? Use /goal. Pequeno mas repetido? Use uma skill. Colaborativo e baseado em discussão? Use uma equipe de agentes. As escolhas de orquestração seguem a mesma lógica moldada pela tarefa que trabalhei na minha análise de arquitetura de enxames de agentes — combine a estrutura ao trabalho, não ao seu entusiasmo.
Se prefere não aprender esse cálculo queimando tokens em um repo de cliente ao vivo, esse é exatamente o tipo de setup de orquestração que construo e ajusto para equipes — você pode ver o que aceito no meu Fiverr. Acertar a seleção de primitivos da primeira vez é a maior parte do valor.
O truque que muda a economia: aninhar skills dentro de workflows
Aqui está o movimento que fez workflows parecerem menos com um poço de dinheiro e mais com alavancagem. Você pode aninhar skills dentro de um workflow. Cada um dos muitos agentes que um workflow lança pode chamar suas receitas reutilizáveis existentes.
Pense no que isso faz. Você investe o esforço uma vez para escrever uma skill precisa e bem testada — digamos, uma receita precisa de "pontue este arquivo de skill contra estes dez critérios." Então um workflow lança 41 agentes e cada um roda essa mesma skill contra um alvo diferente. Você obtém o paralelismo de um workflow com a consistência e manutenibilidade de uma skill. A camada cara e complexa se apoia na camada barata e simples. Essa é a arquitetura que alcancei para a auditoria que abriu este post, e é por isso que a saída foi tão limpa — cada um daqueles 41 agentes avaliava pela mesma rubrica, porque todos rodavam a mesma skill.
Essa é a parte da escada custo-complexidade que as pessoas perdem. Os degraus não são mutuamente excludentes. O padrão inteligente é a ferramenta mais barata fazendo o trabalho real, envolvida na ferramenta cara apenas onde genuinamente precisa da escala. Workflows em cima, skills embaixo. Você não está escolhendo entre eles — está empilhando.
Você pode ir além e combinar um workflow com /goal — largura e profundidade juntas, muitos agentes paralelos cada um iterando em direção a um alvo. É a orquestração mais poderosa que já rodei. Também é a coisa mais cara neste post inteiro, por uma margem ampla, e trato como uma ferramenta elétrica sem proteção. Vale para um trabalho genuinamente grande e genuinamente difícil. Uma ótima maneira de evaporar tokens em qualquer coisa menor.
Um breve parêntese que não tem nada a ver com workflows: se tudo isso parece mais orquestração do que seu problema real precisa — digamos que só quer construir um app ou site de IA com algumas conexões MCP, não coordenar 41 agentes — o Lovable é uma rampa de acesso muito mais simples. Conecta servidores MCP e dá uma experiência de construção que não requer nada disso. É uma ferramenta diferente para uma altitude diferente. Todo o ponto deste post é combinar a ferramenta com a tarefa, então seria hipócrita não mencionar. Agora de volta aos agentes.
O que isso realmente te custa — e como saber se está funcionando
Deixe-me fundamentar a economia, porque "5 milhões de tokens" sem contexto é aterrorizante ou sem sentido dependendo do que assume.
O número que importa não é o total de tokens — é quais tokens. Minha auditoria de 41 agentes foi quase completamente tokens de entrada, e rodei os avaliadores no Haiku. Nos preços publicados da Anthropic, entrada do Haiku custa uma fração de centavo por mil tokens, então 5 milhões de tokens de entrada de modelo barato lendo é uma conta fundamentalmente diferente de 5 milhões de tokens de saída de geração do Opus. A lição generaliza: o custo de um workflow é dominado por quanto seus agentes leem, vezes o preço do modelo com que leem. Escolha o modelo deliberadamente. Modelos baratos para rastreamento largo e raso. Modelos caros apenas para os pedaços que precisam de raciocínio real.
Como saber se um workflow é a escolha certa antes de rodá-lo? Faça esse teste de instinto. Conte os pedaços independentes. Se a tarefa se divide em aproximadamente dez ou mais fragmentos que genuinamente não dependem uns dos outros, o paralelismo vai pagar o overhead de orquestração — esse é seu sinal verde. Menos que isso, ou os pedaços dependem entre si, e um primitivo mais simples quase certamente ganha no custo.
E uma vez rodando, observe duas coisas em /workflows: a contagem de agentes e o tempo real. Se a contagem de agentes está subindo para território que não pretendia — aquele fan-out de escala de monorepo — pare e aperte seu escopo. Se um workflow está demorando muito mais que o trabalho sequencial equivalente, a tarefa provavelmente não era paralelizável e você escolheu errado. Toda a promessa de largura é tempo real mais rápido através de paralelismo. Se não está obtendo isso, a forma estava errada.
A recompensa realista, quando a forma está certa: trabalhos que teriam levado um único agente uma hora de processamento sequencial terminam em minutos, porque o trabalho era largo e você deixou se espalhar. Essa é toda a proposta de valor. Não é magia. Apenas paralelismo, corretamente aplicado, com o plano mantido seguramente fora da cabeça do modelo.
A decisão que torna tudo isso fácil
Volte àquele contador de terminal subindo além de 41. A razão pela qual aquela execução pareceu boa em vez de imprudente não foi a tecnologia. Foi que eu havia combinado a ferramenta com a forma do trabalho: uma pilha larga e plana de trabalhos de pontuação independentes, cada um rodando uma skill idêntica, resultados combinados em código, saída pequena. Primitivo certo, modelo certo, escopo limitado. Tudo downstream daquela decisão foi fácil.
Essa é toda a habilidade aqui, e realmente não é sobre Claude Code. É sobre olhar para uma tarefa e fazer uma pergunta antes de tocar em um único comando: isso é largo ou profundo, colaborativo ou independente, grande ou pequeno? Responda isso honestamente e a ferramenta se escolhe. Skill para o pequeno e repetido. Subagente para o recado secundário simples. Equipe de agentes para o debate genuíno. Workflow para o rastreamento largo e independente. /goal para a iteração profunda. As ferramentas caras envolvendo as baratas, nunca o contrário.
Então antes do seu próximo grande trabalho — a auditoria de codebase, a pesquisa ampla, o dataset que vem adiando — pare e nomeie sua forma em voz alta. Largo ou profundo? Essa única palavra vai te poupar mais tokens que qualquer configuração no app. Qual é a tarefa mais larga no seu prato que está fazendo um arquivo por vez agora?
Perguntas frequentes
O que são workflows dinâmicos do Claude Code?
Workflows dinâmicos do Claude Code são uma funcionalidade, lançada em 28 de maio de 2026, que permite ao Claude escrever um script de orquestração em JavaScript e rodar muitos agentes independentes em paralelo em pedaços diferentes de uma tarefa. O plano vive em um arquivo externo, não na janela de contexto do Claude, e os agentes não se comunicam — resultados são combinados em lógica de script. Você dispara um incluindo a palavra "workflow" no seu prompt (requer Claude Code v2.1.154+).
Como os workflows são diferentes de subagentes e equipes de agentes?
Workflows lançam muitos agentes não comunicantes em paralelo com o plano em um script externo, enquanto subagentes rodam tarefas secundárias isoladas que reportam apenas à sessão principal, e equipes de agentes são um grupo pequeno que sim conversa e compartilha contexto para colaborar. A regra limpa: subagentes descarregam, equipes deliberam, workflows se espalham largo. Para a distinção mais profunda sobre quando agentes devem se comunicar, veja meu guia de equipes de agentes.
Quando devo usar um workflow versus o comando /goal?
Use um workflow para largura — muitos pedaços independentes e paralelizáveis como rastrear uma codebase ou pontuar um dataset — e use /goal para profundidade, onde um esforço itera em loop até atingir um alvo. Workflows se espalham; /goal se aprofunda. Se a tarefa é larga e rasa, workflow. Se é estreita e profunda, /goal.
Quanto custam os workflows do Claude Code em tokens?
O custo de um workflow é dominado por quanto seus agentes leem multiplicado pelo preço do modelo que usam, então a mesma execução de 5 milhões de tokens é barata em entrada de Haiku e cara em saída de Opus. Os custos disparam quando os prompts são vagos ou o escopo não é limitado, porque cada um dos até 1.000 agentes é uma chamada completa ao Claude. Limite o escopo e escolha modelos baratos para rastreamento largo e raso. Para o lado do modelo, veja minha análise dos níveis de esforço do Opus 4.8.
O que é o modo Ultra Code no Claude Code?
Ultra Code (/effort ultracode) combina o maior esforço de raciocínio com orquestração automática de workflows, permitindo que o Claude decida quando cada tarefa substancial justifica lançar um workflow. É o modo mais capaz do Claude Code e o mais caro — um único pedido pode se desdobrar em vários workflows consecutivos. Use para trabalho genuinamente difícil e de alto valor, não como padrão.
Vamos trabalhar juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- Fiverr (desenvolvimento personalizado e integrações): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
