Jev pesa no consumo da sessão do Claude Code? Como medir o custo de contexto na prática

Fala aí, beleza? Toda camada nova que tu pluga no Claude Code cobra um pedágio de contexto ANTES de entregar qualquer benefício

E com o Jev essa pergunta fica ainda mais legítima, porque ele não substitui nada: ele senta por cima do loop como camada extra

Situando quem chegou agora: o Jev é o primeiro modelo da classe que a TypeSafe AI chama de System One Models, entrou em early access por lista de espera em 15/09/2026 e, até o fechamento deste post, não teve anúncio de disponibilidade geral

Outro detalhe que muda tudo: o Jev não expõe endpoint no formato OpenAI nem Anthropic

Ou seja, esquece usar ele como o modelo por trás do Claude Code

Ele entra como camada auxiliar, via skill, plugin, MCP ou roteamento por turno

E camada auxiliar sempre tem preço

Este post não chuta número de economia pra tua sessão

Os únicos números de conta que tu vai ver por aqui são exemplos de README de terceiros, com fonte, e servem pra mostrar o RISCO, não pra prometer desconto

Ele te ensina o método pra tu rodar a MESMA tarefa com e sem a camada e olhar a diferença na tua máquina, no teu projeto, com o teu CLAUDE.md gigante

Bora?

Os três custos que uma camada Jev adiciona ao fluxo

Antes de medir, é bom saber ONDE procurar

O custo não aparece num lugar só, ele se espalha em três frentes bem diferentes:

Curso Recomendado

Curso de Jev: Sistemas Mais Inteligentes, Rápidos e Robustos

Desenvolva sistemas mais inteligentes, rápidos e robustos com Jev

Conhecer curso

Repara numa coisa curiosa da linha do meio: o Jev não decodifica texto autoregressivamente

Cada requisição manda um estado mais uma lista de perguntas tipadas, e ele devolve a resposta DENTRO do schema (escolha, score ou probabilidade)

Não tem prosa gerada, por isso não tem token de saída pra cobrar

Isso explica por que o custo por chamada é pequeno e por que o ponto de atenção real está nas outras duas linhas da tabela

E tem o contraponto simpático: existe um segundo mod da mesma coleção, o jev-skill-suggestion, que nasceu justamente pra atacar a primeira linha

Ele tira a listagem de skills do contexto e deixa o Jev sugerir no máximo uma skill por prompt, injetando só o SKILL.md escolhido

A instalação dele é npx claude-code-templates@latest --mod productivity/jev-skill-suggestion, e o comando /jev-skill-suggestion:setup marca as skills como user-invocable-only

Ou seja: uma camada pode adicionar contexto e outra pode remover

Medir é o que separa as duas =)

Como comparar a mesma tarefa com e sem o Jev

O protocolo abaixo é chato de propósito

Comparação só vale se as duas rodadas forem parecidas o suficiente pra diferença significar alguma coisa

1. Tire a linha de base do contexto vazio

Abre uma sessão nova, não digita nada ainda e roda:

/context
/context all

O /context mostra o uso do contexto por categoria e o /context all mostra o uso de tokens dos componentes carregados

E aqui vem a parte que assusta muita gente na primeira vez: antes de tu digitar qualquer coisa já entraram no contexto o CLAUDE.md, a memória automática, os nomes das ferramentas MCP e as descrições das skills

O erro comum deste passo é medir a linha de base depois de já ter conversado com o agente, aí tu não sabe mais o que é carga inicial e o que é conversa

2. Escolha uma tarefa fixa e escreva o prompt UMA vez só

Salva o prompt num arquivo e cola exatamente igual nas duas condições

De preferência uma tarefa de tamanho médio e determinística o bastante: refatorar um arquivo específico, criar um endpoint que tu já sabe como termina, coisa assim

O erro comum aqui é o clássico: rodar sem a camada com um prompt, achar que melhorou a redação, rodar com a camada com outro prompt e comparar os dois

