Como usar Jev no Codex e Claude Code (e gastar menos tokens)

Ver no idioma original →

Autoria: Vini - AI Coders Academy · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: português

Vídeo original: Como usar JEV no Codex e Claude Code (e gastar menos tokens) · Canal: Vini - AI Coders Academy · 15:03 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Ferramentas de desenvolvimento com IA, Inferência e otimização de modelos

Resumo

O vídeo apresenta o Jev Gateway, que encaminha chamadas de reasoning para o Jev para ajudar agentes de codificação a escolher ferramentas, enquanto as demais requisições seguem para o modelo principal. Vini explica como instalar e usar a integração com Codex e Claude Code, acompanhar as chamadas no dashboard e entender a arquitetura, incluindo a preocupação com cache. Os resultados de benchmarks mostram economias em algumas tarefas e modelos, mas também casos em que o Gateway aumenta o tempo ou o consumo, especialmente na criação de features com certos modelos da Anthropic. O projeto está em alfa, e o apresentador convida a comunidade a testar, contribuir com PRs e issues e ajudar a validar os resultados.

Pontos-chave

• O Jev Gateway pode ser instalado com npm install -g jev-gateway e usado com comandos específicos para cada harness compatível.
• O Gateway intercepta requisições e encaminha chamadas de reasoning para o Jev quando identifica que isso pode ajudar a selecionar uma tool.
• O dashboard mostra o direcionamento das requisições, o uso de tokens, a latência e a confiança associada às chamadas.
• A proposta é adicionar informação à nova requisição sem reescrever o histórico de conversa, para evitar afetar o cache.
• O projeto está em alfa, e o impacto da arquitetura sobre o cache ainda precisa ser validado em casos mais complexos.
• Nos testes de correção de bugs, vários modelos reduziram tokens ou tempo, mas os resultados variaram conforme o modelo.
• Para criação de features, Fable 5.1 teve bons resultados com o Jev, enquanto Opus 5 e Sonnet 5 apresentaram piora na configuração testada.
• O benchmark é pequeno: foram avaliadas duas tarefas, cada uma repetida cinco vezes por modelo, com e sem o Gateway.
• O apresentador incentiva contribuições ao projeto por meio de PRs, issues, testes e propostas de melhoria.

Capítulos

Início	Capítulo	Resumo
00:00	Instalação e uso do Jev Gateway	Vini apresenta o Gateway, explica a instalação, os harnesses compatíveis e as opções para obter acesso ao Jev.
02:04	Por que usar o Jev em workflows agênticos	O apresentador explica a hipótese de usar o Jev para reduzir o custo de reasoning na seleção de tools.
04:08	Arquitetura, cache e dashboard	Vini descreve como o Gateway intercepta requisições, encaminha chamadas e apresenta métricas, destacando que o impacto no cache ainda está em validação.
08:47	Benchmark e resultados em correção de bugs	O vídeo apresenta o benchmark e compara economia de tokens, requisições e tempo em tarefas de correção de bugs.
11:54	Resultados na criação de features	Os testes mostram resultados variados na criação de features, com bons números para Fable 5.1 e piora para Opus 5 e Sonnet 5.
14:02	Conclusões e convite à comunidade	Vini resume as limitações atuais e convida o público a contribuir com testes, PRs e issues.

Citações

A ideia não é reescrever o histórico, a ideia é que a gente adicione um contexto a mais para aquela requisição. — 05:42

A gente não tá alterando o histórico do modelo. — 08:14

Ainda é uma massa de benchmark pequena. — 09:17

Aqui eu tenho meu compromisso de manter a transparência e sinceridade com vocês sempre. — 14:02

Conceitos e entidades

• Jev Gateway (ferramenta): Gateway em alfa que intercepta requisições de agentes e pode encaminhar chamadas de reasoning para o Jev.
• Jev (modelo): Modelo usado pelo Gateway para ajudar a classificar qual tool deve ser chamada.
• Codex (ferramenta): Harness de codificação que pode ser iniciado por meio da integração com o Jev Gateway.
• Claude Code (ferramenta): Harness de codificação citado como compatível com a integração apresentada.
• OpenRouter (empresa): Provedor por meio do qual, segundo o vídeo, é possível acessar o Jev.
• Vercel AI Gateway (ferramenta): Uma das opções de provedor mencionadas para encaminhar chamadas ao Jev.
• TypeSafe (empresa): Provedor citado no vídeo, que exigia convite e aprovação em lista de espera no momento da gravação.
• Jev Gateway Bench (repo): Projeto de benchmark citado como recurso para conferir e executar testes de desempenho.
• Vini (pessoa): Apresentador do vídeo e responsável por explicar a integração e os resultados dos testes.
• cache (conceito): Mecanismo de redução de custos de input mencionado como possível ponto de atenção ao alterar requisições.

Tradução completa (pt-BR)

