JEV no Claude Code vale a pena se você já tem seu próprio fluxo de prompts?

Fala aí, beleza? Teu CLAUDE.md já está afinado, as convenções do time estão escritas, os prompts que tu usa todo dia já viraram músculo… e aí aparece o Jev pedindo espaço no teu fluxo

O Jev é o primeiro modelo "System One" da TypeSafe AI, anunciado em 15/09/2026: ele não gera texto nem código, só responde perguntas tipadas com probabilidade calibrada

O que está em jogo aqui é simples: o que tu ganha em padronização e o que tu perde em controle fino do prompt

O que o Jev faz (e o que ele não faz)

A ideia é simples de entender por aproximação: se um LLM é o cara que escreve a resposta, o Jev é o cara que só aponta o dedo

Ele responde três tipos de pergunta: escolha, score e sim/não

Cada resposta vem com probabilidade calibrada, e ele responde todas as perguntas em uma passagem paralela, na casa de centenas de milissegundos: 70 a 500 ms por chamada

O preço é a parte que chama atenção: US$ 0,042 por 1 milhão de tokens de entrada, e tokens de saída a US$ 0,00

Faz sentido, né? Não tem saída pra cobrar, a saída é um veredito tipado

Não fica preso à API própria: o OpenRouter lista os modelos typesafe/jev-1.13 e jev-latest sob o provedor typesafe, com o mesmo preço da página de docs

Contexto de quem está por trás: a TypeSafe AI saiu do stealth com o Jev em 15 de setembro de 2026, fundada pelo ex-pesquisador da OpenAI Diogo Almeida, com US$ 40 milhões captados

E aqui vai o ponto que resolve metade da confusão: o Jev não substitui o Claude

Ele não escreve o teu código, não refatora nada, não responde "como faço X"

Ele decide o que o Claude vê antes do Claude começar a pensar

Um detalhe de estado atual que importa pra decisão: depois de abrir pra todos sem lista de espera em 20/09/2026, a TypeSafe pausou temporariamente novos cadastros por excesso de demanda (anúncio de 22/09/2026), e contas já criadas seguem funcionando

Antes da pausa, o cadastro no console liberava US$ 5 de crédito grátis pra testar

Se esse crédito continua valendo durante a pausa, e se os cadastros já reabriram, eu não tenho confirmado, então não vou afirmar

Como o seu fluxo atual de prompts funciona hoje no Claude Code

Antes de comparar, bora olhar a linha de base que tu já tem funcionando

O CLAUDE.md entra em contexto no começo de toda conversa, junto com memória automática, nomes de ferramentas MCP e descrições de skills

Ele é lido integralmente até 4 MiB, e é ignorado se for maior que isso

Arquivos de tópico são diferentes: o Claude Code não carrega eles no startup, ele lê sob demanda com as ferramentas de arquivo quando precisa

Em monorepo tem um comportamento bem útil: iniciar o Claude de um subdiretório carrega o CLAUDE.md local e o da raiz, sem puxar instrução de outros pacotes

Ou seja, rodando de packages/api tu pega packages/api/CLAUDE.md mais o CLAUDE.md da raiz

Esse é o controle fino que tu já tem hoje: tu escreve, tu ordena, tu sabe exatamente o que foi pro contexto

Zero probabilidade envolvida, zero chave de terceiro, zero surpresa

É a mesma tensão que aparece no comparativo entre get-shit-done e fluxo próprio: adotar uma camada pronta ou seguir mandando na mão?

Os três caminhos para usar o Jev com o Claude Code

Primeiro, o fato que define tudo: o Claude Code não chama o Jev nativamente

O Jev é uma API HTTP hospedada, com chave própria, então o agente precisa de um caminho até ela

E existem três, com implicações bem diferentes pra quem manda no prompt

Caminho 1: a agent skill oficial da TypeSafe

A rota oficial pra agentes é uma agent skill, instalada no Claude Code pelo marketplace de plugins:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

A instalação é project-local por padrão, e tu usa -g pra deixar global

A invocação é /typesafe:typesafe-ai

E o que essa skill faz, na prática? Ela dá ao agente contexto da API TypeSafe: os três tipos de pergunta, padrões arquiteturais e boas práticas pra estruturar avaliações

Atenção nessa diferença, porque muita gente entende errado: é skill de contexto, não é um roteador automático

Ela te ajuda a construir a avaliação, ela não decide sozinha o que entra no teu prompt

Caminho 2: script próprio

É uma API HTTP com chave, então tu pode chamar do teu jeito e plugar onde quiser no teu fluxo

Aqui o controle continua 100% teu: tu escreve a pergunta tipada, tu decide o que fazer com o veredito

Mais trabalho, mais previsibilidade

Caminho 3: MCP ou plugin da comunidade

A TypeSafe não publica servidor MCP próprio: os MCPs de Jev pra Claude Code são da comunidade

Esse é o caminho com menos trabalho e mais delegação: tu entrega a decisão de contexto pra um componente de terceiro

Cada caminho muda quem fica no controle do prompt, e é exatamente isso que tu está decidindo neste post

jev-rules: o caso concreto de quem trocou o fluxo de prompts pelo Jev

Pra não ficar no abstrato, vale olhar o exemplo mais direto da ideia: o jev-rules, plugin de Claude Code mantido por EliaAlberti, licença MIT e sem dependências

A mecânica é bonita de simples: pra cada regra, ele faz uma pergunta sim/não ao Jev ("o pedido é sobre isso?") e entrega ao Claude só as regras aprovadas

E se algo falhar? Ele volta a mostrar todas as regras

