O jev conflita com hooks, comandos personalizados e CLAUDE.md no Claude Code?

Fala aí, beleza? Apareceu um mod que promete escolher o modelo do Claude Code por você usando o Jev, e a primeira reação de quem já tem a casa arrumada não é curiosidade, é medo

Você passou semanas ajustando CLAUDE.md, montou hooks em settings, escreveu comandos personalizados, organizou skills… e agora entra um componente de terceiro que mexe em qual modelo atende cada turno

Então vamos delimitar o assunto antes de tudo: aqui eu falo dos mods da comunidade, o jev-model-router e o jev-skill-suggestion, publicados no repositório davila7/claude-code-templates

Não é produto da Anthropic e não é produto da TypeSafe AI

O Jev em si é outra coisa: o modelo de decisão "System One" da TypeSafe, que recebe estado não estruturado e devolve decisão tipada (Choice, Score, Noul) com probabilidades calibradas, em vez de gerar texto

Ou seja: ele não escreve seu código, ele decide 🙂

O que exatamente o mod encosta na sua configuração

Antes de julgar atrito, vale entender ONDE a coisa se instala

O comando de instalação do roteador é esse:

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

A flag --mod grava o plugin dentro do projeto, com essa estrutura:

.claude/skills/jev-model-router/
  .claude-plugin/plugin.json
  hooks/hooks.json
  hooks/jev-model-router.ts

Em projeto confiado, o Claude Code carrega esse diretório automaticamente e o plugin aparece como jev-model-router@skills-dir

E os meus hooks clássicos, onde ficam nessa história?

Com function hooks ligados, o hooks.json ganha uma chave nova: modules

Os hooks clássicos (command, http, mcp_tool, prompt, agent) continuam rodando ao lado

O arquivo pode ter hooks, pode ter modules, pode ter os dois: function hooks não substituem nem desligam hook clássico de settings

Isso já mata metade do medo, né?

Onde o mod engancha

O roteamento acontece em dois pontos, e eles são independentes:

As duas chaves de turn.step vêm como opt-in, e o motivo documentado é o routeMainModel: trocar de modelo no meio da sessão invalida o cache de prompt

E detalhe importante pra quem vive contando token: as decisões de roteamento ficam registradas no transcript da sessão, mas não são enviadas ao LLM

Custo de contexto zero

Pontos de atrito: sintoma, causa e o que fazer

Agora a parte que interessa: o que de fato dá ruído, e o que é medo sem causa

Instalei e nada acontece, nem erro aparece:

O sintoma mais comum é o silêncio total

Causa: o mod só funciona em Claude Code com os function hooks ligados por variável de ambiente

Sem CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1, ele carrega e não faz absolutamente nada, sem aviso

O piso de versão também conta: Claude Code 2.1.259 ou superior

Como prevenir: confira a versão e suba a sessão já com a variável, em vez de instalar e ficar esperando mágica

Meus hooks de settings pararam de rodar?

Não, e esse é o ponto onde o design ajuda

Como já vimos, os hooks clássicos seguem valendo junto dos modules

Se algum hook seu parou, o culpado provável é o de sempre: sintaxe do seu próprio hooks.json, ou o hook estar declarado num escopo de settings diferente do que você está olhando

Como prevenir: mexa em uma coisa por vez, e não edite hooks.json no mesmo commit em que instala o mod

CLAUDE.md sendo ignorado depois de instalar:

Aqui eu vou ser honesto com você: não existe documentação descrevendo leitura, reescrita ou override de instruções de CLAUDE.md por esses mods

Então eu não vou afirmar nem negar comportamento específico

O que dá pra afirmar é o que está documentado: as decisões do roteador ficam no transcript e nunca vão pro modelo

Se as regras do projeto estão sendo atropeladas, o caminho é separar as causas, e vale lembrar que instrução ignorada no CLAUDE.md é um problema que existe bem antes de qualquer mod entrar na jogada

Como prevenir: reproduza o comportamento com claude --safe-mode antes de culpar o mod

Configurei o mod no projeto e a config não pega:

Esse pega muita gente que trabalha por repo