00:00 Como se usa o Jev dentro do Codex e do Claude Code? Essa foi uma pergunta que recebi muito lá no Twitter desde que comecei a falar do Jev. Também fui um dos primeiros canais brasileiros a fazer um vídeo sobre o assunto, se não o primeiro. E, naturalmente, as pessoas ficaram na dúvida: “Cara, beleza, é um modelo novo, mas como é que se usa esse negócio?”. Neste vídeo, vou mostrar um jeito de usar o Jev dentro do Codex, do Claude Code, do Entcraft e de outras ferramentas por meio do Jev Gateway. E vou mostrar por que isso faz sentido e quando talvez não

00:31 faça sentido. Vamos nessa. Para instalar, é muito simples: literalmente, são três passos. Você vai instalar com npm install -g jev-gateway. Depois de instalado, ele já vai disponibilizar os comandos dos harnesses que recebem suporte aqui. Você vai ver que adicionei o Codex e o Claude Code, mas outras pessoas já contribuíram aqui: adicionaram suporte ao Open Code e ao Gemini. Já tem um camarada aqui que abriu um monte de PRs que preciso revisar hoje. Ele também está aqui contribuindo com a gente. Isso é muito legal. Então, se

01:03 você viu que seu harness preferido não está aqui, já entre lá e abra sua PR. Quando você executar a instalação do seu harness, ele vai pedir para você informar a chave do Jev e abrir esta interface aqui. Vini, onde consigo essa chave? O Jev já está disponível no Open Router, no Vercel AI Gateway e também, claro, no Type Safe. Até o momento em que gravo este vídeo, o Type Safe exige convite e aprovação na lista de espera. Então, se quiser furar a fila, você pode ir pelo Open Router e já

01:34 consegue usar o Jev por lá também. Depois, você executa o comando específico: jev-codex para usar com o Codex, jev-claude para usar com o Claude Code e assim por diante. Se quiser acompanhar o trabalho e ver como as chamadas estão sendo feitas, abra com este comando: --dashboard. Aí ele vai abrir este painelzinho aqui. Basicamente, vai mostrar quando as requests estão sendo direcionadas para o Jev e quando não estão. Assim, você consegue ter uma noção de quanto do tráfego das

02:04 requisições está sendo direcionado de fato para o Jev e quanto está ficando com o próprio LLM. A maioria dos casos de uso em que você vai ver o Jev se saindo muito bem está relacionada a workflows de agentes de IA: seja para tool calling, fazer evals ou entender melhor o que está funcionando e o que não está. Nesta quinta-feira, às 19 horas, vou fazer uma live gratuita aqui no canal, nossa tradicional live de quinta, para você entender como usar esse modelo dentro de workflows agênticos. Você está

02:36 querendo se aprofundar mais nesse universo e sair do básico de Hermes Agent e Open Crawl? Venha para essa live, tenho certeza de que você vai gostar. Clique no link que está na descrição ou no primeiro comentário fixado para acessar o link da live e já deixe salvo no seu calendário. Minha tese inicial é a seguinte: um agente de IA gasta muitos tokens fazendo requests para entender qual tool chamar. Então, se eu tenho um MCP conectado, por exemplo, o agente vai ter que entender quais tools estão disponíveis e ler a descrição de cada uma delas, que já é pré-injetada no contexto do agente, para então entender qual tool chamar e em que ordem. Estou gastando tokens do GPT-6 Astra para fazer esse reasoning, estou gastando tokens do Fable 5.1, e não faz sentido gastar tanto dinheiro com esses modelos. Aí comecei a pensar: “Cara, e se eu usar o Jev como modelo para classificar qual é a tool certa a ser chamada em cada momento?”. Nosso primeiro teste foi feito no primeiro vídeo do canal sobre o Jev, que, inclusive, foi o primeiro vídeo sobre o Jev no Brasil. A gente já está por dentro e traz as novidades para vocês em

03:06 primeira mão, sem precisar esperar os gringos falarem do assunto para trazer as novidades para vocês. Naquele vídeo, mostrei nos nossos testes quantos tokens estavam sendo gastos somente para fazer o reasoning em workflows agênticos. Ainda não era um agente de codificação. Então, pensei: “Poxa, se a gente consegue economizar em workflows agênticos, por exemplo, em um agente assistente pessoal para agendar passagens, será que também consigo economizar tokens em tarefas de desenvolvimento de software?”. Daí vem o Jev Gateway. Aqui

03:38 precisamos fazer um esclarecimento para explicar como funciona o próprio Jev Gateway. Por quê? Existe um risco que estamos tentando entender — ainda estou testando e tentando obter alguns benchmarks para validar cada vez mais —, que é o risco de o cache ser afetado. O que isso significa? Temos o custo de input e output do LLM. Mesmo usando um LLM subsidiado por uma assinatura, esse custo é considerado dentro do subsídio. Para reduzir esse custo, existe a camada de cache. Assim, o custo do input e o custo do cache também são considerados, e isso reduz drasticamente o que você

