Preciso do Jev se já tenho um CLAUDE.md bem escrito?

Tratar CLAUDE.md e Jev como concorrentes é o jeito mais rápido de escolher errado os dois

Eles até parecem brigar pelo mesmo espaço, afinal os dois acabam "dando contexto" pro Claude Code. Só que um age no início da sessão, escrito por você em markdown, e o outro age no meio do fluxo, chamado pelo seu código, devolvendo uma resposta tipada. Camadas diferentes, momentos diferentes, contas diferentes

Bora separar isso direito?

O que cada um realmente é

CLAUDE.md: instrução persistente lida no launch

O CLAUDE.md é um arquivo markdown com instruções que o Claude lê no começo de cada sessão

O carregamento é hierárquico: no lançamento ele pega o arquivo do diretório de trabalho e de cada diretório pai, e os arquivos de subdiretórios entram sob demanda, quando ele lê algo ali dentro

O comando /init gera o CLAUDE.md inicial analisando a base de código, com comandos de build, instruções de teste e as convenções que ele descobre. O do projeto vive na raiz do repositório (arquivos de escopo de projeto em .claude/) e o pessoal em ~/.claude/CLAUDE.md. Se você define CLAUDE_CONFIG_DIR, todo caminho ~/.claude passa a viver nesse diretório

E tem um segundo sistema de memória junto: a memória automática, que o Claude escreve pra si mesmo. Ela vem ligada por padrão e o toggle fica em /memory, onde você também navega a pasta dessas notas pra ler, editar ou deletar

Resumindo: é texto. Bem escrito, persistente, mas texto lido por um modelo que vai interpretar do jeito dele

Jev: pergunta tipada, resposta estruturada

O Jev é o primeiro modelo público da TypeSafe AI, em early access, apresentado como a primeira geração de modelos System One (a TypeSafe diz estar abrindo o acesso e tirando desenvolvedores da lista de espera)

E aqui vem a parte que confunde todo mundo: ele não gera texto

Ele recebe um estado e perguntas tipadas, e devolve resposta estruturada que o seu código usa direto:

• Choice: uma escolha entre opções, com probabilidade por opção
• Score: um número numa régua definida por você
• Noul: um valor de 0 a 1 pra uma afirmação verdadeiro/falso

Não escreve código, não conversa. E toda decisão volta com uma estimativa de confiança junto (Choice e Score também retornam confiança), justamente pro seu software agir quando a confiança está alta e escalar quando não está

A versão listada hoje é a 1.13, e o campo de modelo aceita IDs versionados tipo jev-1.13.0 além de jev-latest

Se você conhece a diferença entre um README e uma função de validação, é mais ou menos isso: um orienta, o outro retorna valor

CLAUDE.md x Jev: comparativo direto

A medição de latência ali é da OpenRouter, comparando Jev e Claude Opus 5 em classificação, do mesmo cliente, com 8 requisições concorrentes, incluindo tempo de rede e fila do provedor. O Opus 5 com raciocínio desligado ficou em mediana 2.266 ms e p95 3.004 ms, cerca de 13x na mediana

Guarda esse número, ele explica muita coisa lá na frente

O que só o CLAUDE.md resolve

Tem uma pilha de coisa que o Jev simplesmente não foi feito pra fazer, e que o arquivo resolve de graça:

• Convenções do projeto: estilo, padrões, o que não mexer
• Comandos de build e instruções de teste, que o /init já descobre sozinho
• Preferências pessoais que valem pra todos os seus repos, em ~/.claude/CLAUDE.md
• Escopo por diretório: graças ao carregamento hierárquico, um subdiretório pode ter regra própria, carregada só quando o Claude lê arquivos ali

Nada disso precisa de chamada externa, nada disso tem custo por token, nada disso tem latência

Se o seu CLAUDE.md está fraco, nenhum modelo externo conserta isso. É o básico bem feito, e ele continua sendo o maior retorno por esforço no Claude Code

Tome cuidado com uma armadilha comum aqui: gente que escreve instrução do tipo "escolha o modelo mais barato quando a tarefa for simples" e acha que resolveu. Isso é um desejo escrito em markdown, não uma decisão mensurável

O que o CLAUDE.md não cobre e o Jev cobre

A documentação da TypeSafe é bem explícita: o Jev não é substituto drop-in do LLM que está por trás do Claude Code, Cursor, opencode, Copilot e similares

O uso indicado é outro: você usa seu agente de código normalmente pra escrever código que chama o Jev nos pontos de decisão. Ele entra dentro do harness, como camada de decisão, não como cérebro do agente

Os pontos de decisão citados na documentação oficial são:

• Roteamento de modelo: qual modelo atende esta requisição
• Recuperação semântica de contexto: o que puxar pro contexto agora
• Detecção de erro do LLM e guardrails (limites)
• Classificação de traço de raciocínio

Repara no que essas quatro coisas têm em comum: são decisões que se repetem várias vezes por turno, sempre com a mesma pergunta e entradas diferentes

