Introdução: mesmas verificações, o dobro do medidor, cinco limites
Ultracode é a palavra-chave, ou o toggle, que transforma um único pedido digitado no Claude Code em uma equipe inteira de agentes. Num teste pareado com a mesma especificação, as duas execuções passaram nas mesmas verificações ocultas, e a execução com ultracode consumiu mais do que o dobro do medidor da sessão. O motivo não é um modelo mais inteligente: é uma frase que o harness injeta e três proteções que ele desliga.
Este artigo cobre quatro pontos:
- o teste pareado, lido no medidor do plano;
- o multiplicador de tokens em vários outros pares;
- o único tipo de trabalho em que uma equipe encontrou 66 bugs plantados, enquanto um agente sozinho encontrou 14;
- as cinco configurações que limitam uma execução antes que ela devore a sua semana, uma delas capaz de pará-la no próprio limite de uso.
O que o ultracode liga: a palavra-chave, o toggle, um workflow de agentes
O ultracode tem dois interruptores. Digitar ultracode dentro de um prompt roda aquela tarefa como um workflow, sem mexer no nível de esforço da sessão. Ligar o toggle pelo comando /effort faz o Claude planejar um workflow para cada tarefa relevante, então um único pedido pode virar vários workflows em sequência.
Um workflow é um script que o Claude escreve para si mesmo; esse script coloca uma equipe de agentes para trabalhar em fases. Num sandbox minúsculo (alguns arquivos com tratamento de promises descuidado, revisão somente leitura pedida), o Claude examinou os arquivos, abriu um workflow que chamou de "unhandled promise audit", e uma linha de tarefa apareceu sob a caixa de prompt com uma barra de progresso, o número de agentes, o tempo decorrido e um total de tokens em contagem crescente. O comando /workflows lista uma linha por agente, com a contagem de tokens de cada um, além de teclas para pausar, parar ou reiniciar.
Nessa execução, cada finder já tinha lido cerca de 45.000 tokens antes mesmo de os verifiers começarem, para um punhado de linhas de código.
Toda sessão também carrega uma diretriz de tamanho, o número de agentes que o Claude é aconselhado a não ultrapassar:
| Diretriz de tamanho | Agentes recomendados |
|---|---|
| small (padrão no Pro) | menos de 5 |
| medium | menos de 10 |
Cada agente envia as próprias requisições além da sua conversa. Um workflow nunca é uma conta só; é uma conta por agente, e o medidor conta todas.
O teste pareado: as mesmas 136 verificações, 8 por cento contra 18, e nunca para
Um desenvolvedor mediu o custo no plano de assinatura mais alto, com uma configuração limpa: a mesma especificação para um pequeno app de planilha, o mesmo modelo no mesmo nível de esforço, uma execução simples e uma com ultracode. As duas foram avaliadas por verificações ocultas, testes que o modelo nunca vê. As duas passaram em todas as 136.
| Execução | Terminou | Limite da sessão usado | Verificações aprovadas |
|---|---|---|---|
| Simples | sozinha, em 25 min | 8 % | 136 / 136 |
| Ultracode | cortada pelo relógio aos 76 min, ainda conferindo | 18 % | 136 / 136 |
Dentro da execução com ultracode, o Claude escreveu um script cujo único trabalho era rodar uma equipe: 12 agentes contados, testers, alguns juízes e, mais tarde, "breakers" cuja função era quebrar a página. Um breaker encontrou de fato um bug real na barra de fórmulas, que continuava mostrando o texto antigo depois de clicar em outra célula.
Por minuto, a execução com ultracode consumiu o limite quase na mesma velocidade que a simples, em média um pouco mais devagar. Ela não queimou mais rápido; ela simplesmente não parou. O ultracode não deixa o Claude mais inteligente, ele faz o Claude conferir, e você paga por cada conferência. É um par só, numa especificação pequena, e a segunda execução foi cortada por um relógio, mas o formato é claro: mesma resposta, mais do que o dobro da janela da sessão, e todo o tempo extra foi de conferência.
Por que custa: uma frase e três proteções desligadas
O modelo é o mesmo. O que muda é o texto que o harness entrega a ele; o harness é o próprio Claude Code, suas ferramentas e as instruções em torno do modelo.
Com o ultracode ligado, o Claude Code carrega uma referência antes de escrever qualquer workflow. Esse texto diz ao modelo para rodar um workflow em toda tarefa relevante por padrão, e contém a frase que explica a conta: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." Esse é o texto do próprio harness, e uma issue pública no GitHub cita as mesmas linhas.
Três proteções são desligadas ao mesmo tempo:
- O aviso de workflow grande, que normalmente dispara quando uma execução agenda agentes demais, não aparece.
- O limite da sessão para quantos agentes podem rodar ao mesmo tempo não é aplicado aos agentes que o Claude cria.
- No modo auto, o primeiro lançamento nunca é submetido a aprovação.
A diretriz de tamanho é um conselho, não um teto: configurada como small (menos de 5 agentes) no sandbox, a execução com ultracode ainda criou 9. Para ser justo, a frase é um padrão que o modelo ainda pode ponderar, e as proteções são abandonadas de propósito em trabalhos muito grandes. A resposta cabe numa linha: o ultracode não muda o modelo, muda as instruções para "uma equipe para tudo, e custo não é uma restrição".
O multiplicador: três pares, a escada de esforço, o par de 30x
Um segundo desenvolvedor rodou vários pares de agente único contra workflow no plano Pro, com scripts no estilo revisão, lendo o medidor de uso antes e depois de cada um.
| Medida | Agente único | Workflow |
|---|---|---|
| Tokens em um script de revisão | cerca de 115.000 | 972.000 |
| Multiplicador de tokens entre os pares | 1x | até 18x, para praticamente os mesmos achados |
| Movimento do medidor | 1x | até 3x |
| Tempo de relógio | quase idêntico | quase idêntico |
O workflow não terminou mais rápido; gastou mais enquanto você esperava o mesmo tempo. O único lugar em que o paralelo compensou foi num lote de pesquisas independentes, em que os agentes terminaram mais rápido, ainda assim por mais do que o dobro dos tokens.
Um terceiro teste construiu alguns apps pequenos em cada nível de esforço, a preços de API. Cada degrau da escada praticamente dobrou a conta, e o ultracode chegou a vários múltiplos do que o max custou, sem nunca sair na frente. A maior parte desses tokens foi de leituras de cache, as baratas; a pequena fatia de tokens de saída representou quase metade do custo.
Mais um par, uma cena de cidade: um agente único levou cerca de uma hora por alguns dólares a preço de API. A execução com ultracode levou a maior parte de um dia, dezenas de subagentes e cerca de 30 vezes o custo.
São leituras do medidor em números inteiros, apps do zero a preços de API e uma cena de cidade, então nenhum deles é um placar por si só. Juntos, o padrão é o mesmo toda vez: o fan-out compra conferência e cobertura, não uma resposta melhor, a menos que o trabalho se divida em partes independentes.
Onde o fan-out compensa: uma suíte de testes como juiz, e a regra de uma linha
Alguns trabalhos realmente têm esse formato: uma migração, uma auditoria, uma varredura em uma base de código.
O Bun foi reescrito de Zig para Rust com cerca de 50 workflows dinâmicos no Claude Code, rodando continuamente por 11 dias. Foram mais de meio milhão de linhas de Zig, do início até a suíte de testes inteira passando em todas as plataformas nesses mesmos dias. O que fez funcionar não foi o número de agentes, mas o juiz: uma enorme suíte de testes existente dizendo passou ou falhou, sem a opinião de ninguém.
A caça a bugs da Anthropic mostra a mesma coisa. Setenta bugs foram plantados numa base de código grande, e um agente único rodou várias vezes.
| Agente | Bugs encontrados de 70 |
|---|---|
| Agente único (3 execuções) | 14, 15, 27 |
| Workflow (3 execuções) | 66 em toda execução |
Uma ressalva: esse teste rodou no Claude Managed Agents, o produto de API, não no Claude Code, e nenhum custo foi informado.
A thread de lançamento traz os outros ganhos relatados, e todos se parecem: revisão contra um arquivo de regras, tradução de uma base de código inteira, limpeza de uma pilha de páginas escaneadas. O blog de lançamento diz com clareza: a maioria das tarefas tradicionais de programação não precisa de um painel de cinco revisores.
A regra: faça fan-out apenas quando uma suíte de testes ou um conjunto de regras julga a saída e o trabalho se divide em partes independentes. Todo o resto roda simples, em high. O testador do teste pareado disse o mesmo com as próprias palavras: guarde para trabalhos em que a conferência é o trabalho, como uma migração em centenas de arquivos.
Cinco configurações que limitam uma execução
Cada limite fica num lugar que você já conhece.
| # | Configuração | Onde | Efeito |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config em Dynamic workflow size, ou settings.json |
conselho (menos de 5 agentes), e também reduz o limiar do aviso de workflow grande |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
variável de ambiente, exportada antes de iniciar | padrão de até 16 agentes ao mesmo tempo; com 4, o resto entra na fila, o que desacelera o consumo sem matar a execução |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
variável de ambiente | roda todos os agentes do workflow em um único modelo à sua escolha, enquanto os outros subagentes mantêm o deles; um modelo mais barato deixa a conferência mais barata |
| 4 | a palavra-chave ultracode, nunca o toggle |
no prompt; nunca a chave ultracode nas configurações |
a palavra-chave roda uma tarefa como workflow e para; o toggle o torna permanente até ser desligado |
| 5 | autoContinueAtUsageLimit |
settings | ligado: uma execução que atinge o limite pausa, espera o reset e segue, mais de uma vez; desligado: os agentes falham no muro e a execução termina ali |
Três hábitos acompanham essas configurações. O blog de lançamento diz que um orçamento escrito no prompt, como "use 10k tokens", define o teto. Depois de qualquer execução, /usage mostra quanto do uso recente foi para subagentes e workflows, com um aviso quando eles dominam. Se uma execução parecer errada enquanto roda, o painel /workflows e a tecla x a interrompem, e o trabalho já feito geralmente é mantido.
Nada disso deixa um agente mais barato. Isso limita quantos agentes uma execução pode gastar, e por quanto tempo ela pode continuar gastando.
A execução descontrolada, os limites e o veredito
Um relato público mostra como uma semana desaparece. Um script escrito pelo modelo, no maior plano, iniciou 221 agentes em menos de uma hora. Depois do primeiro erro de limite de sessão, o script continuou despachando, e mais 189 agentes foram iniciados nos minutos seguintes. A tabela do próprio autor da issue soma dezenas de milhões de tokens ao longo das fases antes do muro.
| Fase | Tokens, cache incluído |
|---|---|
| Ground | 11.063.801 |
| Find | 35.885.272 |
| Merge | 516.226 |
| Total | 47.465.299 |
O culpado foi uma linha do script gerado, um fallback que dizia: se o agente não devolveu nada, use a lista bruta e siga em frente. O merge falhou e a execução continuou. Essa versão é anterior à pausa no limite de uso, e o autor diz que aqueles tokens não vieram dos agentes que falharam. Um teto de concorrência teria diluído essa execução, e o auto-continue desligado a teria encerrado no muro.
O veredito: na mesma tarefa, com as mesmas verificações aprovadas, o ultracode consumiu mais do que o dobro do medidor de uma execução simples. Não por ser mais inteligente, mas pela frase injetada e pelas proteções que ele abandona. Ele compensa quando uma suíte de testes ou um conjunto de regras julga a saída e as partes não dependem umas das outras. Em todo o resto, você digita e paga pela conferência. Cinco configurações limitam o que uma execução pode gastar: a diretriz de tamanho, o teto de concorrência, o modelo do workflow, a palavra-chave em vez do toggle e a parada no limite.
AIDive