Isso não é medição, é sensação

3. Rode SEM o mod e feche a conta

Terminou a tarefa, roda:

/usage

O /usage reporta uso de tokens e custo da sessão, no bloco Session

Tome cuidado com um detalhe: por padrão o Claude Code calcula os valores em preço de tabela (o managed setting modelPricing ajusta isso)

Se tu é assinante Pro ou Max, aquele número NÃO é o que foi cobrado de ti, é referência

Pra quem gosta de acompanhar isso de forma mais visual dentro do terminal, eu já mostrei outro jeito de ver o gasto de tokens da sessão por aqui

4. Instale a camada e suba a sessão com os hooks ligados

O mod jev-model-router vive na pasta cli-tool/components/mods/productivity/jev-model-router do repositório claude-code-templates

Instalação:

npx claude-code-templates@latest --mod productivity/jev-model-router

E mods do Claude Code só carregam com os function hooks ligados pela variável de ambiente:

CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude

O erro comum deste passo é instalar, abrir o claude do jeito de sempre e jurar que testou

Sem a variável, o mod simplesmente não entra em ação e tu vai comparar duas sessões idênticas sem perceber

Ah, e sobre o custo próprio dele: o README declara uma requisição ao Jev por prompt, cerca de 7,5 mil tokens Jev e 0,5 a 0,75 s de latência, e nada disso entra no contexto do agente além de uma nota de uma linha

5. Repita a MESMA tarefa e compare lado a lado

Mesmo prompt, mesmo projeto, mesmo estado do repo (faz um git stash ou volta pro commit anterior antes, senão tu está pedindo pro agente trabalhar em cima do trabalho dele mesmo)

No fim, /context e /usage de novo

O erro comum é comparar uma sessão curtinha com uma sessão longa: como o custo de reescrita de cache só aparece em sessão comprida, o teste de 3 prompts pode te dar a conclusão invertida

6. Quer rigor de verdade? usa o eval de plugin ou o OpenTelemetry

O eval de plugin do Claude Code roda os casos em sessão isolada só com o plugin alvo carregado e, por padrão, também SEM o plugin, e o relatório já te entrega a diferença

Isso mata o problema do passo 5 na raiz, porque a comparação é automática e não depende da tua memória

E se tu quer isso em série, o Claude Code tem instrumentação OpenTelemetry embutida: spans por requisição de modelo e por execução de ferramenta, com métricas de token e custo, exportáveis pro teu backend

Medir 30 sessões reais de trabalho vale MUITO mais que um teste de laboratório bonitinho

O que eu vi na prática testando uma camada de contexto

Aqui eu preciso ser honesto contigo: a camada que testei no vídeo não é o Jev

É outro plugin, focado em contexto, e o que interessa aqui é a leitura dos números, não o nome dele

No vídeo eu explico o problema de base: sem nenhuma camada, TUDO que tu pede vai pro contexto até compactar

E a compactação nem sempre salva o que realmente importa, aí o agente esquece justo a parte que tu precisava

Eu rodei três prompts num projeto real: refatoração, correção de vulnerabilidades e depois um endpoint novo de estatísticas com frontend (cards visuais e barra de progresso animada)

Depois disso, olhei o status do próprio plugin

Os números que apareceram: 84 KB de dados processados no total, e o status apontou redução de 50% no tráfego de tokens

A minha percepção de duração da sessão saiu de uns 10 a 20 minutos antes de compactar pra mais de uma hora

Agora o ponto que interessa pro método deste post

Tem um valor na minha fala que ficou ambíguo: em um momento ele aparece como o que foi pra sandbox e nunca entrou no contexto, em outro como o que de fato entrou

E é exatamente por isso que eu não quero que tu confie no meu número nem no número do README de ninguém

Sensação de sessão longa é ótima pra gravar vídeo e péssima pra decidir custo

/context e /usage não têm opinião, eles só contam

