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

Author: Vini - AI Coders Academy · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: Portuguese

Original video: Como usar JEV no Codex e Claude Code (e gastar menos tokens) · Channel: Vini - AI Coders Academy · 15:03 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, Software engineering with AI, AI developer tools, Model inference and optimization

Summary

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.

Key points

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.

Chapters

Start	Chapter	Summary
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.

Quotes

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

Concepts and entities

Jev Gateway, Jev, Codex, Claude Code, OpenRouter, Vercel AI Gateway, TypeSafe, Jev Gateway Bench, Vini, cache

Full transcript (original language)

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.