04:08 gastaria se pagasse pelo consumo sem cache. E, quando alteramos o histórico de conversa do chat completion do LLM, perdemos todo o cache. Então, acabamos gerando mais custos em vez de resolver o problema. Esse é um dos primeiros alertas que quero fazer aqui para vocês, um dos primeiros pontos de atenção que estamos validando. Por isso, o projeto está em alfa. Até agora, a validação está indo bem e estamos conseguindo ter um bom desempenho. Mas ainda precisamos entender casos mais complexos. Inclusive, convido você a me ajudar a validar e

04:40 testar — e não só testar, mas também trazer soluções inteligentes para que a gente não tenha esse problema com o cache. O que levei em consideração nesta fase inicial, até agora? Vamos lá. Toda vez que houver uma requisição, ela vai passar primeiro pelo Gateway. Foi por isso que criamos a nomenclatura jev- seguida do nome do seu harness, em vez de fazer tudo diretamente pelo Codex, para que você possa comparar. Então, vou fazer uma tarefa com o Codex e outra com o Jev Codex. Qual está tendo melhor desempenho? Assim, você tem esse Gateway como um canal que intercepta a comunicação. E

05:11 durante essa interceptação, o que ele faz? Ele identifica se aquela chamada é uma chamada de reasoning para tool calling. Se for, aí sim, ele vai usar o Jev para fazer essa requisição. Se não for, ele a direciona diretamente para o servidor do provedor. Às vezes, ele vai entender que a confiança não está alta e também vai encaminhar a chamada diretamente para o servidor. A ideia não é reescrever o histórico; é adicionar mais contexto àquela requisição e reduzir o reasoning necessário para entender qual

05:42 tool deve ser chamada. Basicamente, é como se ele dissesse: “Olha, precisamos fazer uma tool call”. E, na própria request da API, a tool call vai ser esta. Assim, fica meio redundante para o modelo, que não precisa gastar raciocínio. Essa é a tese, essa é a ideia deste projeto. Você vai conseguir acompanhar quantos tokens estão sendo gastos, tanto de input quanto de output, principalmente os tokens do Jev, além de quantos output tokens e input tokens são usados pelo próprio LLM, a latência do Jev e a confiança média em cada requisição, em cada tool call que acontece. Então, aqui

06:12 ferramenta. Então, basicamente, é como se ele falasse assim: “Ó, a gente precisa chamar uma ferramenta”. E aí, na própria requisição da API, a chamada de ferramenta vai ser essa. Então, fica meio redundante para ele; ele não precisa gastar raciocínio. Essa é a tese, essa é a ideia que a gente tem aqui dentro desse projeto. E aí você vai conseguir acompanhar quantos tokens estão sendo gastos, tanto de entrada quanto de saída: tanto os tokens do Jev, principalmente, quanto os tokens de saída e de entrada do próprio LLM, além da latência do Jev e da confiança média que você está tendo para cada requisição, para cada chamada de ferramenta que acontece. Então, aqui

06:43 Você consegue acompanhar esse dashboard. Ele vai mostrar como o modelo está sendo usado, qual é o status, tudo certinho, aqui dentro de cada requisição. E, à medida que você vai usando… Deixa eu fazer um teste aqui, ó: vou mandar um oi, gastar um token rapidinho aqui. Você vai ver que ele vai ativar isso aqui rapidamente, assim que começar o reasoning lá dentro do modelo. Ó, começou o reasoning. Vem cá e ativa, e ele vai acompanhando isso em tempo real. Agora eu quero te mostrar a parte lógica por trás disso, qual é a arquitetura que a gente montou. Então, aqui tem alguns rabiscos para a

07:13 gente entender, tá? Aqui vai estar o seu agente: o Codex, o Claude, o Open Code, o Gemini, beleza? O agente vai fazer a requisição, que vai trazer tanto o histórico quanto as tools disponíveis para serem chamadas. Aí o Jev Gateway entra em ação. Ele vai ler a requisição, entender o formato da API e decidir como vai encaminhá-la. Se for encaminhada, ela vai para o Jev, que pergunta: “Qual tool faz sentido chamar?” Tá? Essa tool, essa chamada para o Jev, acontece tanto para o Type Safe quanto para o OpenRouter e também pode acontecer para o Vercel AI

07:44 Gateway. Então, você não precisa usar apenas um provedor de LLM ali, no caso, um provedor de IA para o Dev. Você também pode usar as outras opções. Uma vez que isso foi resolvido, a resposta — ou a requisição original, ou a requisição ajustada — é encaminhada para o modelo principal. Então, perceba: a gente não está alterando o histórico do modelo. A gente está trazendo a nova requisição, e somente a nova requisição vai carregar uma informação a mais. E essa informação a mais vai para o