No vídeo acima tu vê a instalação, os três prompts rodando no projeto e a leitura do status no final, que é mais ou menos o ritmo que tu vai repetir no protocolo da seção anterior

A sessão ficou mais cara depois do roteamento: por que isso acontece

O sintoma:

Tu instalou uma camada que existe pra economizar

Rodou o dia inteiro

E no fim do dia a conta subiu em vez de cair

A causa:

Cache de prompt é POR MODELO

Então, quando o roteamento decide trocar o modelo do loop principal no meio da sessão, o contexto inteiro precisa ser escrito de novo pro modelo novo

Essa reescrita sai a 1,25x da taxa de input no cache de 5 minutos, ou 2x no cache de 1 hora

O próprio README do mod dá a conta que ilustra isso: algo em torno de US$ 2,40 pra pular de Opus 5.5 pra Sonnet 5 com 600k de contexto, contra US$ 0,12 pra manter o cache quente

Pra situar os preços de tabela: o Opus 5.5 custa US$ 4 por milhão de entrada, US$ 20 por milhão de saída e US$ 0,20 por milhão em leitura de cache

O Sonnet 5 custa US$ 2 por milhão de entrada e US$ 10 por milhão de saída

Percebe a armadilha? O modelo mais barato por token pode sair mais caro na conta final, porque tu pagou o pedágio da mudança

A solução:

Medir em sessão longa, não em prompt isolado

Num teste de dois prompts o cache ainda está pequeno e a troca parece de graça

É na sessão de duas horas, com contexto acumulado, que a conta muda de sinal

E já que a gente está falando de sessão longa: se a tua sessão cair no meio da tarefa, o jeito de retomar sem perder o trabalho também influencia esse custo, porque reconstruir contexto do zero é input pago igual

A prevenção:

Decida o roteamento pelo TAMANHO do contexto acumulado, não só pela dificuldade do prompt

E trate as duas coisas como decisões separadas: camada de contexto (tipo o skill suggestion) é um problema, camada de roteamento de modelo é outro

Juntar as duas num teste só é receita pra tu não saber qual delas causou o quê

Vale a pena por perfil de uso

Sem inventar percentual, dá pra separar bem os cenários

Tende a compensar: quem tem muita skill, muito agent e muito plugin habilitado

Lembra que todo plugin habilitado consome contexto MESMO sem ser usado, porque nomes e descrições entram em toda sessão e contam no teu uso

Se o teu /context all já mostra um monte de token gasto antes do primeiro prompt, uma camada que injeta só o SKILL.md escolhido ataca uma dor que tu já tem

Tende a atrapalhar: sessão longa, cache quente, projeto grande e troca de modelo no meio do caminho

Aqui o pedágio da reescrita de contexto pode comer a economia inteira e ainda pedir sobremesa

E as limitações de estado atual, que não dá pra varrer pra debaixo do tapete:

• O Jev está em early access por lista de espera desde 15/09/2026, sem anúncio de disponibilidade geral até agora
• Ele não tem endpoint compatível com OpenAI nem Anthropic, então não vira o modelo do Claude Code de jeito nenhum
• O papel dele é de camada auxiliar, e camada auxiliar se avalia por medição, não por promessa

Conclusão

O número que importa não é o do README, nem o do meu vídeo, nem o do post de ninguém

É o da TUA máquina, com o TEU CLAUDE.md, no TEU projeto

Então o próximo passo é bem simples e tu consegue fazer hoje: abre a sessão que tu já ia abrir de qualquer jeito, roda /context e /usage e guarda esses valores

Pronto, tu tem linha de base

Depois disso, instalar uma camada Jev (ou qualquer outra) deixa de ser fé e vira comparação

Se tu fizer o teste, volta aqui nos comentários e conta o que deu na tua sessão, principalmente se o resultado tiver sido o contrário do esperado

Esses são os mais interessantes 😀

Até o próximo post!