AIDiveIntro: uma dica, não economia
Jev não vai deixar o Claude Code mais barato, e o próprio benchmark do gateway confirma isso. Este artigo lê o código do jev-gateway e seu repositório de benchmark, depois coloca um proxy de registro na frente de uma sessão real do Claude Code para ver o que um roteador receberia.
Jev é o modelo de decisão da TypeSafe: uma probabilidade devolvida em milissegundos, conectada ao Claude Code por seis vídeos em uma semana. O discurso é "o loop de codificação agentic mais barato". Os próprios números do gateway mostram o Opus 5 fazendo 47% mais requisições e levando 83% mais tempo numa tarefa de feature com o routing ativado.
Como um roteador que responde em milissegundos deixa o Claude Code mais lento? Tudo se resume a uma linha de código. Dentro do Claude Code, o Jev recebe exatamente duas frases, e uma sessão normal entrega a ele 40 tools a cada chamada.
O que é o Jev, e o que a onda vende
Jev é um modelo de decisão da TypeSafe. Ele não gera texto: você faz uma pergunta tipada e ele responde com uma escolha, uma nota ou uma probabilidade sim/não. Os números do fornecedor:
| Figura | Valor |
|---|---|
| Preço de entrada | $0.04 por milhão de tokens |
| Preço de saída | grátis ("barato demais para cobrar") |
| Latência | 70 a 500 ms |
| Manchete da home page | 194× mais rápido, 445× mais barato |
O post do blog abaixo dessa manchete diz que os dois multiplicadores são o topo dos ganhos reais, medidos contra a média de dois modelos de fronteira, uma comparação que os próprios autores admitem ser tendenciosa a favor desses modelos.
Seis vídeos em cinco dias conectaram o Jev ao Claude Code. O maior está em 139.000 visualizações e o chama de o loop de codificação agentic mais barato até agora. Dois repositórios carregam a onda: jev-gateway, um proxy local para Claude Code e Codex criado cinco dias antes com 181 estrelas, e fast-jev-compaction, um plugin de compactação criado no dia anterior a esse, com 6.400 estrelas. O gateway é onde o Claude Code se conecta, então é por aí que a leitura começa.
Uma env var, uma linha: modo hint
jev-gateway fica entre o Claude Code e a API da Anthropic. Ele inicia o Claude Code com uma única variável de ambiente, ANTHROPIC_BASE_URL, apontando para uma porta local. Nada mais muda; um comentário no código-fonte diz que não há credencial de gateway, então um login Pro ou Max continua funcionando normalmente.
Dentro do adapter (src/adapters/messages.ts, linha 99), uma linha decide o que o Jev tem permissão para fazer:
steer: thinking || cached ? "hint" : "tool_choice"
Com o thinking estendido ativado, ou uma conversa em cache, o gateway só pode sugerir. Caso contrário, ele força o tool. O comentário acima da linha explica por quê: a API rejeita um tool forçado enquanto o thinking estendido está ativo, e mudar o tool_choice invalida a conversa em cache que o Claude Code relê a cada turno.
Para verificar como uma requisição real se parece, um proxy de registro de 60 linhas tomou o lugar do gateway na mesma porta, com o Claude Code iniciado através dele e uma requisição enviada num repositório real. A requisição carrega thinking: adaptive e três marcadores de cache; tool_choice está ausente; 24 tools acompanham numa instalação limpa. Rode a linha do gateway contra essa requisição e o caminho forçado nunca dispara. Toda chamada do Claude Code cai no modo hint. O README diz exatamente isso: espere melhores escolhas de tool em listas grandes de tools, não custo ou latência menores.
A dica: duas frases, e onde ela não cabe
O que o Jev pode fazer dentro do Claude Code é duas frases adicionadas à última mensagem: "um modelo de roteamento sugere que este tool é o movimento mais relevante agora. Ignore isso se não fizer sentido." Essa é toda a intervenção. O modelo é livre para ignorar, e o tool_choice permanece em auto.
Forçar um tool não é uma opção, segundo a documentação da Anthropic: um tool forçado retorna um erro 400 no Opus 5.5 e no Fable 5.1, e dá erro com thinking manual nos demais modelos. Mudar o tool_choice também está fora: a documentação de prompt caching diz que isso invalida o cache de mensagens, a maior parte de uma sessão longa. Editar a descrição de um tool invalida o cache inteiro: tools, sistema e mensagens.
| Mudança na requisição | Efeito no cache de prompt |
|---|---|
| Adicionar uma dica à última mensagem do usuário | prefixo em cache inalterado |
Mudar o tool_choice |
cache de mensagens invalidado |
| Editar a definição de um tool | tools, sistema e mensagens invalidados |
O comentário do gateway explica por que a dica vai no final: o prefixo em cache permanece byte a byte idêntico ao que o Claude Code reenvia no turno seguinte. Há uma guarda na frente disso: quando a última mensagem não é do usuário, a requisição passa intocada. As duas requisições capturadas terminaram num bloco de sistema que o próprio Claude Code adiciona, um lembrete de ambiente numa e a saída de um hook na outra. Nesse formato, a dica não tem onde pousar. Ela pousa em outros turnos, já que os resultados de tools voltam como mensagens do usuário, e o benchmark conta o Jev direcionando de um terço a metade das requisições do Claude Code.
O benchmark que ninguém cita
O próprio benchmark do gateway, jev-gateway-bench, responde à pergunta inicial. Rodou 120 sessões, cinco execuções por célula, no mesmo Claude Code e na mesma assinatura que todo mundo usa, sem servidores MCP, plugins ou skills. Duas tarefas num pequeno motor de xadrez: uma caça a bugs com cinco bugs injetados, e uma feature, adicionando notação algébrica.
| Modelo, tarefa | Routing ligado vs. desligado |
|---|---|
| Opus 5, feature | +61% tokens de entrada, +47% requisições, +83% tempo (ainda resolveu 5/5) |
| Sonnet 5, feature | +16% tokens de entrada, +37% tempo |
| Sonnet 5, caça a bugs | −48% tokens de entrada, −25% tempo |
Depuração é onde o routing compensa, nas palavras dos próprios autores. A explicação deles é a resposta para a pergunta: o gateway só sugere com modelos Claude, então uma dica que não serve custa um desvio em vez de ser ignorada de graça.
Codex recebe a versão forçada. O Jev decidiu de 76% a 100% das requisições do Codex, contra um terço a metade das do Claude Code. Um modelo no outro harness ficou mais barato e errado, três soluções em cinco em vez de cinco. Mais barato e errado não é economia.
Os limites são reais: cinco execuções por célula é uma amostra pequena, é um motor de brinquedo, e ninguém repetiu o teste. A entrada também está majoritariamente em cache, então uma economia de entrada vale menos do que uma economia de saída.
O que minha sessão entrega: 24 tools limpo, 40 completo
O que uma sessão normal do Claude Code entrega a um roteador a cada chamada? O log do proxy responde: 40 tools. Mesmo repositório, mesmo prompt de uma palavra só, duas configurações: uma instalação limpa com config vazia e nenhum servidor MCP, e uma configuração normal com seus servidores e plugins.
| Instalação limpa | Configuração normal | |
|---|---|---|
| Tools na requisição | 24 | 40 (16 de servidores MCP e plugins) |
| Tokens de prefixo cobrados | 47.411 | 57.277 |
| Tokens de saída | 4 | 4 |
| Custo equivalente de API de um "ok" | $0.07 | $1.15 |
A lista é a conta. As definições mais pesadas são embutidas: o tool de shell sozinho tem 12.000 caracteres, o tool de agent quase 9.000.
A nota de rodapé do benchmark viu seis tools e 7.000 tokens numa instalação limpa, e 285 tools numa configuração carregada. O Claude Code limpo de hoje já vem com muito mais tools embutidos, e o caso carregado é mais raro: a maioria dos tools MCP fica atrás de um tool de busca, deferred, então a lista que um roteador vê continua pequena. Seja qual for o tamanho dela, o gateway manda essa lista para o Jev a cada requisição; uma issue aberta no repositório diz que o custo total é pago antes de a maioria das respostas ser descartada. Nada disso é culpa do Jev, e nada disso é o Jev que precisa consertar.
Veredito por uso
Routing dentro do Claude Code: não. É uma dica que o modelo pode ignorar, deixou o trabalho de feature mais lento nos dois modelos Claude, e a única vitória é em depuração. A exceção é um dia de caça a bugs numa lista muito grande de tools, o próprio caso que o README nomeia.
O plugin de compactação, fast-jev-compaction: ainda não. Ele precisa de uma flag de hook em acesso antecipado, suas issues abertas dizem que os hooks não registram em algumas builds, e depois de uma compactação o modelo escreveu nove relatórios dizendo que o trabalho estava concluído, todos fabricados. Os praticantes chegaram lá primeiro: a thread principal sobre o plugin tem 491 pontos, e sua objeção principal não é velocidade, mas os termos de serviço sobre enviar transcrições para terceiros.
Codex: esse é o alvo de verdade. Ali o gateway força o tool, o Jev direcionou até toda requisição, e a caça a bugs rodou com 57% menos tokens de saída.
| Uso | Veredito |
|---|---|
| Routing no Claude Code | Não, exceto caça a bugs numa lista muito grande de tools |
| fast-jev-compaction | Ainda não |
| Codex | Sim |
Uma coisa que a onda acertou: o login da assinatura nunca muda, o gateway só troca uma URL. Os limites desta leitura: cinco execuções por célula, um motor de xadrez, um repositório de benchmark que ninguém repetiu, e nenhuma sessão com routing minha própria. Eu medi a lista e a requisição, não o Jev. O próprio Jev é barato. O desvio não é.