08:14 modelo. Então, é como se o próprio prompt que estivesse indo para o modelo fosse com uma informação a mais. Beleza? E aí ele vai, faz… Vai para o modelo. O prompt fica no cache, ele está exatamente aqui nessa camada. Então, por isso que eu falei na nossa tese: o cache não deve ser um problema. E aí ele volta. Aqui, a resposta pode vir em texto ou em um formato de chamada de ferramenta. E aí, quando volta, volta para o nosso loop agêntico aqui, para o agente. Então, toda vez que tem uma request, ela passa para cá, verifica no Dev Gateway se é para ir para o Dev ou não. Se for para o Dev, ele faz a request, traz o

08:47 output, ajusta a mensagem original. Ajustou a mensagem original, vai para o modelo principal. Aqui está o cache, então não é afetado, e daí ele devolve. E assim ele segue nesse ciclo até concluir a tarefa. Beleza? Aí tem um ponto legal. No próprio repositório, a gente já adicionou o nosso projeto de benchmark. Se você quiser conferir e até mesmo rodar seu próprio benchmark para verificar os resultados, eles estão disponíveis aqui para você. Lá no final da página, você vai encontrar aqui, ó, beleza? O nosso

09:17 repositório Dev Gateway Bench. E, aqui dentro desse benchmark, o que a gente está validando é o seguinte: rodei duas tarefas, e cada uma delas foi executada cinco vezes em cada um desses modelos que vocês estão vendo aqui, e cinco vezes com esses modelos e o Dev Gateway funcionando também, redirecionando. Ainda é uma base pequena para benchmark, se a gente comparar com os grandes benchmarks, mas deu para ter pelo menos uma média OK, para dar esse passo inicial e começar a validar nossa tese. Então, o que a gente traz aqui? GPT-6 Astra,

09:47 para a tarefa de correção de bugs, encontrar um bug e corrigi-lo, a gente economizou 39% no tempo e 57% dos tokens de output. Então, foi uma baita economia de tokens de output. Nos input tokens, a gente economizou 7%. Isso é a média das tarefas. Então, entre cinco tarefas com o Dev e cinco tarefas sem o Dev, a média de economia ficou nessa porcentagem. GPT-5.6 Soul também teve a mesma economia de output tokens, 57%, mas, nos input tokens,

10:19 a gente também economizou 40%, coisa para caramba. E, quanto à quantidade de requisições, a gente reduziu em nove requisições: foram 36% menos. O tempo também foi 36% menor do que a média. Então, ainda assim, foi um resultado bem legal. Quando a gente vai para o GPT-5.6 Luna, aí já temos uma mudança. Você vai observar que os output tokens diminuíram 12%, os input tokens, 10%, mas levou 10% mais tempo para desenvolver. E aqui ainda teve uma

10:50 economia de requests também, né? Redução de 15% nas requests. Mas a gente percebeu que, usando modelos de fronteira mais avançados, o Dev, na parte de fazer esse reasoning, teve um desempenho melhor. Já no Claude, temos uma situação diferente aqui. Você vai ver que, no Fable 5… no Fable 5.1, ele economizou 13% nos output tokens. Nos input tokens, economizou 19%. Nas requisições de LLM, economizou 22%, mas aumentou em 6% o tempo de execução dessas tarefas.

11:22 Ainda assim, no Opus 5, a gente tem um resultado diferente também: 7% de economia nos output tokens, 22% de economia nos input tokens, 14% de economia no número de requests, mas 2% a mais no tempo. Pouca diferença aqui, né? No Sonnet 5, tivemos uma diferença gigante em comparação com os outros modelos da Anthropic: 41% menos tokens de output gastos, 48% menos tokens de input gastos, 26% menos requests feitas pelo LLM e 25% mais rapidez em

11:54 relação aos outros testes. Então, cara, foi bem interessante comparar esses modelos. De fato, existe algum nível de eficiência aqui, e a gente conseguiu comprovar isso com a execução de tarefas reais. E aí, o que muda é na hora de criar novas features. Então, até agora, a gente falou sobre resolver problemas, bugs, encontrar problemas no seu código. Agora, para criar novas features, foi diferente. Vou chamar a atenção primeiro para o Fable 5.1, que, na hora de criar a tarefa, foi o único

12:25 modelo da Anthropic que realmente economizou tokens, beleza? Economizou bastante: 24% menos tokens de output, 27% menos tokens de input, 19% menos requests e 26% menos tempo para fazer a mesma tarefa. Então, o Fable 5.1, usando o Jev para fazer o reasoning, foi um combo muito bom. Mas, se a gente olhar para o Astra, ele não economizou nada no output, gastou um pouquinho a mais no input e gastou 8% a mais de