E aí a instrução em markdown não dá conta, porque ela não retorna probabilidade, não retorna número comparável, e não retorna confiança. Ela influencia o texto que um modelo grande vai gerar… e você torce

Com o Jev, a confiança vem anexada em cada resposta. Confiança alta, o software age. Confiança baixa, o software escala pra outra coisa. É lógica de programa, não de prompt

Dois exemplos concretos de decisão que instrução não dá conta

Nada de teoria, bora nos casos publicados

1) Skill suggestion: escolher a skill certa sem truncar descrição

O cookbook oficial de skill suggestion usa divulgação progressiva em vez de truncar descrições

O fluxo é assim: ranqueia 182 skills em uma requisição, busca o texto completo das 3 primeiras e julga de novo. Dá duas requisições TypeSafe por turno, uma pra ranquear e uma pra verificar

Usa Choice pra escolher a skill e Nouls pra decidir se sugere alguma. Resultado reportado: reduz carregamentos errados de skill em mais da metade

Tenta escrever isso em CLAUDE.md. Você até consegue descrever a intenção, mas ranquear roster inteiro e depois reavaliar os finalistas é código, não instrução

2) fast-jev-compaction: compactação por pontuação, não por resumo

Por padrão, o Claude Code gerencia a janela de contexto sozinho ao chegar perto do limite: limpa as saídas de ferramentas mais antigas primeiro e depois resume a conversa se precisar. Ou seja, contexto cheio não encerra a sessão. O /context mostra o uso ao vivo por categoria, com sugestões de otimização

Bom comportamento padrão, mas o resumo é uma reescrita: o literal vira prosa

O plugin comunitário fast-jev-compaction troca esse resumo por decisões do Jev: pontua cada chamada de ferramenta e resultado em uma requisição, descarta ou trunca os obsoletos, e mantém literal o que fica

O repositório é ao mesmo tempo pacote npm (src/) e plugin do Claude Code (hooks/, .claude-plugin/)

De novo: é uma decisão repetida, mecânica, com resposta tipada. Exatamente a fatia que instrução persistente nunca vai ocupar

Usando os dois juntos: quem manda em quê

A divisão de papéis fica simples quando você para de comparar:

• CLAUDE.md descreve o projeto e as regras pro agente escrever código
• Jev é chamado pelo código que o agente escreveu, nos pontos de decisão

Um fala com o Claude, o outro fala com o seu programa

E existe uma ponte oficial entre os dois mundos: a TypeSafe mantém uma agent skill que dá ao agente contexto completo sobre a API, com os três tipos de pergunta, padrões arquiteturais e boas práticas pra estruturar avaliações

No Claude Code, a instalação é por plugin marketplace:

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

Em outros agentes:

npx skills add typesafe-ai/skills --skill typesafe-ai

E aí você seleciona o agente

A sacada é essa: com a skill oficial instalada, quando você pede pro Claude Code implementar um roteamento ou um guardrail, ele já sabe como é a API do Jev e qual primitivo faz sentido em cada caso. Você não fica explicando Choice, Score e Noul toda sessão =)

Veredito: você precisa do Jev?

Honestidade primeiro: depende do que você constrói

Se o seu uso é Claude Code interativo no dia a dia, abrir o terminal, pedir feature, revisar, commitar… o CLAUDE.md bem escrito continua sendo o maior retorno, disparado. Jev aqui é opcional, e eu diria que é distração se o seu arquivo ainda está no rascunho do /init

Se você constrói harness, plugin, hook ou pipeline com decisões repetidas por turno, é o contrário: o CLAUDE.md nunca vai cobrir isso. Não é questão de escrever melhor, é que markdown não retorna Choice com probabilidade nem Noul de 0 a 1

Agora a fricção real, sem enfeite:

• O Jev está em early access, com a TypeSafe liberando desenvolvedores da lista de espera
• A cobrança é só na entrada, saída gratuita, então o custo escala com o tamanho do estado que você manda
• Existem limites de taxa em tokens por segundo e requisições por minuto, por tier, com limites maiores em planos custom e enterprise (contato [email protected])

Ou seja: é uma dependência externa no seu fluxo, com conta e com rate limit. Não é "ligar e esquecer"

Pra quem está começando do zero com modelos dentro de agentes, esse vídeo do canal mostra como usar o Fable 5 e o Sonnet 5 de graça, funcionando também no OpenCode via ZenMux

Conclusão

Jev vs CLAUDE.md é uma falsa briga: um é instrução lida no launch, o outro é decisão tipada em runtime

O próximo passo é chato e é o certo: roda /init e depois /context pra auditar o que o seu CLAUDE.md está realmente carregando hoje. Dá uma olhada também no /memory, porque a memória automática já está ligada por padrão e você talvez nem saiba o que tem escrito lá

Arrumou a casa? Aí sim

Se sobrar um ponto de decisão que se repete todo turno no seu fluxo (roteamento, guardrail, seleção de contexto), instala a skill oficial e testa o Jev nesse ponto específico. Um ponto só, medindo

Começar pelo modelo externo antes de arrumar o arquivo é o caminho mais caro pro mesmo lugar 😀

até o próximo post!