As opções do mod ficam em pluginConfigs nas configurações de usuário (~/.claude/settings.json), não nas settings do projeto

Também dá pra passar um arquivo com --settings <arquivo>, ou vir por managed settings

Como prevenir: se você versiona .claude/settings.json do projeto pro time inteiro, aceite que a config do roteador não vai viajar por ali

A sessão ficou lenta ou esquisita do meio pra frente:

Causa provável: troca de modelo no meio da conversa

Cache de prompt é por modelo, o cache não é compartilhado, e a troca faz o contexto ser reescrito pro modelo novo

Por isso o roteamento de modelo no loop principal é opt-in e não vem ligado de cara

Como prevenir: em sessão longa, deixe o loop principal fora do roteamento e roteie só subagente

Minhas skills pararam de ser escolhidas pelo Claude:

Esse é o atrito mais real da lista, e ele vem do OUTRO mod

O jev-skill-suggestion retira a listagem de skills do contexto e deixa o Jev escolher no máximo uma skill por prompt, injetando o SKILL.md escolhido

E ele tem um comando de setup, /jev-skill-suggestion:setup, que marca as skills instaladas como user-invocable-only

Ou seja: ele altera a configuração de skills já existentes na sua máquina

Pra entender e reverter, os campos oficiais são estes:

• disable-model-invocation: true no frontmatter, só o usuário invoca
• user-invocable: false no frontmatter, só o Claude invoca
• user-invocable-only em skillOverrides nas settings

Como prevenir: se seu fluxo depende do modelo escolher skill sozinho, não rode o setup desse mod sem antes saber o estado atual de cada skill sua

E os comandos personalizados?

O que está documentado é que o jev-skill-suggestion traz um slash command próprio, o de setup

Sobre precedência, sobrescrita ou bloqueio dos SEUS comandos em .claude/commands, não achei documentação

Como prevenir: veja abaixo o plugin validate, que lista o que o plugin engancha antes de você rodar nada

Como isolar o teste sem bagunçar sua configuração

A ideia aqui é simples: nada entra nas suas settings antes de você ver o que a coisa faz

1. Valide o plugin antes de usar. O comando oficial lista cada evento enganchado e cada chamada ao objeto $:

claude plugin validate .claude/skills/jev-model-router

Erro comum deste passo: pular ele porque "é só um mod de roteamento". É exatamente aqui que você descobre se o plugin toca algo que você não esperava

2. Carregue por sessão, sem gravar nada. O Claude Code permite carregar um plugin só pra sessão atual:

CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude --plugin-dir .claude/skills/jev-model-router

A flag é repetível, e /reload-plugins recarrega edições dentro da sessão

Erro comum deste passo: usar --plugin-dir e esquecer a variável de ambiente, aí você jura que o mod é furado quando ele só está desligado

3. Use o modo seguro pra separar "é o mod" de "é a minha config". O claude --safe-mode (ou a variável CLAUDE_CODE_SAFE_MODE) sobe a sessão com as SUAS customizações desligadas: CLAUDE.md, skills, plugins, hooks, servidores MCP, comandos personalizados e agentes

Erro comum deste passo: achar que safe mode zera TUDO. Os hooks e a política de settings que são gerenciados pela organização continuam valendo mesmo ali, e isso importa muito em repo de empresa

4. Rode primeiro sem chave de API nenhuma. Sem chave configurada, o mod recorre ao classificador embutido do próprio motor do Claude Code, e você pode até forçar provider para builtin

Erro comum deste passo: criar conta e sair colando chave antes de saber se o roteamento faz sentido no seu fluxo

5. Ligue uma camada por vez. Comece por routeSubagentModel, deixe routeMainEffort e routeMainModel desligados, e só depois mexa nos limiares minUpgradeConfidence e minDowngradeConfidence

Ajuste timeoutMs e deixe logDecisions ativo enquanto estiver avaliando

Erro comum deste passo: ligar as três camadas juntas e não ter a menor ideia de qual delas causou a mudança de comportamento

6. Conforte-se com o fail-open. Erro, timeout, confiança baixa e downgrade bloqueado deixam a requisição exatamente como o motor do Claude Code montou