12:57 tempo. Ou seja, foi irrelevante criar uma feature nova com o GPT-6 Astra usando o Jev, beleza? Com o GPT-5.6 Sol, a gente observa uma redução de 9% nos output tokens, 39% nos input tokens, 36% menos requests — na verdade, menos requests — e 16% menos tempo de execução. Esse modelo também teve um resultado legal. GPT-5.6 Luna: 14% menos output tokens, 51% menos input tokens, 42% menos requests e

13:29 14% menos tempo de execução. Agora, o Opus 5 teve um resultado um pouco esquisito, porque gastamos 22% mais output tokens, 61% mais input tokens — ou seja, gastamos bem mais aqui —, 47% mais requests e 83% mais tempo. Então, nesse caso, nem vale a pena considerar o Opus 5 com o Jev nessa configuração atual. Inclusive, se você manja do assunto e já tem uma ideia de como resolver isso, abre uma PR para a gente. Sonnet 5 também foi 9% mais lento, né?

14:02 Aliás, gastou mais output tokens: 16% mais input tokens, 3% mais requests e foi 37% mais lento. Então, hoje, dentro da Anthropic, para criar uma feature nova, o único modelo que realmente vale muito a pena é o Fable 5.1. Opus 5 e Sonnet 5 não valem a pena com o Jev Gateway na versão atual. Vamos tentar melhorar? Claro que vamos, mas aqui tenho o compromisso de manter a transparência e a sinceridade com vocês, sempre. Jev Gateway é um projeto criado por brasileiros para brasileiros e para o mundo inteiro. A gente talvez não

14:33 tenha tanta grana para bancar o treinamento de LLM, mas o que não falta no brasileiro é criatividade. Então, se você acredita que pode contribuir com esse projeto, tem uma ideia interessante de como a gente resolve os problemas já conhecidos, cola lá dentro, abre a sua PR, abre a sua issue, testa, ajuda a gente a validar isso. Quem sabe isso não vira um grande case feito no Brasil dentro do universo da inteligência artificial? No mais, eu sou o Vini, esse é o canal da AI Coders Academy. Se inscreve, cola com a gente na live de quinta-feira, todas as

15:03 quintas-feiras, às 19 horas da noite. Tô te esperando lá, hein? No mais, estamos juntos. Aquele abraço e valeu.

Transcrição original

[00:00] Como que usa o Jev dentro do Codex e dentro do Cloud Code? Essa foi uma pergunta que eu recebi para caramba lá dentro do Twitter desde quando eu comecei a falar do Jev. Foi um dos primeiros canais BR a fazer um vídeo sobre o assunto também, se não o primeiro. E naturalmente as pessoas ficaram na dúvida, cara, beleza, é um modelo novo, mas como é que usa esse trem? Nesse vídeo eu vou te mostrar um jeito de você usar o Jev dentro do Codex, dentro do Cloud Code, dentro do Entcraft e outras ferramentas através do Jev Gateway. E vou te mostrar por que que isso faz sentido e quando talvez não

[00:31] faça sentido. Bora nessa. Para instalar é muito simples, literalmente três passos. Você vai instalar com o npm install -g jev-gateway. Uma vez que está instalado, aí ele vai te disponibilizar já os comandos conforme os harnesses que a gente já tiver dando suporte aqui. Você vai ver que eu adicionei o Codex e Cloud, mas já tiveram outras pessoas que contribuíram aqui, adicionou suporte ao Open Code, adicionou suporte ao Gemini. Já tem um camarada aqui que já abriu uma porrada de PR que eu tenho que revisar hoje. Está aqui com a gente contribuindo também. Isso é muito massa. Então se

[01:03] você viu que o seu harness preferido não está aqui, já entra lá e já abre a sua PR. Vai rodar a instalação do seu harness, ele vai te pedir, vai abrir esse essa interface aqui para você colocar a chave do Jev. Vini, onde que eu consigo essa parada? Já está disponível no Open Router, está disponível no Vercel AI Gateway e também, claro, no Type Safe. O Type Safe, até o momento que eu gravo esse vídeo, ele exige convite, ele exige que você seja aprovado na lista de espera. Então se você quiser furar a fila, você vai lá pelo Open Router, você já

[01:34] consegue usar o Jev lá pelo Open Router também. E aí depois você roda o comando específico. Jev Codex para rodar com Codex, Jev Cloud para rodar com Cloud e assim sucessivamente. Se você quiser acompanhar o trabalho e como estão sendo feitas as chamadas, você vai abrir com esse comando {traço} {traço} dashboard, que aí ele vai abrir esse camaradinha aqui, ó. Basicamente, ele vai mostrar quando que as requests estão sendo direcionadas para o Jev e quando não estão sendo. Então você consegue ter uma noção de qual quanto do tráfego das

