Um script na frente de todo modelo que não é Claude
Toda chamada a um modelo fora do Claude passa por um roteador e uma classe de tarefa. A classe escolhe o destino, e só uma delas pode alterar o repositório.
Em 18 de agosto, enviei uma tarefa longa de programação a um modelo externo. Ela rodava em
primeiro plano, ou seja, ligada diretamente ao meu terminal. O shell encerrou o processo após 2
minutos, com saída 143. Rodei de novo em segundo plano, sem prender o terminal, e terminou:
52.226 tokens. Um segundo envio do mesmo tipo chegou a 56.564. Foram uma execução em primeiro
plano que morreu, outra em segundo plano e um segundo envio. Todas eram da classe burst. Só o
ambiente de execução mudou.
O roteador já existia naquela época. O episódio mostrou que ele precisa conhecer o ambiente
onde cada classe roda. Quem escreve o prompt não deveria precisar saber disso. Toda chamada a
um modelo fora do Claude passa pelo script route-engine.sh.
Uma entrada
A chamada é route-engine.sh <caller> <task_class>, com o prompt na entrada padrão. caller é
o nome do agente que faz a chamada. A classe informa o tipo de trabalho, e o roteador escolhe o
destino.
Em cada chamada, o script grava um recibo num log JSONL, um arquivo de texto com um registro por linha. Ele registra o provedor pedido e o que realmente respondeu. Às vezes são diferentes. Por isso o recibo importa.
Já escrevi sobre escolher um modelo pelo tipo de trabalho e sobre tentar outro caminho quando um recurso acaba. Este texto trata do ponto em que essas escolhas se encontram: a classe.
As classes
Hoje há sete:
reason: raciocínio. É uma sentinela que não executa nada. O modelo principal continua raciocinando.bulk: rascunhos mecânicos.cheap: classificar, resumir e extrair.burst: programação longa e autônoma.review: uma segunda opinião independente e mais profunda.review-fast: PRs pequenos ou só de documentação. Nunca segurança, migrações, autenticação ou release.vision: imagens.
Só burst pode escrever no repositório. Ele trabalha isolado na pasta de trabalho de quem fez
a chamada e sem acesso à rede. As outras classes só recebem texto e devolvem texto. Nada é
alterado. Essa restrição é intencional.
Burst não tem alternativa de texto
A divisão fica mais clara quando burst falha. Se o roteador mudasse para um motor que só
responde com texto, a chamada devolveria uma resposta sem alterar arquivos. A automação veria
uma resposta, marcaria a tarefa como concluída e deixaria o repositório intacto. É o mesmo
falso sucesso que descrevi no texto sobre fallback.
Por isso, burst não tem uma alternativa de texto. Se não há um motor capaz de escrever, a
chamada falha e deixa isso claro. Prefiro um erro que pare o processo a uma resposta educada
que não fez nada.
O episódio dos 2 minutos também importa aqui. Uma tarefa burst demora por natureza, então o
tempo limite do shell faz parte do ambiente. Em primeiro plano, o processo morre. Em segundo
plano, termina.
A ALLOWLIST
O roteador tem uma lista de permissões chamada ALLOWLIST. A ADR-024, proposta em 9 de agosto,
descreve 133 linhas explícitas e dois curingas: codex * e ollama *. Essa lista limita para
onde cada classe pode ir. Não limita gastos.
Depois vieram duas decisões separadas da ADR-024. Em 12 de agosto, defini que o revisor de PR só pode usar uma lista curta de famílias de modelos: Claude, codex, antigravity, ollama cloud e opencode-go. A regra fica no roteador, não no prompt do revisor. Ele pode ignorar o texto do prompt, mas não o roteador. A outra decisão é a ADR-025, aceita em 14 de agosto. Ela trocou o programa de linha de comando do gateway multi-provedor por uma chamada HTTP direta.
Os motores são contados por medidor: assinatura (Claude Max, Codex, Ollama Cloud e algumas assinaturas de gateway), pool compartilhado e gratuito. A ordem é assinatura, pool e gratuito.
O que cada motor consegue fazer
Em 3 de setembro, descobri que o braço Claude de burst edita arquivos, mas não executa
comandos. O braço codex executa comandos, mas não escreve dentro de .git. Os dois fazem parte
de burst, mas têm capacidades diferentes.
O prompt não muda isso. A capacidade depende do motor. Pedir ao braço Claude para "rodar os testes" não adianta, pois ele não executa comandos. Quem precisa saber disso é o roteador, que escolhe o braço, não quem escreve o prompt.