Vale a pena usar o Jev fora do Claude Code? O que muda em Codex, OpenCode e outros agentes de terminal

Tem uma confusão rolando desde o lançamento: muita gente acha que o Jev é "um modelo que você pluga no agente e pronto"

Não é isso 🙂

O Jev é o modelo System One da TypeSafe AI, lançado em 15 de setembro de 2026, e ele não gera texto: recebe um estado e perguntas tipadas, devolve escolhas e scores com probabilidades

Então a pergunta que interessa pra quem não vive só dentro de um agente é outra: o fluxo que as pessoas montaram com Jev sobrevive quando você troca o Claude Code por Codex, OpenCode, Cursor ou Gemini CLI? Bora destrinchar isso

O que o Jev faz (e por que ele nunca vai ser o cérebro do seu agente de terminal):

Primeiro o porquê, que é onde quase todo mundo escorrega

Um agente de terminal precisa de um modelo que converse em formato de chat: o Claude Code fala Anthropic Messages, o Codex fala OpenAI Responses. A API da TypeSafe expõe um único endpoint de decisão, o POST https://api.typesafe.ai/v1/systemone

Não existe /v1/chat/completions ali, nem endpoint Messages

Tradução prática: o Jev não pode ser o modelo por trás do seu agente. Ele é um juiz que você chama no meio do caminho, tipo aquele colega que você consulta pra decidir "vai por A ou por B?" e volta a trabalhar

Se você conhece a ideia de feature flag decidida por serviço externo, o encaixe é bem semelhante: o agente continua sendo o agente, o Jev só responde a pergunta tipada

E o preço? US$ 0,042 por 1 milhão de tokens de entrada, com saída a US$ 0. Como a saída é escolha e score, e não um textão, o custo mora quase todo no estado que você manda

Sobre disponibilidade, o modelo está espalhado em alguns lugares:

• OpenRouter: lista a versão typesafe/jev-1.13, publicada em 18 de setembro de 2026, alcançável só via decisions endpoint (de novo: não é chat)
• Vercel AI Gateway: disponível com o model ID typesafe-ai/jev
• Cloudflare AI: o modelo typesafe/jev aparece documentado no catálogo

E o cadastro direto no console da TypeSafe? Aí vem o detalhe chato: abriu pra todos em 20 de setembro de 2026 com US$ 5 de crédito inicial e os novos cadastros foram pausados em 22 de setembro por causa da demanda

Contas já criadas continuam funcionando, e a empresa diz que quer reabrir. Até 24 de setembro de 2026 a home não tinha nem botão de waitlist, só Sign in e Contact sales…

Guarda essa informação, porque ela muda o "por onde começar" no fim do post

Jev no Claude Code x Codex x OpenCode x outros agentes: o que roda em cada um:

Em vez de comparar agente contra agente, o jeito honesto é comparar caminho de integração, porque é o caminho que é portátil ou não

Repara no padrão: a única coisa oficial é a skill, e o resto é comunidade

A skill oficial: mesma ideia, instalação diferente

A documentação da agent skill separa Claude Code dos demais agentes

No Claude Code:

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

Depois você invoca com /typesafe:typesafe-ai

Nos outros agentes:

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

O instalador pede pra escolher o agente, e daí você pede "use the TypeSafe skill" no chat

Tome cuidado com uma coisa: a instalação é project-local por padrão, e -g instala global. Isso importa bastante pra quem trabalha em dois projetos ao mesmo tempo, porque a skill que você instalou num repo simplesmente não existe no outro

E o que a skill entrega, na real? Contexto sobre a API da TypeSafe: os três tipos de pergunta, padrões arquiteturais e boas práticas

Ou seja, ela ensina o agente a usar o Jev. Ela não é uma integração automática de roteamento, e essa distinção é onde o hype costuma esticar demais

Os fluxos com Jev e como cada um se comporta fora do Claude Code:

Aqui separei por objetivo, que é como as pessoas de fato usam

1. Roteamento de modelo e esforço por tarefa

Esse é o caso famoso, e é o mais preso ao Claude Code

O jev-model-router é um mod do repositório claude-code-templates, que usa o Jev pra escolher modelo e nível de raciocínio por tarefa:

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

O problema é a base: mods são function hooks e rodam só no Claude Code, exigem a versão 2.1.259 ou superior, ficam atrás de CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 e a própria página de mods avisa que a API pode mudar entre releases

Ponto positivo: o mod aceita três rotas (API da TypeSafe, Vercel AI Gateway ou um classificador embutido) e, se a chamada falhar, o request segue sem alteração. As decisões ficam logadas

Esse fallback sem bloqueio é ótimo pra não travar teu dia, e ruim pra confiança: o roteamento pode simplesmente não ter acontecido e você nem percebe

Fora do Claude Code, o que existe de equivalente é o opencode-jev-router, pacote @robertn702/opencode-jev-router, com o comando opencode-jev-router. Ele funciona como proxy da Responses API e também como plugin in-process, e a partir da v0.2.0 o plugin é o caminho principal de setup

Requisitos duros: Node.js 24.x e TYPESAFE_API_KEY no ambiente ou no .env

Se você já quebra a cabeça com vários agentes no Claude Code, a lógica de roteamento por tarefa vai soar familiar: é a mesma pergunta de "quem pega qual trabalho", só que decidida por um modelo tipado

2. Guarda-corpo de permissão

Esse é o fluxo MAIS portátil da lista, e na minha leitura o mais interessante pra quem alterna ferramenta

O jev-guard instala hooks baseados em Jev na configuração de vários agentes, mantendo a mesma política e memória de sessão:

npm i -g jev-guard
jev-guard install claude

Troca o claude por codex, copilot, gemini, cursor, pi ou opencode e ele escreve os hooks na config do agente correspondente

O julgamento é feito com três perguntas tipadas ao Jev: risk, user_requested e from_untrusted

Sacou a jogada? Em vez de manter sete arquivos de permissão diferentes, a política vive num lugar e é o Jev que responde "isso aí é arriscado?" antes dos rm -rf da vida acontecerem

Tem também o jev-guard scan-skills, pra dar uma passada nas skills instaladas

3. Julgamento sob demanda dentro do chat

Quer chamar o Jev no meio da conversa, sem hook nenhum? MCP

O jev-mcp é um servidor MCP local em stdio (node dist/index.js) que expõe julgamentos tipados como ferramentas: jev_step, jev_coding_loop, jev_tool_route, jev_review, jev_verify, jev_screen e jev_rank, entre outras

Pede chave da TypeSafe, tem modo mock (ótimo pra quem está fora do cadastro) e licença MIT

Do lado do Codex, a documentação de MCP mostra suporte a servidores STDIO e Streamable HTTP, configurados em tabelas [mcp_servers.<nome>] dentro de ~/.codex/config.toml (ou .codex/config.toml no projeto). Você escreve à mão ou usa codex mcp add

E o detalhe bonito: o mesmo TOML vale pro app, pra CLI e pra extensão de IDE

Como MCP é protocolo, esse caminho serve pra Cursor, Codex e qualquer cliente MCP. É o que mais se aproxima de "escrevi uma vez, uso em tudo"

4. Auditoria pós-sessão

Esse eu achei mto massa pela abordagem: nem hook, nem roteador, nem MCP

O jevalyzer lê os logs de sessão que já estão no disco, de Claude Code, Codex, opencode, Gemini CLI e Antigravity, e gera relatório HTML ou dashboard no terminal

Zero integração em tempo de execução, zero risco de travar o agente. Você trabalha o dia inteiro e depois pergunta ao Jev o que foi bem julgado e o que foi decisão zoada

Pra quem usa três agentes diferentes na semana, é a forma mais barata de ter uma visão única sem instalar nada dentro do fluxo

Veredito: para quem trabalha com mais de um agente, vale ou não vale?

Vamos por perfil, que é o jeito honesto de responder

Se você vive no Claude Code: caminho mais curto, sem discussão. Plugin marketplace oficial pra skill, mod jev-model-router pro roteamento, e tudo documentado. É o ecossistema onde o Jev pegou primeiro

Se você alterna agentes: esquece replicar o roteador e vai nas camadas portáteis. O jev-guard e o MCP te dão o mesmo benefício em Codex, Cursor, OpenCode e companhia sem você manter gambiarra por agente. Quem usa OpenCode como daily driver tem o roteador próprio, então esse caso específico está coberto

Se você só quer entender o valor antes de investir: jevalyzer primeiro. Lê logs que já existem, não mexe em config de nada

Agora as ressalvas, porque não é tudo topzera:

• Tirando a agent skill, tudo é projeto comunitário. Isso significa cadência de manutenção fora do teu controle
• A API de function hooks do Claude Code pode mudar entre releases, segundo a própria página de mods. Integração nessa base é integração que você vai revisitar
• O fallback sem bloqueio do mod é uma faca de dois lados: não trava, mas também não avisa alto quando não roteou
• E o freio de mão: novos cadastros no console da TypeSafe estão pausados desde 22 de setembro de 2026. Se você ainda não tem conta, o acesso hoje passa pelas listagens em OpenRouter, Vercel AI Gateway ou Cloudflare AI, ou por modo mock

Eu não tenho número próprio de latência nem de custo por julgamento pra te dar aqui, e não vou inventar: os valores que circulam por aí vêm de repositórios de terceiros sem metodologia checável

Por onde começar hoje:

Depende de onde tu passa o dia:

1. Claude Code: instala a skill oficial com claude plugin marketplace add typesafe-ai/skills e claude plugin install typesafe@typesafe-ai, e só depois considera o mod. O erro comum aqui é pular a checagem de versão: sem Claude Code 2.1.259+ e sem CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1, o mod não tem base pra rodar
2. Codex ou Cursor: monta o jev-mcp em stdio e registra o servidor. No Codex, é tabela [mcp_servers.<nome>] em ~/.codex/config.toml ou codex mcp add. O erro comum é editar o TOML do projeto esperando efeito global (ou o contrário)
3. OpenCode: vai de opencode-jev-router pelo plugin, que é o caminho principal desde a v0.2.0. O erro comum é rodar em Node antigo: ele pede Node.js 24.x, e a chave TYPESAFE_API_KEY precisa estar no ambiente ou no .env
4. Vários agentes ao mesmo tempo: npm i -g jev-guard e depois um jev-guard install por agente que você usa. A política e a memória de sessão ficam compartilhadas, e é exatamente por isso que esse é o melhor custo-benefício de esforço
5. Sem chave da TypeSafe: não é o fim. O jev-mcp tem modo mock, e o jev-model-router cai num classificador embutido quando não tem API nem Gateway configurado. Dá pra sentir o formato do fluxo antes de gastar

Resumo da ópera: o Jev não migra como modelo, ele migra como camada de decisão. E quanto mais portátil a camada que você escolhe (MCP e hooks multiagente), menos você fica preso a um único terminal

Fica de olho na reabertura do cadastro no console, porque é isso que destrava o caminho mais direto pra quem está começando agora…

até o próximo post! 🙂