[02:04] requisições estão sendo feitas, estão indo de fato lá pro Jev e quanto de fato elas estão ficando com o próprio LLM. A maioria dos casos de uso que você vai ver o Jev realmente mandando bem pra caramba tá relacionado a workflows de agentes de IA. Seja pra tool calling, seja pra fazer eval, seja pra entender melhor o que que tá funcionando, o que não tá funcionando. E na quinta-feira agora, às 19 horas da noite, eu vou fazer uma live gratuita aqui no canal, nossa live de quinta tradicionalíssima, pra você entender como que usa esse cara dentro de workflows agênticos. Você tá

[02:36] querendo se aprofundar mais nesse universo, sair do básico de Hermes Agent e Open Crawl, vem pra essa live que eu tenho certeza que você vai gostar. Já clica no link que tá aqui na descrição e no primeiro comentário fixado que você já pega o link da live certinho, já deixa salvo aí no seu calendário. A minha tese inicial é a seguinte: um agente de IA, ele gasta muito token fazendo requests faz pra entender qual tool chamar. Então se eu tenho um um MCP conectado, por exemplo, o agente ele vai ter que entender quais são as tools disponíveis, ler a descrição de cada uma dessas tools que já é pré-injetado ali

[03:06] no contexto do agente, pra aí então ele entender qual tool chamar e qual ordem chamar. Isso eu tô gastando token de GPT-6 Astra pra fazer esse reasoning, eu tô gastando token de eh Fable 5.1 e não faz sentido eu gastar tanta grana com esses caras. E aí eu comecei a pensar: “Cara, e se eu usar o Jev como modelo pra classificar qual tool certa ser chamada em cada momento”. Então nosso primeiro teste foi executado lá no primeiro vídeo do canal aqui sobre o Jev, que inclusive foi o primeiro vídeo no Brasil sobre o Jev, a gente já tá antenado, já traz aqui pra vocês em

[03:38] primeira mão, sem precisar esperar os gringos falarem do assunto pra gente trazer pra vocês. E aí naquele vídeo eu mostrei nos nossos testes o quanto de tokens estavam sendo gastos somente pra fazer o reasoning em workflows agênticos, não era agente de codificação ainda. Então eu falei: “Poxa, se a gente consegue economizar em workflows agênticos, por exemplo, no agente assistente pessoal, de agendamento de passagem, por exemplo, será que eu consigo economizar tokens também em tarefas de desenvolvimento de software?” Daí vem o Jeff Gateway. Aqui a gente

[04:08] precisa fazer um disclaimer para explicar para você o funcionamento do próprio Jeff Gateway. Por quê? Existe um risco que a gente tá entendendo como que ele tá ainda, tô testando, tô tentando pegar alguns benchs para validar cada vez mais, mas que é o risco do cache ser afetado. Que que é isso? A gente tem o custo de input e output do LLM. Mesmo sendo usado um LLM subsidiado numa assinatura, você tem esse esse custo que tá sendo considerado ali dentro do seu subsídio. Para esse custo ficar menor, você tem a camada de cache. Então o custo do input do do custo do cache também que tá sendo utilizado, ele vai reduzir drasticamente o que você

[04:40] gastaria se tivesse pagando pelo consumo sem cache. E quando a gente altera o histórico de conversa do chat do completion do LLM, você perde o cache todo. Então você acaba gerando mais custo do que resolvendo o problema. E essa é uma das primeiras bandeiras que eu quero levantar aqui com vocês, nos primeiros pontos de atenção, que é justamente que a gente tá validando. Por isso o projeto tá em alfa. Até então, a validação tá legal, a gente tá conseguindo de fato performar bem. Mas a gente ainda precisa entender casos mais complexos. Inclusive você é meu convidado a me ajudar a validar e

[05:11] testar, e não só testar, é trazer soluções inteligentes para a gente não ter esse problema do cache. O que que eu levei em consideração para para essa fase inicial até agora? Vamos lá. A gente vai levar toda vez que tiver uma requisição, ela passa antes pelo Gateway, por isso que a gente criou a nomenclatura Jeff traço e aí o nome do seu harness, ao invés de fazer direto pelo Codex, para você poder comparar. Então eu vou fazer uma tarefa com Codex, vou fazer uma tarefa com o Jeff Codex. Qual que tá performando melhor? Então você tem esse Gateway como um canal que tá interceptando a comunicação. E

[05:42] durante essa interceptação, que que ele faz? Ele vai identificar se aquela chamada, se ela é uma chamada de reasoning to call. Se for uma chamada de reasoning to call, aí sim, ele vai usar o Jev, o Jev, para fazer essa requisição. Se não, ele é direciona direto lá para o próprio servidor do provedor. Algumas vezes ele vai entender que a confiança não está alta, então ele também vai devolver direto para o servidor. A ideia não é reescrever o histórico, a ideia é que a gente adicione um contexto a mais para aquela requisição e reduza o reasoning que seria necessário para entender qual

