Cada tarefa no modelo certo

Você chamaria um dev especialista com 20 anos de experiência para trocar o nome de uma variável? Eu também não. Mas é mais ou menos isso que acontece quando todo subagente roda no mesmo modelo.

Fiz um plugin para o Claude Code que tenta resolver isso.

O problema

Quando o Claude Code dispara um subagente, ele roda no modelo da sessão, mesmo que a tarefa seja pequena e mecânica. Renomear um campo e redesenhar um módulo custam o mesmo “cérebro”.

Mesmo quando você escreve um prompt ou uma spec, quem escolhe o modelo e o effort é o próprio modelo que está rodando.

No fim, gastamos nosso usage com essas tarefas, quando poderíamos usá-lo no desenvolvimento.

A ideia

Pense numa fila de atendimento. Quem chega com uma dúvida simples fala com o atendente. Quem chega com um caso difícil vai para o especialista. Ninguém acha isso estranho. Rotear cada tarefa para o modelo certo é isso.

O plugin intercepta os spawns de subagente do Claude Code (a ferramenta Agent) e pergunta ao JEV, da TypeSafe, o que aquela tarefa pede: modelo (haiku, sonnet ou opus), effort e perfil de ferramentas.

Instalação

Numa sessão do Claude Code:

/plugin marketplace add hiyoku/jev-orc
/plugin install jev-orchestrator@jev-orc

O segundo comando abre os detalhes para você escolher o escopo: usuário, projeto ou local. Depois é só configurar a chave do JEV, no campo typesafeApiKey (guardada no Keychain do macOS) ou na variável TYPESAFE_API_KEY.

Você não chama o JEV. Com o plugin ligado, os spawns passam por ele. Por padrão, só os agentes do próprio Claude Code são roteados. /jev-orc liga e desliga, e /jev-orc status mostra o estado. Existe também o modo explicit, que só roteia spawns cuja descrição começa com [jev].

O que o JEV decide

O JEV lê o texto da tarefa (até 4000 caracteres) e devolve números: complexidade e confiança, deliberação, e se a tarefa edita arquivos, roda shell, pesquisa na web, consulta docs de biblioteca ou usa navegador.

Quem transforma isso em escolha é a política do plugin:

Complexidade baixa vai para haiku, média para sonnet, alta para opus.
Confiança baixa sobe um nível.
Edição de arquivos recebe um perfil com edição. Senão, o perfil é só de leitura.

As duas skills

O roteamento funciona melhor com tarefas bem cortadas. Por isso o plugin tem duas skills.

/jev-orchestrator:plan <pedido> só escreve arquivos, não executa nada. Ela cria docs/dev/NNN_<DescricaoCurta>/ com:

prompt.md: objetivo, contexto, restrições, critério de pronto, uma tabela de tarefas e as “ondas” de execução (quais tarefas podem rodar em paralelo).
Um arquivo por tarefa (01_..., 02_...): cada uma pequena, com no máximo 3 arquivos e cerca de 60 linhas de diff, com caminhos exatos e um comando de verificação.

Um exemplo do README:

/jev-orchestrator:plan Adicionar a flag --json ao comando export. Arquivos:
src/cli/export.ts e seu teste. A saída padrão não muda. Pronto quando
`npm test` passar e `export --json` imprimir JSON válido.

Adicione docs/dev/ ao .gitignore do seu projeto: o plano é local e não deve ir para o repositório.

A dica do README: peça a uma IA para escrever o pedido completo antes de chamar o plan.

/jev-orchestrator:run 001 lê o plano e dispara um agente por tarefa, onda a onda. Sem número, usa a pasta mais recente. Se uma tarefa falha, as ondas que dependem dela param e você é avisado. As independentes seguem. No fim, ela relata o que foi feito, o que falhou e o que foi pulado. Commit só se você pedir.

Por que o plano importa? Tarefas pequenas e mecânicas são justamente o que o JEV manda para o modelo mais barato, o haiku. A economia vem sobretudo do plano.

E se o JEV falhar?

Chave ausente, timeout, rede fora do ar: o spawn roda mesmo assim, com sonnet e effort medium. O plugin nunca bloqueia o spawn.

Economia e privacidade

O plugin mostra uma status line. Este é o exemplo do README, no estilo plain:

jev ON · haiku·low·t-read · 42k tok $0.08 · vs opus/high ~$0.31 (-74%) — high

Atenção: a economia mostrada é estimativa, não medição, e esse número é só um exemplo do README, não um resultado geral.

As decisões ficam num log local, em ~/.claude/jev-orchestrator/decisions.jsonl. A chave, o prompt completo e os resultados de ferramentas nunca são gravados. Em compensação, o texto da tarefa (até 4000 caracteres), o nome e a descrição do agente são enviados ao endpoint do JEV a cada spawn roteado. Vale saber antes de ligar.

No que estou trabalhando atualmente

Os cortes de modelo e effort ainda não foram calibrados com dados suficientes. Estou usando o plugin no dia a dia, e o log de decisões, para calibrá-los.
A economia é apenas uma estimativa.
A confiança do JEV tende a vir alta mesmo para pedidos vagos.

Se algo aqui for útil, ou você tiver uma sugestão, me chame no LinkedIn. Ou, se preferir, abra um PR em hiyoku/jev-orc que ficarei feliz com a contribuição.

Se cada pessoa que puder colaborar der um pouco do que tem, a gente constrói algo que ajuda todo mundo.