Esse fallback é o detalhe que separa brinquedo de ferramenta, na minha visão: falhar mostrando tudo é melhor que falhar escondendo

As regras ficam no projeto, um arquivo Markdown por regra, dentro de .claude/jev-rules/

A chave é lida do ambiente, depois do .env do projeto, depois de ~/.jev-rules.env, nessa ordem, e aceita tanto TYPESAFE_API_KEY quanto AI_GATEWAY_API_KEY (a do Vercel AI Gateway)

Versões recentes mudaram a forma de entrega: a v0.3.0 entrega cada regra e documento de mapa uma vez por sessão, e a v0.4.0 adicionou um painel lateral, acionado por /rules, que lista as regras com o score do Jev

Tem também um gancho que eu achei mto massa: ele julga o caminho do arquivo antes de uma edição, em Edit, Write, MultiEdit ou NotebookEdit, pra injetar as regras ligadas àquele arquivo

Sobre performance, o autor do plugin afirma 12 regras julgadas em 367 a 773 ms e cerca de US$ 0,00002 por prompt

Isso é afirmação dele no repositório, não teste do Hora de Codar, então trate como número do fornecedor

Pra instalar, o caminho certo é o README do próprio repositório, que é onde o autor mantém os comandos em dia

Jev x seu fluxo de prompts atual x hooks nativos do Claude Code

E tem um terceiro competidor que quase ninguém coloca na mesa: o Claude Code já tem decisão com julgamento embutida

São os hooks do tipo prompt, que mandam o prompt e os dados do hook pra um modelo Claude decidir em uma única chamada e devolver JSON

O modelo padrão é Haiku, trocável pelo campo model, e os agent hooks abrem um subagente que pode ler arquivos e usar ferramentas

Os pontos de encaixe são os mesmos que esse tipo de integração usa: UserPromptSubmit, que injeta contexto extra no prompt via hookSpecificOutput.additionalContext, e PreToolUse, que pode negar a chamada ou reescrever os argumentos com updatedInput

Quando adotar o Jev e quando ficar no que você já tem

Bora ser prático, porque a resposta muda muito com o teu cenário

Favorece o Jev:

• Monorepo com dezenas de regras por stack, onde cada pacote tem convenção própria e quase nada disso vale pro pedido atual
• Regras que só fazem sentido pra certos caminhos de arquivo (aí o julgamento do path antes do Edit brilha)
• Time com convenções longas, daquelas que estouram o começo da sessão e comem contexto que tu queria pro código
• Casos em que tu prefere regra enxuta e relevante a regra completa e ignorada

Favorece ficar no que tu já tem:

• Poucas convenções, projeto solo, CLAUDE.md de tamanho civilizado
• Aversão a dependência externa com chave própria (é uma superfície nova pra quebrar e pra revisar)
• Necessidade de reprodutibilidade exata do prompt, tipo auditoria ou debug fino de comportamento do agente
• O risco que ninguém pode ignorar: o gate é probabilístico, então ele pode errar e esconder justamente a regra que importava naquele pedido

E tem o meio do caminho, que é o que eu acho mais saudável pra quem está em dúvida: quebrar o CLAUDE.md em regras separadas por assunto e por arquivo

Isso já melhora teu fluxo hoje, sem chave, sem serviço de terceiro, e é exatamente a forma que qualquer roteamento posterior vai exigir

Veredito: o que se ganha em padronização e o que se perde em controle fino

O ganho é real: contexto enxuto, regras selecionadas por relevância no momento do pedido, custo de entrada praticamente irrelevante no preço publicado e latência baixa pro que ele faz

Padronização também entra na conta: regra virou arquivo, arquivo virou coisa que o time revisa em PR, e o "combinado do time" para de viver na cabeça de quem escreveu o prompt

A perda é igualmente real, e é onde eu peço calma

O teu prompt deixa de ser determinístico

Tu passa a depender de chave e de serviço de terceiro pra montar o começo de cada conversa

E a autoria do roteamento sai do teu arquivo e vai pra um componente que tu não escreveu

Recomendação por perfil, sem fingir que eu rodei bateria de teste aqui:

• Projeto solo ou convenção curta: fica no teu fluxo, tu não tem o problema que o Jev resolve
• Time com convenção grande ou monorepo: vale testar, começando por um subconjunto de regras e mantendo o fallback ligado
• Quem quer o ganho sem terceiro: testa hooks type prompt com UserPromptSubmit antes de plugar API externa
• Quem precisa de prompt reproduzível: nem considera gate probabilístico, resolve com arquivos de tópico lidos sob demanda

Conclusão

Resumo em uma frase: o JEV no Claude Code compra contexto enxuto pagando com previsibilidade, e esse câmbio só é bom se o teu gargalo hoje é excesso de regra entrando em toda sessão

Lembra do estado atual antes de planejar: novos cadastros na TypeSafe foram pausados em 22/09/2026 por excesso de demanda, e contas já criadas seguem funcionando (o Jev também aparece no OpenRouter como typesafe/jev-1.13 e jev-latest)

Próximo passo prático, que serve nos dois mundos: quebra teu CLAUDE.md em regras separadas por assunto e por arquivo

Tu melhora o fluxo atual imediatamente e fica pronto pra plugar um gate depois, se decidir que vale

E se tu está começando essa arrumação agora, vale olhar como montar seu sistema começando pequeno antes de adicionar mais uma peça móvel

A outra ordem possível é testar hooks type prompt nativos primeiro, e só depois pensar em depender de serviço de terceiro

Faça o teste e me conta: tu confia num gate probabilístico decidindo qual convenção o teu agente vê? Bora trocar uma ideia

até o próximo post! 😀