[06:12] tool. Então, basicamente, é como se ele falasse assim: “Ó, a gente precisa chamar tool call”. E aí na própria request da Bahia, a tool call vai ser essa. Então ele fica meio redundante para ele, ele não precisa gastar raciocínio. Essa é a tese, essa é a ideia que a gente tem aqui dentro desse projeto. E aí você vai conseguir acompanhar quantos tokens estão sendo gastos, tanto de input quanto output, tanto o os tokens do Jev, principalmente, e quantos output tokens e input tokens do próprio LLM e também a latência do Jev e a confiança média que você tá tendo para cada requisição, para cada tool call que acontece. Então aqui

[06:43] você consegue acompanhar esse dashboard vai te mostrar como o modelo tá sendo usado, qual o status, tudo certinho aqui dentro de cada requisição e a medida que você vai usando, deixa eu fazer um teste aqui, ó, vou mandar um oi, gastar um token aqui rapidão aqui, você vai ver que ele vai ativar isso aqui rapidamente assim que começar o reasoning lá dentro do modelo, ó, começou o reasoning, vem cá e ativa e ele vai assistindo isso em tempo real. Agora eu quero te mostrar a parte lógica por trás disso, qual que é a arquitetura que a gente montou. Então aqui tem alguns rabiscos para a

[07:13] gente entender, tá? Aqui vai tá o seu agente, o Codex, o Claude, o Open Code, o Gemini, beleza? Ele vai, o agente vai fazer a requisição que vai trazer tanto o histórico, tanto as tools disponíveis para serem chamadas e aí o Jev Gateway entra em ação. Ele vai ler a requisição, vai entender o formato da API e vai decidir como que vai encaminhar. Se ele encaminha, ele vai para para o Jev e fala assim, ó: “Qual tool faz sentido chamar?” Tá? Essa, essa tool, essa chamada para o Jev, ela acontece tanto para o Type Safe, quanto pode ser para o OpenRouter, quanto para o Vercel AI

[07:44] Gateway também. Então você não tá somente necessitando de usar somente um provedor de LLM ali, no caso um provedor de IA para o Dev. Você consegue usar nas outras opções também. Uma vez que isso foi resolvido, aí vem a resposta, ou a original, a requisição original, ou a requisição ajustada, é encaminhada para o modelo principal. Então perceba, a gente não tá alterando o histórico do modelo. A gente tá trazendo a nova requisição e somente a nova requisição, ela sim vai carregar uma informação a mais e essa informação a mais vai para o

[08:14] modelo. Então é tipo como se o próprio prompt que tivesse indo para o modelo tivesse indo com uma informação a mais. Beleza? E aí ele vai, faz, vai para o modelo prompt do cache, ele tá morando exatamente aqui nessa camada. Então por isso que eu falei na nossa tese, não é para ser um problema o cache. E aí ele volta. Aqui a gente tem volta em texto ou uma uma um formato de chamada de ferramenta. E aí quando ele volta, ele volta no nosso loop agêntico aqui, para o agente. Então toda vez que tem uma request, ele passa para cá, verifica o Dev no Dev Gateway se é para ir para o Dev ou não. Se se é para ir para o Dev, ele faz a request, traz o

[08:47] output, ajusta a mensagem original, ajustou a a mensagem original, vai para o modelo principal. Aqui tá o cache, então não é afetado e daí ele devolve. E assim ele vai nesse ciclo até concluir a tarefa. Beleza? Aí tem um ponto legal. No próprio repositório, a gente já adicionou aqui o nosso projeto de benchmark. Se você quiser conferir ele e até mesmo rodar o seu próprio benchmark para verificar os resultados, eles estão disponíveis aqui para você. Lá no final da página, você vai encontrar aqui, ó, beleza? O nosso

[09:17] repositório Dev Gateway Bench. E aqui dentro desse benchmark, o que a gente tá validando é o seguinte, eu rodei duas tarefas, cada uma delas rodou cinco vezes em cada um desses modelos que vocês tão vendo aqui e cinco vezes com esses modelos e o Dev Gateway funcionando também, redirecionando. Ainda é uma massa de benchmark pequena, se a gente for olhar aí com os grandes benchmarks, mas deu para a gente ter pelo menos uma média OK para já ter aquele passo inicial e de começar a validar nossa tese. Então, o que que a gente traz aqui? GPT-6 Astra,

[09:47] para a tarefa de correção de bugs, encontrar um bug e corrigir bug, a gente economizou 39% no tempo e aqui a gente economizou 57% de tokens no output. Então, foi uma baita economia de tokens no output. No input tokens, a gente a gente economizou 7%. Isso na média das tarefas. Então, de cinco tarefas com o Dev e cinco tarefas sem o Dev, a média de economia ficou aqui dentro dessa porcentagem. GPT-5.6 Soul também, mesma economia de output tokens, 57%, mas no input tokens,

