O que o Jev lê do seu projeto antes de o Claude Code começar a trabalhar?

Antes de aprovar qualquer integração num repositório que tem código de cliente, a pergunta certa não é o que a IA faz

é o que ela recebe

O Jev virou assunto no ecossistema do Claude Code rápido demais: apresentado em 15 de setembro de 2026 em early access, com acesso aberto pra todo mundo em 21 de setembro

Aí começou a enxurrada de posts dizendo que ele "analisa seu projeto". Então bora fazer a leitura honesta: o que realmente sai do seu computador quando o Jev está em uso, e o que é só documentação entrando no contexto do agente 🙂

O que é o Jev e por que ele aparece dentro do Claude Code

O Jev é o primeiro modelo público da TypeSafe AI, startup fundada pelo ex-pesquisador da OpenAI Diogo Almeida, como noticiou o Olhar Digital

E ele é uma criatura diferente do que você está acostumado. Ele não gera texto livre e não chama ferramentas

O que ele faz é: recebe dados mais uma lista de perguntas tipadas, e devolve valores de um schema declarado antes. Só isso

As três primitivas de pergunta:

• Choice: escolhe uma opção entre até 255
• Score: posição numa escala de 2 a 10 níveis, descritos por você
• Noul: probabilidade de uma afirmação sim/não ser verdadeira, de 0 a 1

Se você conhece um enum de linguagem tipada, é bem parecido: o conjunto de saídas possíveis está fechado antes da chamada acontecer

E é exatamente aqui que a superfície de risco muda. Não tem resposta em texto livre pra vazar conteúdo de arquivo de volta, não tem chamada de ferramenta, não tem acesso autônomo a nada no seu disco

O id de API versionado atual é jev-1.13.0, com os aliases jev-latest (o padrão dos SDKs) e jev-preview

E tem um detalhe de preço que conta a história toda: US$ 0,042 por 1 milhão de tokens de entrada e US$ 0,00 por 1 milhão de tokens de saída

Saída de graça porque saída é um punhado de valores de schema. O que é contabilizado é o que entra

Ou seja: a conta que você paga é literalmente proporcional ao que você mandou pra fora. Guarda esse raciocínio, ele volta lá na frente

Onde o Jev encosta no seu projeto hoje (e o que cada caminho envia)

Existem caminhos diferentes pro Jev aparecer perto do seu Claude Code, e as pessoas misturam os três como se fossem a mesma coisa. Não são

1. O agent skill oficial da TypeSafe

A TypeSafe publica um agent skill oficial que é instalado no Claude Code como plugin:

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

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

Para outros agentes, o caminho é outro:

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

A instalação é project-local por padrão, e -g instala global

E o que tem dentro desse skill? Material de referência sobre a API: conceitos, design de perguntas, padrões de composição, API HTTP, notas de SDK e cookbooks, mais um índice de fontes upstream. Dá pra conferir no repositório typesafe-ai/skills

Presta atenção nisso, porque é o ponto que mais gera confusão: o skill oficial é documentação entrando no seu contexto, não dados seus saindo. A documentação descreve o conteúdo dele como contexto da API entregue ao agente

Quem faz dado sair da máquina é código chamando o endpoint

2. O mod comunitário jev-skill-suggestion

Esse é diferente, e é o que de fato conversa com o Jev durante a sua sessão