Erro comum deste passo: interpretar "nada mudou" como bug. Pode ser o mod funcionando como prometido, sem alterar a requisição original

Quando vale ligar e quando é melhor deixar de fora

Vale ligar quando seu projeto espalha trabalho em muitos subagentes: rotear só agent.spawn mexe no modelo de cada spawn e não encosta na sua conversa principal

É o cenário de melhor relação entre efeito e risco

Melhor deixar de fora quando você vive em sessão longa e cache quente: aí turn.step desligado é a escolha óbvia, porque o cache é por modelo e a troca reescreve o contexto

Em repo de time com settings gerenciadas, pense duas vezes: a config do mod mora nas settings de usuário, então cada pessoa configura a própria, e as políticas da organização seguem valendo por cima

Se você não quer criar conta na TypeSafe, o builtin resolve

E se seu fluxo depende de skill escolhida pelo modelo, fique longe do jev-skill-suggestion, pelo motivo que já expliquei lá em cima

E se eu quiser usar o Jev de verdade?

Aí entra a parte de acesso, que mudou rápido

O Jev foi lançado em acesso antecipado pela TypeSafe AI em 15 de setembro de 2026, abriu pra todos sem lista de espera em 20 de setembro e teve novos cadastros pausados em 22 de setembro por excesso de demanda

Contas já criadas continuam funcionando

Mesmo com o cadastro direto pausado, ele segue acessível por rotas de terceiros: Vercel AI Gateway e OpenRouter (listagens jev-latest e jev-1.13)

Sobre custo: US$ 0,042 por milhão de tokens de entrada, com tokens de saída gratuitos

É por isso que a chave provider e as duas chaves de API separadas (typesafeApiKey e gatewayApiKey) existem: a decisão de rota é sua

O risco que não é conflito, é segurança

Aqui eu preciso ser chato, porque essa parte é mais importante que a briga com seus hooks

Function hooks (nome de produto: Claude Mods) estão em acesso antecipado, atrás de flag desligada por padrão, ainda não em disponibilidade geral, e a API pode mudar entre releases

A proposta está aberta na issue #91870 do repositório anthropics/claude-code, e a Anthropic publicou o código-fonte de três mods embutidos mais as declarações TypeScript no diretório mods do próprio repo

Ou seja: dá pra estudar o mecanismo na fonte, e vale fazer isso

A pesquisa de segurança sobre os mods encontrou quatro riscos em function hooks, incluindo $.fs.read não ser limitado ao projeto nem à sessão (aceita caminho absoluto), spoofing de UI e captura de entrada digitada

E tem um detalhe que merece atenção: quando um plugin já confiado recebe atualização, o Claude Code carrega hooks de ciclo de vida novos sem pedir nova autorização item por item

Isso conversa direto com a discussão de até onde deixar o agente agir sozinho: plugin de terceiro é código executando na sua máquina, não é config inofensiva

Daí o hábito que eu insisto: claude plugin validate primeiro, --plugin-dir por sessão depois, settings só no fim

Material de apoio sobre automação por evento

Todo esse papo de hook é, no fundo, automação disparada por evento: algo acontece, seu código reage

Se você quer entender essa lógica do zero, esse vídeo do canal mostra o funcionamento de webhooks no N8N passo a passo, do conceito até o fluxo rodando

Conclusão

Resumo do veredito: conflito do jev no Claude Code é baixo por design

Os hooks clássicos convivem com os modules no mesmo arquivo, o roteador falha aberto, e as decisões nem entram no contexto

O atrito de verdade está concentrado em três pontos: a flag de function hooks (sem ela é silêncio total), o escopo das settings (pluginConfigs é do usuário, não do projeto) e o jev-skill-suggestion, que muda o estado das suas skills existentes

Próximo passo concreto: rode claude plugin validate, carregue por sessão com a variável de ambiente e --plugin-dir, ligue só agent.spawn e compare com uma sessão em claude --safe-mode

Só depois disso escreva qualquer coisa nas suas settings 😀

Até o próximo post!