[10:19] a gente economizou 40% também aqui, coisa para caramba. E a quantidade de requisições, a gente reduziu em nove requisições, foi 36% menos e o tempo também foi 36% menor do que a média. Então, ainda assim foi bem legal o resultado. Quando a gente vai para o GPT-5.6 Luna, aí aqui a gente já tem uma mudança. Você vai observar que o output tokens diminuiu 12%, input tokens 10%, mas demorou 10% a mais do tempo para desenvolver e aqui ainda teve uma

[10:50] economia de request também, né? 15% redução de requests. Mas a gente percebeu que, usando modelos mais avançados de fronteira, o Dev, como a parte de fazer esse reasoning, ele performou melhor. Já no Claude, a gente tem uma parada diferente aqui. Você vai ver que no Fable 5, ele Fable 5.1, ele economizou 15%, aliás, 13% aqui no no output tokens. No input tokens, ele economizou 19%. No nas requisições de LLM, ele economizou 22%, mas aumentou em 6% o tempo de execução dessas tarefas.

[11:22] Ainda assim, no Opus 5, a gente tem um resultado diferente também, 7% economia no no output, 22% economia no input, 14% economia de tempo na na na de economia de requests, mais 2% a mais no tempo. Pouca diferença aqui, né? No Sonnet 5, tivemos uma diferença gigante em comparação aos outros modelos da Anthropic, em 41% menos tokens gastos de output, 48% menos tokens gastos de input, 26% menos requests feitas ali, eh, pelo LLM e 25% mais rápido também em

[11:54] relação aos outros, aos outros, aos outros testes. Então, cara, isso daqui ficou bem interessante da gente comparar esses modelos. De fato, tem algum nível de eficiência aqui e a gente conseguiu comprovar com uma execução de tarefas reais. E aí, o que muda vai ser na hora de criar novas features. Então, a gente falou aqui até agora para resolver problemas, bugs, encontrar problemas no seu código. Agora, para criar novas features, daí foi diferente. Vou chamar a atenção primeiro do Fable 5.1, que na hora de criar a tarefa, ele foi o único

[12:25] modelo da Anthropic que realmente economizou tokens, beleza? Economizou bastante. 24% menos tokens de output, 27% menos tokens de input, 19% menos requests e 26% menos em tempo para fazer a mesma tarefa. Então, Fable 5.1, para criar novas features usando o Jev como o cara que tá fazendo o reasoning, foi um combo muito bom. Mas se a gente olha para o Astra, o Astra não economizou nada no output, gastou um pouquinho a mais aqui no input e gastou 8% a mais de

[12:57] tempo. Ou seja, foi irrelevante criar uma feature nova com o GPT 6 Astra usando o Jev, beleza? GPT 5.6 Sol, a gente vai observar uma redução de 9% no output tokens, 39% nos input, 36% menos tempo nas requests, aliás, menos requests, na verdade, e 16% menos tempo na execução. Esse cara aqui ficou legal também. GPT 5.6 Luna, menos 14% no output tokens, menos 51% no input tokens, menos 42% nas requests e menos

[13:29] 14% no tempo de execução. Agora, Opus 5 foi uma parada um pouco esquisita, porque no Opus 5 a gente gastou 22% mais output tokens, 61% mais input tokens, ou seja, gastou bem mais aqui, 47% mais requests e 83% mais tempo. Então, nesse caso, nem vale a pena olhar para o Opus 5 com o Jev nessa configuração atual. Inclusive, se você tiver as manha e já tiver com uma ideia de como é que a gente resolve isso, dropa lá uma PR para a gente. Sonet 5, 9% também mais lento, né?

[14:02] Aliás, mais output tokens gastos, 16% mais input tokens, 3% mais requests e 37% mais lento. Então, dentro da Anthropic hoje, para você criar uma nova feature, o único cara que tá valendo muito a pena é o Fable 5.1. Opus 5 e Sonet 5 dentro do Jev Gateway na versão atual não tá valendo a pena. Vamos tentar melhorar? Claro que vamos, mas aqui eu tenho meu compromisso de manter a transparência e sinceridade com vocês sempre. Jev Gateway é um projeto criado por brasileiros para brasileiros e para o mundo inteiro. A gente talvez não

[14:33] tenha tanta grana para bancar o treinamento de LLM, mas o que não falta no brasileiro é criatividade. Então, se você acredita que pode contribuir com esse projeto, tem uma ideia interessante de como é que a gente resolve os problemas já conhecidos, cola lá dentro, abre a sua PR, abre a sua issue, testa, ajuda a gente a validar isso, quem sabe isso não vira um grande case feito no Brasil dentro do universo da inteligência artificial. No mais, eu sou o Vini, esse é o canal da AI Coders Academy, se inscreve, cola com a gente na live de quinta-feira, todas as

[15:03] quintas-feiras às 19 horas da noite. Tô te esperando lá, hein? No mais, estamos juntos. Aquele abraço e valeu.