O jev-skill-suggestion é um mod do repositório davila7/claude-code-templates (PR #932, por davila7), instalado assim:

npx claude-code-templates@latest --mod productivity/jev-skill-suggestion

O que ele faz: tira a listagem de skills do contexto do Claude Code e manda a lista de skills disponíveis para o Jev classificar qual deve ser injetada

Funciona com a API da TypeSafe ou com o Vercel AI Gateway

O ganho reportado no cookbook de skill suggestion da TypeSafe, citado pelo mod: num conjunto de 182 skills, o carregamento de skill errada caiu de 16,8% para 7,3%, e o de skills desnecessárias caiu de 9,8% para 4,0%

Marcando o óbvio: esse número é da empresa, em avaliação dela. Não é auditoria independente

Se você já penou com skill que não carrega no projeto certo, entende bem o problema que o mod tenta resolver: o agente escolhendo errado no meio de uma pilha grande de skills

3. Integração própria via SDKs oficiais

A TypeSafe mantém SDKs oficiais para Python (typesafe-sdk) e TypeScript (@typesafe-ai/sdk)

Aqui não tem mistério nem surpresa: quem decide o que vai no state é você, no seu código

E é o caminho mais honesto pra quem precisa responder a um time de segurança, porque o conteúdo enviado está escrito no seu repositório, linha por linha

O que o Claude Code carrega sozinho x o que chega ao Jev

Essa é a confusão número um do tema, então vale a tabela

São duas camadas separadas: o contexto que o seu agente monta na máquina, e o payload que sai pela rede numa chamada ao Jev

A leitura da tabela é essa: suas convenções e instruções de projeto entram no contexto do agente por padrão, porque o Claude Code carrega os arquivos de memória sozinho ao iniciar

Elas só chegam ao Jev se a integração explicitamente colocar aquilo no state

No caso do mod de skill suggestion, o que vai é a lista de skills disponíveis

Tome cuidado com um detalhe que passa batido: o CLAUDE.md pode importar outros arquivos com a sintaxe @caminho/do/arquivo. Então o seu contexto local pode ser bem maior do que você lembra de ter escrito

Checklist para saber o que sai do seu computador antes de aprovar

Sequência curta, sem invenção, na ordem que faz sentido pra quem vai assinar embaixo

1. Mapeie o que o Claude Code já carrega sozinho na sessão. Abra a hierarquia de memória do projeto (./CLAUDE.md, ~/.claude/CLAUDE.md, ./CLAUDE.local.md) e siga cada import @ até o fim. O erro comum deste passo: revisar só o CLAUDE.md da raiz e esquecer que os imports puxam arquivo que você nem lembrava que existia

2. Identifique qual caminho está ativo no projeto. Skill oficial via plugin, mod jev-skill-suggestion ou integração própria pelos SDKs. São coisas distintas com consequências distintas. Lembrando que a instalação do plugin é project-local por padrão e global com -g, então um -g distraído espalha a decisão pra todos os seus projetos

3. Se for integração própria, inspecione o state que você monta antes de enviar. É ele, e só ele, que define o limite do que sai. O erro comum deste passo: montar o state concatenando arquivo inteiro "por garantia", quando a pergunta tipada precisava de três campos

4. Se for o mod, saiba com quem você está falando. O destino pode ser a API da TypeSafe ou o Vercel AI Gateway, e isso muda a resposta que você dá pro time de segurança. O erro comum deste passo: aprovar "o Jev" sem olhar qual provedor está configurado

E o erro comum que atravessa todos eles: assumir que documentação lida pelo agente equivale a código enviado pra fora. Não equivale

Se você quer um processo mais estruturado pra isso, tem um material aqui sobre avaliar um sistema antes de instalar que se encaixa direitinho antes desse checklist

Dá para aprovar o Jev num repositório com código sensível?

Veredito honesto, sem promessa de fórmula mágica

Do lado bom: a política de privacidade da TypeSafe diz que a empresa não treina nem faz fine-tune de modelos de IA ou machine learning com o Input do cliente, e que não divulga Input a terceiros além de prestadores de serviço. Os pesos são os mesmos para todas as contas

Isso é mais explícito do que boa parte do mercado escreve

Do lado que exige atenção: o addendum de processamento de dados prevê que Customer Data pode ser processado para prestar o serviço e derivar telemetria, e que essa telemetria pode ser usada para melhorar os serviços e produtos da TypeSafe

E tem o ponto que eu acho o mais importante de todos: zero data retention existe, mas sob solicitação, para clientes enterprise

Ou seja, a política geral NÃO equivale a compromisso de retenção zero. Se o seu contrato de confidencialidade fala em retenção, isso é conversa comercial, não é checkbox

Então pra quem o risco tende a ser aceitável? Pra quem manda state curto e estruturado, tipo uma lista de nomes de skills. O payload é pequeno, previsível e não carrega código de cliente

E pra quem exige conversa antes? Repositório com dado regulado, ou contrato de confidencialidade estrito. Aí você fala com a TypeSafe sobre ZDR antes de liberar, não depois

Ah, e sobre os números de desempenho que circularam: a própria TypeSafe afirma que o Jev pode ser até 193,6 vezes mais rápido e 444,6 vezes mais barato em determinados fluxos avaliados internamente

São números autoatribuídos, de avaliação interna. Servem como indicação de ordem de grandeza, não como substituto da sua avaliação no seu fluxo

Conclusão

A ideia central do post cabe numa linha: com um modelo que só devolve valores de um schema declarado antes, a superfície de exposição é definida pelo state

e o state é definido pela integração, não pelo modelo

O Jev não sai passeando pelo seu repositório. Quem monta o payload é o código que chama o endpoint, seja o mod comunitário mandando a lista de skills, seja o seu próprio código usando os SDKs

Próximo passo concreto, na ordem: abra o que a sua integração envia hoje, revise a hierarquia de CLAUDE.md do projeto (imports inclusos) e, se o seu caso pede, procure a TypeSafe pra tratar ZDR antes de liberar o uso pro time

Transparência é isso: saber responder o que sai da máquina, sem achismo

até o próximo post! 😀