Seu agente de código está pagando preços de modelo frontier para responder questões de múltipla escolha.
Quais notas devo carregar? Esta etapa vai para o modelo grande ou para um menor? A ferramenta acabou de falhar. Tentar de novo, corrigir ou desistir? Quais testes devem rodar primeiro?
Cada uma dessas é uma pergunta com quatro ou cinco respostas possíveis. E na maioria das configurações de agentes atuais, todas elas são respondidas pelo modelo mais caro que você tem, com o modo thinking ativado, lendo todo o contexto e escrevendo um parágrafo antes de tomar uma decisão.
Esse é o vazamento.
Este artigo mostra como estancá-lo. O Opus 5.5 fica com o raciocínio pesado: planejamento, escrita de código, debugging. O Jev assume as quatro decisões que acontecem em quase todas as etapas. Seu harness prepara as opções, verifica as respostas e dá a palavra final.
No exemplo prático abaixo, uma sessão de desenvolvimento de feature cai de US$ 6,42 para US$ 2,00. Isso é 69% mais barato, e cada linha da conta está neste artigo para que você possa conferir com os seus próprios números.
Isso foi escrito para qualquer pessoa que roda um agente de código em trabalho real: Claude Code, seu próprio harness na API ou qualquer coisa no meio do caminho. Você não precisa reescrever seu agente. Cada peça deste artigo se encaixa em um loop existente como uma chamada de função com uma flag para desativá-la. Se você leu meu artigo sobre Jev + Claude Code, esta é a versão atualizada: mesma ideia, um modelo de raciocínio mais recente e quatro decisões específicas em vez de um princípio geral.
Você vai precisar de uma chave de API do Jev, uma chave de API da Anthropic e de cerca de uma semana de logs do seu próprio agente para usar como base de comparação.
Vamos construir isso.
opus raciocina jev decide.
O Problema: Um Modelo Fazendo Dois Trabalhos
Observe um agente de código trabalhar por dez minutos e você o verá fazendo dois tipos de trabalho bem diferentes.
O primeiro trabalho é raciocinar. Planejar uma feature. Escrever uma função. Ler um stack trace e descobrir por que o parser de datas quebra em anos bissextos. Esse trabalho é aberto. A resposta não está em uma lista. Aqui você quer o modelo mais inteligente que puder pagar, e o Opus 5.5 é muito bom nisso.
O segundo trabalho é decidir. Escolher as três notas de projeto que importam entre quarenta. Decidir que um rename pode ir para um modelo barato. Escolher o que fazer depois que o npm test atinge o timeout. Definir quais 12 arquivos de teste rodar antes dos 1.400 completos. Essas respostas estão em uma lista. A lista é curta. E seu código pode agir diretamente com base na resposta.
A maioria dos agentes executa os dois trabalhos no mesmo modelo, porque esse é o padrão. O loop chama o Opus, o Opus pensa, o Opus responde, o loop continua.
Funciona. Mas também é lento e caro de um jeito fácil de passar despercebido, porque as chamadas de decisão não parecem caras individualmente. Uma única chamada de "quais notas eu preciso" custa talvez um centavo. Mas ela acontece em cada etapa e carrega o contexto inteiro consigo todas as vezes.
E há um segundo custo ainda mais fácil de ignorar: quando o agente não consegue decidir o que carregar, ele carrega tudo. Cada nota de projeto, cada documento de convenção, cada decisão passada, tudo entulhado em cada chamada. O Opus 5.5 barateou as leituras de cache para US$ 0,20 por milhão de tokens, mas "barato vezes sessenta etapas vezes toda a sua pasta de notas" ainda soma bastante.
A Solução: Opus Raciocina, Jev Decide, Seu Harness Manda
O Jev é o modelo da TypeSafe criado exatamente para o segundo trabalho. Ele não escreve texto. Você fornece contexto e perguntas tipadas com um conjunto fixo de opções, e ele devolve uma probabilidade para cada opção. Responde em milissegundos, o input custa US$ 0,042 por milhão de tokens e o output é gratuito.
Isso torna a arquitetura simples de descrever:
O Opus 5.5 faz o raciocínio. Planejamento, código, debugging, qualquer coisa em que a resposta não esteja em uma lista.
O Jev toma as pequenas decisões. Ele escolhe entre as opções que seu harness preparou.
Seu harness continua no comando. Ele monta as listas de opções, lê as probabilidades, aplica limites (thresholds) e recorre ao Opus quando o Jev não tem certeza.
Essa terceira linha é a que as pessoas pulam, e é justamente a que torna tudo seguro. O Jev nunca inventa uma opção. O Jev nunca tem a palavra final sobre algo que você não possa desfazer. É o seu código que decide o que significa "certeza suficiente".
Aqui está a função auxiliar na qual todo o resto deste artigo se baseia:
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Conecte isso ao seu cliente Jev: o SDK da TypeSafe, o Vercel AI Gateway,
ou o pacote LangChain. Precisa retornar {option: probability}
para cada opção que você passou.
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
Repare no que não está ali: nenhuma pergunta pedindo ao Jev para dizer qual é seu nível de confiança. Você lê a probabilidade que ele retorna. Perguntar a qualquer modelo "você tem certeza?" gera um "sim" quase sempre. A probabilidade é o sinal honesto.
Agora, as quatro decisões.
As quatro decisões dentro da etapa do agente
Decisão 1: Escolha as Notas de Projeto Relevantes Antes de Carregar o Contexto
Esta é a maior alavanca isolada, e é aquela que quase ninguém implementou.
Seu agente tem uma pasta de notas. Um AGENTS.md, documentos de arquitetura, convenções, decisões passadas, avisos de "nunca mexa no módulo de billing sem uma migration". Talvez uns 30.000 tokens disso. A maioria dos agentes carrega tudo em cada chamada, porque ninguém quer ser a pessoa que deixou de fora a nota importante.
Então, em vez de carregar tudo, você faz uma pergunta simples ao Jev sobre cada nota, tudo em paralelo: o agente precisa desta nota para esta tarefa?
Primeiro, divida suas notas em blocos por título. Cada seção do AGENTS.md vira seu próprio bloco. Cada documento de arquitetura vira um ou mais blocos.
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
Depois, pontue cada bloco em relação à tarefa atual:
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Would an engineer need this note to do the task correctly?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
Três detalhes importam aqui.
Sempre carregue o que é inegociável. Algumas notas devem estar em cada chamada independentemente de qualquer coisa: regras de segurança, "nunca faça force push", aquela linha que diz qual banco de dados é o de produção. Marque essas como always e pule a pontuação delas.
Mantenha um piso e um fallback. Se nada ultrapassar 0,55, você ainda carrega as duas primeiras. Um agente com zero de contexto é pior do que um com contexto ligeiramente excessivo.
Registre o que foi descartado. Quando o agente cometer um erro, a primeira coisa a verificar é se a nota que teria evitado aquilo foi cortada pela pontuação. Esse log é o que permite ajustar keep e floor.
No exemplo prático, essa única mudança reduz a parte de notas de cada chamada de 30.000 para 6.000 tokens. Sozinha, ela corta o custo da sessão em cerca de 24%.
Decisão 2: Direcione Tarefas Adequadas para um Worker Mais Rápido
Nem toda etapa precisa do Opus.
Renomear uma função em oito arquivos não precisa. Adicionar um campo a um formulário que já tem nove campos idênticos não precisa. Atualizar um caminho de import não precisa. São edições que seguem um padrão que já existe na codebase.
Por isso, antes de cada etapa rodar, o Jev classifica a etapa, e seu harness mapeia a classe para um worker:
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="What kind of work is this step?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
Veja como as opções foram escritas. Não são "fácil" e "difícil", e definitivamente não são "um modelo pequeno dá conta disso?". São tipos concretos de trabalho que seu código consegue mapear para uma ação. Essa é a regra para toda pergunta ao Jev: cada opção precisa ser algo que seu harness saiba como executar.
E repare no padrão. Abaixo de 0,8, a etapa vai para o Opus. Erros de roteamento aqui só vão em uma direção: uma tarefa difícil enviada ao worker rápido custa uma etapa falha e uma nova tentativa, enquanto uma tarefa fácil enviada ao Opus custa apenas um pouco mais. Então, na dúvida, mande para cima.
Para o worker rápido, uso o Haiku 4.5 a US$ 1 por milhão de tokens de input e US$ 5 por milhão de output. No exemplo prático, 12 das 36 etapas de trabalho real vão para ele.
Decisão 3: Escolha um Caminho de Recuperação Quando uma Ferramenta Falhar
Ferramentas falham o tempo todo. Testes atingem timeout. Um caminho de arquivo está errado. Um pacote não está instalado. Um comando shell esbarra em um erro de permissão. Um linter reclama de algo sem relação.
A maioria dos agentes lida com isso da forma mais cara possível: devolvem o erro inteiro para o modelo grande e deixam que ele pense no que fazer. Às vezes isso é o certo. Muitas vezes a resposta é óbvia, e o Opus gasta 1.500 tokens redescobrindo que ENOENT significa que o arquivo não está lá.
Pior: os agentes ficam presos em loops. Tenta, falha, tenta, falha, pagando por uma etapa completa de raciocínio a cada vez.
Então você entrega a falha ao Jev com um conjunto fixo de caminhos de recuperação:
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # últimos n caracteres do erro
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="What is the best next move after this failure?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # rede instável ou timeout3 "retry_after_install", # pacote ou ferramenta ausente4 "fix_path_and_retry", # caminho de arquivo ou cwd errado5 "switch_tool", # esta ferramenta não consegue, outra sim6 "escalate_to_opus", # precisa de debugging real7 "stop_and_report", # precisa de um humano8]
O limite rígido de tentativas vive no código, não no modelo. Nenhum modelo, por mais barato que seja, deve ter permissão para tentar infinitamente.
Cada caminho de recuperação mapeia para uma pequena função no seu harness. retry_after_install extrai o pacote ausente do erro com uma regex e o instala. fix_path_and_retry verifica os caminhos existentes e sugere a correspondência mais próxima. Apenas escalate_to_opus gasta dinheiro de verdade, e só dispara quando a falha realmente exige raciocínio.
No exemplo prático, isso elimina 6 etapas de retentativa desperdiçadas da sessão.
Decisão 4: Rode Verificações Focadas Antes da Suíte Completa de Testes
Esta economiza mais tempo do que dinheiro, e tempo é o que faz um agente parecer rápido.
Após cada alteração, a maioria dos agentes roda a suíte inteira de testes. Se sua suíte leva quatro minutos, seu agente passa quatro minutos esperando após cada edição, e depois lê centenas de linhas de output procurando a única falha que importa.
A solução segue o mesmo padrão das notas: pontue cada arquivo de teste em relação ao diff, rode os mais relevantes primeiro e só execute a suíte completa quando as verificações focadas passarem.
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Could this change break tests in this file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # falhe rápido, corrija antes de qualquer outra coisa18 return run_tests(test_files) # a suíte completa ainda bloqueia o commit
Leia essa última linha duas vezes. A suíte completa ainda roda antes de qualquer coisa ser commitada. As verificações focadas são um alerta precoce, não um substituto. Você detecta a maioria das quebras em segundos em vez de minutos, e nunca entrega algo que a suíte completa teria pego.
Adicione as verificações baratas primeiro também: type check e lint apenas nos arquivos alterados. Levam um segundo e pegam uma parcela surpreendente de erros antes de qualquer teste rodar.
Juntando Tudo: O Loop do Harness
Veja como as quatro decisões se encaixam dentro de uma etapa do loop:
def run_step(task: str, step: str, state):
1. contexto: carrega apenas as notas que esta etapa precisa
notes = state.always_notes + pick_notes(step, state.notes)
2. roteamento: escolhe o worker para esta etapa
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. recuperação: trata quaisquer falhas de ferramentas nesta etapa
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. verificações: testes focados primeiro, suíte completa antes do commit
if result.diff:
state.log_check(check(result.diff, state.test_files))
E aqui está o lado do Opus: é apenas a sua chamada normal ao Opus 5.5. Coloque seu contexto estável primeiro (system prompt, definições de ferramentas, as notas "always") para que permaneça em cache entre as etapas, e deixe o material específico da etapa por último.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # o id do seu modelo Opus 5.5
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
Nada exótico. A economia vem daquilo que você deixa de enviar para ele, não de um prompt genial.
Uma Etapa Rastreada
Veja como uma única etapa aparece no log quando as quatro decisões estão ativas. A tarefa: adicionar rate limiting ao endpoint público de signup. Este trace é ilustrativo, mas é o formato que você verá nos seus próprios logs.
step 14 "add a per IP rate limit to POST /signup"
[notes] pontuou 41 blocos em paralelo
manteve: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
descartou: 37 blocos, incluindo billing, templates de email, CI
[route] new_logic (0.91) → opus
[opus] planeja a mudança, escreve middleware + config + edição do handler
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, roda de novo
[checks] typecheck nos arquivos alterados: passou
testes focados (12 de 1.388): passaram
suíte completa: passou
Leia de cima para baixo e conte quantas dessas linhas costumavam ser uma chamada completa ao Opus. Escolher notas: uma chamada gigante, ou nenhuma escolha e 30.000 tokens de notas carregados às cegas. Roteamento: nada, toda etapa ia para o Opus. O pacote ausente: uma etapa inteira de raciocínio para concluir que um módulo faltando significa "instale o módulo". Escolher testes: nada, a suíte completa em cada edição.
Agora, apenas uma linha desse trace é Opus, e é a linha que realmente precisava de um modelo frontier: planejar e escrever o rate limiter.
Essa é a ideia inteira em uma imagem. O modelo caro gasta seu tempo na parte do trabalho que só ele consegue fazer.
O Exemplo Prático: De Onde Vêm os 69%
Aqui está a conta completa de uma sessão de feature: 60 etapas de agente mais as 6 retentativas desperdiçadas que um agente típico acumula pelo caminho. Todos os preços são os valores públicos de tabela atuais.
Antes: Opus 5.5 faz tudo
Cada etapa carrega 70.000 tokens de contexto: 15.000 para o system prompt e ferramentas, 30.000 para a pasta de notas completa e 25.000 para a conversa até então. Assumo que 80% disso seja cache hit. Cada etapa gera cerca de 1.500 tokens de output, porque o thinking está sempre ligado no Opus 5.5.
cache reads: 56.000 × US$ 0,20/M = US$ 0,0112
fresh input: 14.000 × US$ 4,00/M = US$ 0,0560
output: 1.500 × US$ 20,00/M = US$ 0,0300
por etapa = US$ 0,0972
66 etapas × US$ 0,0972 = US$ 6,42
Depois: a camada de decisão
O contexto cai para 46.000 tokens por etapa, porque o Jev escolhe 6.000 tokens de notas em vez de carregar todos os 30.000. As 24 etapas puramente de decisão migram para o Jev. Os 6 loops de retentativa desaparecem. E 12 das 36 etapas de trabalho restantes vão para o Haiku 4.5.
Opus 5.5: 24 etapas × US$ 0,0742 = US$ 1,78
Haiku 4.5: 12 etapas × US$ 0,0169 = US$ 0,20
Jev: 102 chamadas × 5.000 tokens
× US$ 0,042/M, output grátis = US$ 0,02
total = US$ 2,00
De US$ 6,42 para US$ 2,00. Isso é 68,8% mais barato para a mesma feature.
defina o threshold pelo custo de uma resposta errada
E aqui está quanto cada alavanca contribui, empilhadas em ordem:
só seleção de notas US$ 4,89 23,7% de economia
- decisões movidas pro Jev US$ 3,13 51,2% de economia
- caminhos de recuperação US$ 2,69 58,1% de economia
- roteamento para worker rápido US$ 2,00 68,8% de economia
Duas observações honestas sobre essa conta.
Primeiro, esses são números modelados com base em premissas explícitas, não uma medição do seu stack. Seu tamanho de contexto, taxa de cache hit e quantidade de decisões serão diferentes. O motivo de mostrar cada linha é para que você possa substituir pelos seus próprios números. Depois de medir o seu antes e depois real, use o seu número, não o meu.
Segundo, olhe para onde o dinheiro realmente vai. As 102 chamadas do Jev custam dois centavos no total. A economia não vem do Jev ser barato por chamada. Ela vem de tudo que deixa de acontecer depois que o Jev toma a decisão: contexto inflado, etapas completas de raciocínio para questões de múltipla escolha, loops de retentativa e chamadas ao modelo grande em tarefas de rename.
Por Que Não Usar Só o Haiku para as Decisões?
Pergunta justa. O Haiku 4.5 é barato e rápido. Por que adicionar um modelo novo?
Três motivos.
Ele ainda escreve. O Haiku responde em texto. Você precisa instruí-lo a responder com uma das suas opções, depois parsear a resposta, e então lidar com as vezes em que ele adiciona uma explicação, escolhe algo que não está na lista ou embute a resposta em uma frase. O Jev retorna uma probabilidade para cada opção que você passou. Não há nada para parsear e nada fora da lista.
Você recebe a distribuição completa, não apenas uma resposta. Quando o Jev diz needed: 0.52, not_needed: 0.48, você sabe que é cara ou coroa e seu harness pode escalar. Quando um modelo de texto diz "needed", você não tem ideia se ele estava seguro. Thresholds só funcionam quando você consegue ver as probabilidades.
A conta de custos é diferente. O output do Jev é gratuito e seu input custa US$ 0,042 por milhão de tokens. Pontuar 41 blocos de notas a cada etapa significa 41 chamadas pequenas por etapa. Com o Jev, isso é uma fração de centavo. Com qualquer modelo de texto, mesmo um barato, são 41 gerações com seu próprio custo de output e latência.
Use o Haiku para edições pequenas, onde ele realmente precisa escrever código. Use o Jev para escolher em listas. Use o Opus para pensar. Cada modelo faz o trabalho para o qual foi criado.
Como Implementar Sem Quebrar Nada
Não ative as quatro decisões de uma vez. Esta é a ordem que eu usaria.
Semana 1: shadow mode. Mantenha seu agente atual exatamente como está. Para cada decisão que ele tomar, faça também a mesma pergunta ao Jev e registre ambas as respostas mais a probabilidade do Jev. Não aja com base na resposta do Jev de forma alguma.
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
Semana 2: leia as divergências. Olhe apenas para as linhas em que o Jev e seu agente atual discordaram. Ordene-as pela probabilidade do Jev. Você geralmente encontrará uma linha clara: acima de certa probabilidade, o Jev acerta quase tão frequentemente quanto o Opus. Essa linha é o seu threshold. Essas linhas de divergência também viram seu conjunto de testes, construído de graça a partir do seu tráfego real.
Semana 3: ative a seleção de notas. É a maior alavanca e a mais fácil de desfazer, já que uma nota esquecida aparece rápido nos seus logs.
Semana 4: ative recuperação e testes. Ambos têm limites rígidos e fallbacks no código, então o pior caso é voltar ao que você faz hoje.
Por último: roteamento. Erros de roteamento são os mais visíveis para os usuários, porque uma tarefa difícil enviada ao worker rápido gera código ruim. Ative-o por último, com um threshold conservador, e acompanhe a taxa de falha nas etapas do worker rápido.
Coloque cada decisão atrás de uma flag on/off para que você possa desfazê-la em uma linha.
Definindo Thresholds por Risco
Um único threshold para tudo é um erro. Defina-os com base no que acontece quando a resposta está errada.
Uma sessão de feature, mesmo resultado de US$ 6,42 para US$ 2,00
Risco baixo, fácil de desfazer: 0,55 a 0,65. Escolher notas. Ordenar testes. Uma resposta errada custa um pouco de contexto ou alguns segundos.
Risco médio: 0,8. Roteamento e recuperação. Uma resposta errada custa uma etapa falha, que seu harness detecta.
Risco alto, difícil de desfazer: 0,9 ou nunca. Deletar arquivos. Fazer force push. Mexer em configuração de produção. Rodar uma migration. Meu conselho sincero: não deixe nenhum modelo tomar essas decisões sozinho. Encaminhe-as para um humano ou, no mínimo, para o Opus com uma etapa de confirmação.
Qualquer coisa abaixo do threshold sobe na hierarquia: para o Opus se exigir raciocínio, para um humano se exigir julgamento.
Onde Isso Não Ajuda
Essa arquitetura não é um multiplicador mágico para qualquer carga de trabalho.
Cargas de geração pura quase não mudam. Se seu agente passa a maior parte do tempo escrevendo grandes volumes de código novo a partir de uma especificação clara, não há muitas decisões para mover. Você ainda terá a economia da seleção de notas, mas pouco além disso.
Projetos minúsculos não precisam disso. Se sua pasta de notas inteira tem 2.000 tokens e sua suíte roda em oito segundos, o overhead de montar isso ainda não vale a pena.
O Jev não é ótimo para dar a palavra final sozinho. Ele é excelente em notar coisas e escolher em uma lista curta. Não é o modelo ideal para decidir "este pull request está pronto para merge?" como uma pergunta única. Divida perguntas grandes em pequenas, pontue cada uma e combine os resultados no seu próprio código com os seus próprios pesos.
Se você já tem dados rotulados para uma pergunta fixa, um modelo pequeno hospedado por você pode bater o Jev no preço. O Jev brilha quando as perguntas continuam mudando e você não tem dados de treinamento, o que descreve a maioria dos agentes de código.
Os Erros Que Eu Evitaria
Deixar o modelo escrever a lista de opções. Toda a arquitetura depende de opções nas quais seu código consiga agir. Se um modelo gerar as opções, você volta a parsear texto livre.
Perguntar ao Jev se ele está confiante. Leia a probabilidade em vez disso. Um autorrelato é quase sempre "sim".
Sem fallback. Toda decisão do Jev precisa de um caminho para "não tenho certeza", e esse caminho é o Opus ou um humano, nunca um palpite.
Limites de retentativa no prompt em vez de no código. Um modelo instruído a "tentar apenas 3 vezes" ocasionalmente tentará 30 vezes. Código não.
Descartar a suíte completa de testes. As verificações focadas aceleram você. A suíte completa mantém você honesto. Fique com as duas.
Medir nada. Se você não registrar o custo por sessão antes de começar, nunca vai saber se economizou 20% ou 70%. Primeiro, levante o seu uso durante uma semana de trabalho normal. Leva dez minutos e é o único número que realmente importa.
O que fazer esta semana
Aqui está o processo completo em formato de checklist:
- Registre uma semana de sessões do agente: etapas, tokens, custo e falhas.
- Identifique as decisões escondidas no seu loop: notas, roteamento, recuperação e testes.
- Escreva cada uma delas como uma pergunta com uma lista fixa de opções.
- Rode o Jev em modo sombra (shadow mode) junto com o seu agente atual por uma semana.
- Defina os limites a partir do log de divergências, com base no risco.
- Ative primeiro a seleção de notas, depois a recuperação e os testes e, por fim, o roteamento.
- Compare o custo por sessão antes e depois. Esse é o seu número.
O Opus 5.5 é o melhor modelo de raciocínio que já usei para código. O erro é fazer ele cuidar de todo o resto também.
Deixe o modelo pensar. Deixe o Jev decidir. Deixe o seu código dar as regras.
Se este conteúdo foi útil, siga @cyrilXBT. Toda semana eu destrincho como construir produtos com os modelos de IA mais recentes, sempre com números reais.
Salve este artigo nos favoritos para ter tudo à mão quando for começar a construir.
