O modelo que não escreve

O Jev não escreve. Ele decide. Você manda um texto e perguntas fechadas, e ele devolve a resposta de cada uma com a probabilidade dela, em menos de meio segundo, por um preço que arredonda para zero.

As três perguntas, e é só isso que ele responde

O resto, em seis linhas

• Onde ele encaixa: em todo lugar onde hoje se queima modelo grande só para receber um rótulo. Triagem, roteamento, classificação, guardrail, ordenar candidato. O modelo caro não some: ele só para de ler o que ia ser jogado fora.
• O que ele não faz: não escreve, não resume, não faz conta, não vê imagem. E não alucina quer dizer apenas que ele nunca inventa uma opção fora da lista; escolher a errada, ele escolhe.
• A regra de ouro: pergunta atômica. Nada de avalie este post. Três perguntas simples (tem gancho? serve para o meu público? já está batido?), e o peso de cada uma numa linha do seu código, não escondido dentro do modelo.
• O portão: use a confiança para decidir se age, não o que faz. Acima do corte, o código age sozinho. Abaixo, chama a pessoa ou o modelo grande. É isso que transforma 84% de acerto em 100% de acerto na metade do trabalho.
• O nome é a tese: vem do paradoxo de Jevons. Baratear a decisão não economiza decisão, faz você tomar mil vezes mais decisões.
• Se for fazer uma coisa só: pegue uma decisão que a sua operação já toma cem vezes por semana, junte cem casos cuja resposta certa você já tem de graça, e meça acerto, custo e tempo contra o que roda hoje.

Jev é um modelo que não escreve. Você manda um texto e uma lista de perguntas fechadas. Ele devolve as respostas, cada uma com a probabilidade dela.

Não conversa, não resume, não explica. Só decide.

Quem fez: Diogo Almeida, ex-OpenAI, um dos autores principais do paper do InstructGPT, o trabalho que virou o ChatGPT. Ele passou 2 anos em silêncio construindo isto. A empresa é a TypeSafe AI, e o lema dela é uma alfinetada.

we're building prod, not god

o lema da TypeSafe: estamos construindo produção, não deus

O antes e depois, no mesmo caso

Este é o modelo mental que faz o resto encaixar. A pergunta é uma só: o fluxo tem humano no meio?

E não é acidente. É o que foi otimizado.

Agente de código é assistência, por mais técnico que pareça. A pergunta de Almeida que prova isso: você confiaria num agente de código sem controle de versão? O controle de versão é o humano no laço. Código é uma linguagem para humanos, não para máquinas.

Três siglas, e só a terceira é nova

O mecanismo: colapso de modo

Aqui está a explicação de uma coisa que todo mundo sente e ninguém sabe nomear: por que a resposta de um LLM quase sempre parece certa, mesmo quando está errada.

Quando o espaço de otimização é difícil demais, o modelo precisa escolher o formato dos próprios erros. Existem dois formatos:

A virada que muda tudo para automação

Yann LeCun tem um argumento famoso de que os LLMs estão condenados: se cada token tem uma chance de errar, uma sequência longa erra exponencialmente.

Na prática não acontece. O motivo é justamente o colapso de modo: o modelo sempre pega a saída segura, então não diverge.

Mas o argumento do LeCun volta a valer quando você encadeia decisões. Uma decisão plausível serve. Dez mil decisões encadeadas, cada uma apoiada na anterior, não sobram.

É por isso que automação de verdade não se resolve com um LLM melhor.

A prova histórica de que a tarefa vale mais que o tamanho

Este é o argumento mais forte do dossiê inteiro, e é histórico, não promessa.

E prompt bem feito no GPT-3 nem chegava perto. Foi o mesmo cara que fez. É o precedente exato do que ele está tentando repetir agora.

A lição que ele tira, contra o bitter lesson do Sutton (que diz que computação importa mais que algoritmo): dado importa mais que computação, e fazer a tarefa certa importa mais que dado.

Em seis anos e meio de LLM, ele conta uma vez e meia em que alguém acertou a tarefa: o RLHF, e meio crédito pro RLVR. É raro, e nunca é óbvio na hora.

De onde vem o nome

Do paradoxo de Jevons: quando um recurso fica mais eficiente, o consumo total dele aumenta em vez de cair.

O nome é a tese. Baratear a decisão não economiza decisão. Faz você tomar mil vezes mais decisões.

São só três. Tudo se constrói em cima delas.

noul, isto é verdade?

Devolve um número de 0 a 1.

choice, qual destas opções?

Devolve a escolhida, a probabilidade de cada uma, e uma confiança.

score, que nota nesta escala?

Você descreve cada degrau. Devolve a nota, que pode cair entre dois degraus, e a confiança.

O contrato, em miúdos

Vale saber antes da primeira chamada. Cada pergunta leva type, instructions e, quando cabe, criteria.

O score não devolve o degrau, devolve o valor esperado. Com três degraus a escala vai de 0 a 2, e 0,3 quer dizer perto do primeiro, puxando pro segundo. A legend que vem junto é o mapa de índice para rótulo.

A confidence mede a concentração da distribuição, não a chance universal de a resposta estar certa.

É o erro número um de quem vem de LLM. Não pergunte avalie este post.

Por que isso importa no dia a dia: quando a prioridade muda, as notas cruas continuam valendo. Você não gasta chamada nenhuma pra mudar de ideia.

Todas as perguntas vão numa chamada só. São avaliadas em paralelo contra o mesmo texto e não enxergam umas às outras. Acrescentar pergunta quase não muda o tempo.

A regra atômica é o começo. Isto aqui é o resto, e sai todo da documentação deles. É a parte mais acionável do dossiê: dá pra aplicar hoje.

Mande todas as perguntas numa chamada só. É o maior ganho que existe.

Eles mediram, num artigo de 53.777 caracteres com 13 perguntas (8 noul, 2 choice, 3 score):

É esse terceiro número que fecha o argumento: juntar não custa acurácia. O texto entra uma vez só, e as perguntas rodam em paralelo contra ele. Mandar 13 perguntas separadas é pagar o texto 13 vezes.

A única regra: só junte perguntas independentes. Se a segunda depende da resposta da primeira, aí são duas chamadas mesmo.

Mande perguntas especulativas, elas saem de graça

Como acrescentar pergunta quase não muda o tempo, mande também as que só importam num ramo. Exemplo deles: num ticket, pergunte a categoria e, junto, a gravidade do bug e se houve pedido de reembolso. Se a categoria vier pedido de funcionalidade, seu código simplesmente ignora as outras duas.

A árvore de decisão inteira sai de uma chamada. O roteamento vive no if do seu código, não na pergunta.

O texto vai como objeto, não como string

A recomendação é explícita: use objeto JSON com campos nomeados na maioria dos casos. String só quando é um texto único e simples. E aponte a pergunta pro campo exato, com crase:

Junte no mesmo texto o que a decisão precisa comparar (o ticket, o pedido e a política de reembolso juntos). Mas mande só o que a pergunta precisa: a acurácia cai quando entra coisa que não interessa.

Como escrever as opções de um choice

• Use os mesmos campos em todas as opções. Em vez de um parágrafo solto por opção, dê a cada uma a mesma estrutura: o que é, o que não é, exemplos.
• O o que não é é o que afia a fronteira. É ele que separa sósia de sósia.
• Taxonomia profunda: uma pergunta por nível, com as opções sendo os filhos daquele nó. As probabilidades dizem se vale explorar dois ramos.

O limite de opções, e onde a casa cai nele

Acima disso, divida em blocos, rankeie cada bloco, e rode uma segunda passada sobre os vencedores. Para calibrar, com os três catálogos que aparecem neste dossiê:

Confiança não é a probabilidade do primeiro colocado

Parece a mesma coisa e não é. A confiança separa estas duas situações, a probabilidade do vencedor não.

O truque de responder mais grosso quando não sabe

Este é esperto e quase ninguém faz. Em vez de errar fino ou calar, responda no nível de cima da sua taxonomia.

Eles classificaram 60 relatórios anuais em 75 grupos de indústria:

Não precisa de chamada nova. O rótulo largo se deriva do estreito, no seu código.

As faixas de revisão que eles publicam

Para choice, o corte que eles usaram foi probabilidade do primeiro acima de 0,60. O efeito medido: a concordância de rótulo sobe de 90,8% para 99,2%, e o sistema ainda age sozinho em 74,2% dos casos.

Os números são ilustrativos. O certo é plotar confiança contra acerto nos seus dados.

Duas regras curtas pra fechar

• Escreva toda pergunta de forma que sim seja a coisa checada. Se metade das suas perguntas responde sim para o bom e a outra metade responde sim para o ruim, você não consegue comparar as linhas entre si. Padronize o sentido.
• Fixe a versão do modelo. jev-latest é apelido, e apelido anda. Se você calibrou um corte de confiança, fixe jev-1.13.0.

Isto é o que separa brinquedo de produção.

Toda resposta de choice e de score vem com uma confiança de 0 a 1. Ela mede o quanto a probabilidade está concentrada numa opção só.

Use a confiança pra decidir se age, não o que faz:

Onde você põe os cortes depende do estrago que o erro causa. Ler errado é recuperável. Apagar errado não é.

A outra metade dos pedidos sobe pro modelo caro, como sempre subiu.

O que permite calibrar um corte e confiar nele semana que vem

Medindo a mesma pergunta 15 vezes, o desvio padrão do Jev ficou em 0,0102, abaixo de todas as condições de LLM testadas, com latência média de 111ms contra 1,1 a 13,9 segundos.

Ele não é só mais barato: ele repete a mesma resposta. Um corte calibrado hoje continua valendo depois.

A métrica que quase toda avaliação de portão esquece

Contar acerto médio esconde justamente o erro que o portão existe para evitar. O que falta é contar separadamente as vezes em que o sistema agiu quando devia ter se abstido.

Não é invenção minha: é assim que a trycua avalia os modelinhos de decisão dela, com seis colunas separadas (acurácia, abstenção, cobertura, ação errada, alvo errado, e ação tomada quando o esperado era abster). Se você vai ligar um portão, meça essas duas últimas desde o primeiro dia.

Este é o desenho que resume o uso inteiro, e não é meu: é o do Nate Herk.

O modelo caro nunca some. Ele só para de ler o que ia ser descartado.

Quando puxar cada um

Aqui está o encaixe mais direto com o que a casa faz, e o único onde já existe número de terceiro.

Os três harnesses têm o mesmo problema

É o mesmo desenho nos três: joga o catálogo inteiro no prompt e pede pro modelo grande escolher lendo a lista. Não existe etapa de roteamento dedicada em nenhum deles.

O custo foi medido, no Hermes

A TypeSafe rodou o experimento no catálogo real do Hermes: 182 skills, 488 pedidos de teste. Dos 488, 315 tinham exatamente uma skill certa e 173 não tinham nenhuma, de propósito, pra punir chute.

Duas taxas de erro, as duas quanto menor melhor:

Um detalhe que diz muito: das 36 primeiras escolhas erradas do agente sozinho, 10 foram dentro da categoria certa. Ele já olha no lugar certo. O difícil é separar sósias.

Como eles fizeram, em duas chamadas

1. Peneirar o catálogo inteiro. Um choice sobre as 182 skills, usando como critério a mesma descrição curta que o agente já vê. Junto, três noul perguntando de ângulos diferentes se o usuário quer uma AÇÃO e não uma explicação. Se a média das três ficar abaixo de 0,30, não sugere nada e fica quieto.
2. Reavaliar só os 3 primeiros. O mesmo choice, agora com a descrição completa mais os primeiros 700 caracteres do arquivo da skill. Mais um noul por candidato: esta skill faz exatamente a coisa pedida?. Se o maior ficar abaixo de 0,30, descarta a lista toda.

Dois detalhes de projeto que valem roubar

A sugestão entra em uma linha, DEPOIS do catálogo, nunca dentro dele. Mexer no meio do catálogo quebraria o cache de prefixo e deixaria cada turno mais caro.

A frase diz explicitamente ignore isto se não servir. Eles testaram: pressionar mais aumenta a obediência às sugestões erradas também. E uma sugestão errada e confiante é pior que nenhuma sugestão.

O que eu medi na Lain

Mesmo desenho, catálogo da casa: 56 entries, 116 pedidos de teste. A verdade não foi escrita por mim: são os exemplos que o Biel escreveu ao cadastrar cada entry.

O desenho pra Lain

Jev na frente, modelo da sessão atrás. O Jev rankeia as 56 entries e responde em 0,3s. Acima do corte, a sessão já começa sabendo a entry. Abaixo do corte, o modelo grande decide como sempre fez.

Três ganhos de uma vez:

1. O índice sai da janela de todo turno, e vira uma chamada de uma fração de centavo.
2. A decisão cai pra 0,3s, contra um turno inteiro de modelo caro.
3. A regra da casa vira código. Hoje duas entries plausíveis viram uma pergunta é um julgamento. Com as probabilidades na mão, vira um número: se a segunda colocada está perto da primeira, pergunta.

E o 93,1% de acerto no top 2 diz que essa pergunta de desempate quase sempre contém a resposta certa.

Já existe pacote pronto pros dois harnesses, e o que ele faz de verdade

Em 20/09/2026 saiu um manual em português do Denderson (jev-llm.denderson.com), página única com 20 capítulos, com versão em inglês e em espanhol, e dois pacotes de integração para baixar: Naia Hermes (Hermes 0.19.0, Python) e Naia OpenClaw (OpenClaw 2026.9.5, Node).

O código controla o fluxo. O Jev avalia a decisão semântica. O LLM escreve ou planeja.

a tese do manual, que é a mesma deste dossiê

O que os pacotes fazem, de fato: registram uma ferramenta jev_decide que o agente pode escolher chamar. Nenhum hook automático. O plugin declara a ferramenta, uma skill curta ensina quando usar, e o cliente valida a resposta antes de devolver. Liga com hermes plugins enable naia-jev e openclaw plugins enable naia-jev-openclaw, e desliga com disable.

O que o cliente dele faz e o adapter.mjs daqui não fazia: valida campo por campo antes de aceitar. Confere qual modelo respondeu, confere que as chaves das respostas batem com as das perguntas, que o choice está dentro da lista, que o score cai entre 0 e N-1, e que todo número está entre 0 e 1.

HTTP 200 sozinho não significa decisão utilizável.

a regra do cliente dele, que vale copiar

Teto local dos pacotes, mais apertado que o da API de propósito: 24 KB de entrada, 16 perguntas por chamada, timeout de 2 segundos, sem retry, sem cache, sem log de conteúdo. E a ferramenta é declarada advisory_only: confiança não autoriza ação.

Na instância de Hermes dele o Jev entra em dois momentos, descritos em prosa:

1. Preparação de turno. Uma chamada agrupada avalia intenção, skills elegíveis, família de ferramenta, tamanho da tarefa, persona e necessidade de fonte. A sugestão só entra no contexto quando bate critério local, e não remove ferramenta do catálogo.
2. Observação depois da geração. Resultado de ferramenta vira evidência, sem chamar o Jev a cada ferramenta. Ele é explícito de que isto não é barreira: o texto já pode ter sido transmitido quando a checagem roda.

Ele mesmo desarma a leitura fácil: isso comprova uso e latência naquele experimento, não houve A/B suficiente para atribuir economia, e não se multiplica a média por 15 para estimar atraso sem saber o paralelismo.

O caso do OpenClaw, que é o alerta

Almeida citou o OpenClaw pelo nome como o exemplo do que não fazer: a lição que ele não seguiu foi ter humano no laço.

O OpenClaw é um agente autônomo de código aberto que virou fenômeno (247 mil estrelas no GitHub). Roda dentro do WhatsApp ou do Telegram e tem acesso a e-mail, calendário e mensagem. A equipe de segurança da Cisco testou uma skill de terceiro e encontrou exfiltração de dados e injeção de prompt sem o usuário perceber.

O ponto aqui não é condenar o projeto. É que ele já tem as portas certas, e elas são manuais: dá pra marcar uma skill como o modelo não pode escolher esta sozinho (disable-model-invocation), ou despachar direto pra uma ferramenta sem passar pelo modelo (command-dispatch: tool).

A pergunta que gerou esta seção: dá pra ligar um LLM num vault gigante do Obsidian e usar o Jev pra apontar qual nota tem a informação?

Dá, e é um dos usos que eles documentaram com número. Mas tem uma inversão que precisa ficar clara antes.

O Jev não busca no seu vault. Ele escolhe entre o que você já achou.

a inversão que decide o desenho inteiro

Ele lê 32 mil tokens por chamada. O vault do Biel tem 1.312 notas e 9,1 milhões de caracteres, uns 2,6 milhões de tokens. É quarenta vezes o que cabe. Então alguém precisa peneirar antes.

O desenho em três camadas

• Camada 1, busca rápida. Qualquer método que rode no vault inteiro rápido: busca por palavra, BM25, embedding, ou a busca do próprio Obsidian. Ela não precisa acertar a ordem, precisa só não deixar a nota certa de fora.
• Camada 2, o Jev reordena. Uma pergunta de sim ou não por candidato: esta nota responde a esta pergunta?. A resposta é um número de 0 a 1, e você ordena por ele. As 30 chamadas rodam em paralelo.
• Camada 3, o modelo grande. Ele lê três notas em vez de trinta, e escreve a resposta.

O número, no caso difícil deles

Eles rodaram isso num conjunto de 3.565 trechos de decisão judicial, com 40 perguntas. A busca rápida sozinha punha a resposta certa em primeiro lugar em 5% dos casos. Com o Jev reordenando:

A limitação que decide tudo

É o mesmo caso do posta isso no Mastodon da seção anterior: quando a coisa certa não está na lista, a segunda passada só pode rejeitar, não inventar.

Duas perguntas extras que valem de graça

Como todas as perguntas vão na mesma chamada, estas saem sem custo real:

Outras que encaixam no mesmo lugar: esta nota está desatualizada?, isto é anotação crua ou conclusão fechada?, isto é sobre o negócio ou sobre a vida pessoal?.

A variante que dispensa índice

Tem um caminho mais direto, e ele vem do experimento com o catálogo do Hermes.

Uma pergunta de escolha aguenta 182 opções confortavelmente. Se você usar só o título mais uma linha de descrição de cada nota, as 1.312 notas do vault cabem em umas três chamadas. Rankeia cada bloco, junta os vencedores, e roda a segunda passada em cima deles.

Dá pra fazer busca semântica no vault sem montar banco de embedding nenhum.

sem índice pra manter, e sem reindexar quando uma nota muda

Onde isso já encosta no que a casa tem

O vault já é operado pela casa: tem CLI do Obsidian, skills de busca e de leitura, e as bases que agregam por pasta. A peneira da camada 1 já existe. O que falta é a camada 2, e ela é uma chamada.

A terceira aplicação estrutural, ao lado do roteamento e do segundo cérebro. Apareceu no X em 19/09/2026, com Elvis Saravia, e ataca o problema mais caro de agente longo: o agente dizer que terminou quando não terminou.

O que ele fez

Saravia mantém um harness próprio, com uma funcionalidade de /goal: você declara o objetivo e o agente trabalha até cumprir. O problema conhecido desse desenho é que quem decide que o objetivo foi cumprido é o próprio agente.

Ele pôs um verificador de Jev nesse lugar. Depois de cada turno, uma checagem: o objetivo está cumprido? Antes isso era feito por um modelo de raciocínio caro, e por isso rodava pouco. A frase dele: a verificação contínua ficou barata o bastante pra escalar, e por isso dá pra rodar mais verificadores, com mais frequência, pra manter o agente na linha.

System One models are perfect for verification.

Elvis Saravia, no X, em 19/09/2026

Ele chama isso de escalar o harness combinando System One e System Two de forma esperta, aposta que destrava uma leva nova de métodos de test-time compute, e resume o conjunto como um destravamento insano para agente de horizonte longo.

Onde enfiar a checagem: no terminei, ou a cada passo

Perguntaram exatamente isso na thread, e a resposta é honesta:

• hoje ele checa quando o agente afirma que terminou. É o uso seguro.
• checar a cada par de passos é tentador porque é barato, e ele diz que tem curiosidade de testar. Não testou ainda.

As ressalvas dele, que valem tanto quanto a ideia

• Isso é para quem tem harness próprio. Ele mesmo diz que pode não fazer sentido para quem usa o /goal de fábrica do Codex ou do Claude Code, e que vai demonstrar com o Pi porque o harness dele não é público.
• Ele acabou de começar. Os primeiros resultados são bons, e ele ainda precisa achar como medir. Nenhum número foi publicado.
• Ele chama isso do caso de uso mais chato do Jev, de propósito: as demos espalhafatosas e irreais do X nunca chegam em produção, e o que eleva resultado é o uso sem graça.

O desenho pra Lain

A casa já tem o lugar exato, e ele está escrito: as done criteria de cada entry, em .lain/entries/<id>.md. Hoje quem decide se foram cumpridas é o modelo da sessão, no fim do trabalho, lendo o próprio relato. É o juiz julgando a causa dele.

O desenho: quando um despacho volta, um noul por critério de conclusão, com o estado sendo o relatório do subagent mais a lista de arquivos que ele tocou.

• acima do corte, o trabalho está entregue
• abaixo, a Lain reabre aquele critério específico antes de responder ao Biel

Vale para a regra da prova pelo mesmo motivo: implementei X sem evidência que se possa conferir é exatamente o término falso que o verificador pega.

Uma chamada de Jev não é um subagent.

a diferença que decide se isso cabe ou não

Não relê o contexto, não reexplora o projeto, não custa a janela duas vezes. Custa três décimos de segundo e uma fração de centavo. É por isso que cabe no fim de todo despacho, e um verificador de modelo grande não cabe.

O Jev tinha menos de uma semana no ar quando isto foi escrito, e já existiam duas curadorias grandes (as duas de 18/09/2026), dezenas de repositórios públicos e integração em três lugares oficiais. Aqui está o que sobrou da triagem.

O que dá pra instalar hoje

O detalhe do jev-model-router que vale a leitura: ele classifica o modelo principal só no começo da sessão, de propósito, para não quebrar o cache. É a lição da seção 9, aplicada por outra pessoa, sem combinar.

O padrão que se repete em quase todos

Alimente candidatos. Não peça invenção.

o que os quarenta projetos têm em comum

• o agente de browser monta o espaço de ações a partir do DOM a cada passo, e o Jev escolhe o próximo clique
• o buscador traz os trechos como sempre trouxe, e o Jev apaga os que não servem
• o lançador de arquivos rankeia, e o Jev re-rankeia a cada tecla digitada

É a mesma inversão da seção 10, e ela aparece sozinha em projeto de gente que não se conhece. Quando um padrão reaparece assim, ele é da tecnologia, não do autor.

Os números que saíram junto

Todos de terceiros, nenhum medido aqui, nenhum com metodologia publicada.

O linter de prosa é o que mais interessa aqui: é a mecânica da ideia 6 (soa como você ou como IA), rodada por outra pessoa, e com o falso positivo medido, que é a parte que costuma faltar.

Nenhum número aqui aparece sem dizer de onde veio.

A calibragem honesta das manchetes de velocidade

A melhor formulação que li é de Manish Choudhary, depois de ele ler mais de dez artigos e cinco horas de vídeo. Os três números são todos verdadeiros, e o que muda é o que está sendo medido:

É essa a régua para ler tanto o 20 a 200x do anúncio quanto o 250x que circulou nos grupos. E o 193,6x que a Vercel repete no changelog dela vem das avaliações da própria TypeSafe contra um modelo de meio de tabela, não contra um de fronteira.

Medidos por terceiros

O único benchmark independente de verdade, do Greg Pstrucha, num pipeline de segurança que ele já rodava em produção:

Outros, de terceiros

• 1.000 e-mails, 7 classificações cada: 6 segundos e 9 centavos. O mesmo com GPT 5.6 Luna: 5 minutos e 62 centavos. (Nate Herk)
• 20.000 requisições por 85 centavos. (Nate Herk)
• 1.700 e-mails com 4 saídas cada: 18 centavos. (Ryan Vogle)
• Custo mensal a 10 mil decisões por dia: Jev US$ 10, GPT-5.6 Luna US$ 55, GPT-5.6 Sol US$ 1.080, GPT-6 Astra US$ 2.700. (painel do Nate Herk)
• Medidos pelo Denderson, no manual dele, cada um com a ressalva escrita por ele: no caso real do Hermes, 15 chamadas numa tarefa de construção de site, média de 908ms, sem A/B suficiente para atribuir economia; e duas chamadas reais feitas na edição do próprio manual, 778ms com 709 tokens de entrada e 917ms com 546 tokens, a primeira com confiança 0,84. A conta de 37,5% de economia que aparece no manual é declaradamente simulada, não medida.

Medidos por mim, no workspace

Esta seção evita a maior parte da frustração.

• Não escreve nada. Nem uma palavra. Precisa de texto? O Jev decide e outro modelo escreve.
• Não resume, não acha tema, não faz análise aberta. Ele não olha 1.000 transcrições e diz o que está errado nas suas calls. Ele responde 1.000 vezes a pergunta que você escreveu, e você lê o resultado e tira o tema.
• Não extrai valor, escolhe entre valores. Ache os candidatos com código ou com outro modelo, e deixe o Jev escolher qual é o certo.
• Não conta, não faz conta, não compara data. Aritmética fica no código. Pra data: extraia as partes (mês, dia e ano são conjuntos pequenos e fechados) e monte a data você.
• 64k de contexto, contra o milhão dos modelos grandes. Filtre antes de mandar: a acurácia cai quando o texto vem cheio de coisa que não interessa à pergunta.
• Ele é literal. Responde a pergunta que você escreveu, não a que você quis dizer.
• Não vê imagem nem áudio. Só texto.

Quando você olha uma resposta errada e se pega explicando o que queria dizer, essa explicação é a metade que faltava na pergunta.

a regra deles, que eu confirmei na prática

O que eles mesmos admitem

Esta é a parte que me fez confiar mais neles, não menos. As ressalvas abaixo estão escritas pela própria TypeSafe, no blog de lançamento.

Some a isso o que vem na crítica, mais abaixo: não existe paper, nem arquitetura publicada, nem avaliação de terceiro em conjunto padrão.

E tem uma cláusula no contrato que você precisa saber que existe

O contrato deles (o MCA, atualizado em 27/08/2026) proíbe o cliente de publicar benchmarks ou informação de desempenho sobre os Serviços.

Isso foi notado publicamente no X nos primeiros dias. Uma conta respondeu a um resultado publicado dizendo que quem publicou já tinha violado os termos de uso. Outra apontou que a cláusula derruba boa parte do uso acadêmico.

Uso interno e decisão sua não têm problema nenhum. Publicar comparativo de desempenho com o nome deles é o que a cláusula alcança.

o que dá pra dizer com segurança, lendo o contrato

Se for virar conteúdo, vale ler a cláusula antes. O caminho seguro é ensinar o padrão (o funil, o portão de confiança) em vez de publicar a tabela de quem é quantas vezes mais caro.

O que muda de verdade

Não é capacidade. É preço e latência.

Um LLM sempre conseguiu classificar e-mail. O que ele nunca conseguiu foi classificar todos os seus e-mails, todo dia, por centavos, em segundos.

Isso muda a pergunta que você pode fazer aos seus dados. Em vez de amostrar, você passa o corpus inteiro.

Jev é só um comando de decisão muito inteligente. Como se os classificadores de 2016 tivessem ganhado a inteligência de 2026.

Nathan Flurry, no X

Tem uma segunda, mais curta, que virou a mais repetida: um if de IA.

E tem a admissão do próprio autor. Quando um comentarista do Hacker News escreveu que aquilo é fundamentalmente um modelo de classificação e não um LLM, Almeida concordou, preferindo chamar de zero-shot em vez de instruction-tuned. Quem vende não está fingindo que é outra coisa.

E o principal: ele não substitui o GPT nem o Claude.

O tamanho do barulho

• O post de lançamento passou de 600 mil visualizações.
• O conteúdo de maior alcance não é da TypeSafe: é o artigo Building a Harness with Jev, da LangChain, com 1,5 milhão de visualizações. O ângulo é exatamente o da seção 9 deste dossiê.
• A Vercel publicou que é o modelo de adoção mais rápida da história do AI Gateway: em 24 horas, quase 13% dos times pagantes usando, o dobro da família GPT-5.6.

A crítica, que é justa

Já tem alternativa aberta, e em dias

• Laya, aberto, no Hugging Face, com quem publicou afirmando que já passou o Jev em velocidade.
• SimpleJev.ai, de Eugene Cheah: biblioteca aberta que pega qualquer modelo do Hugging Face e transforma num Jev, com endpoint de API, rodando em produção.
• Nimble, da Bespoke Labs, no GitHub. E vários outros: NanoJev, Kev, Jever, OpenJev.
• CUA-S1, da trycua, que é um dado diferente dos outros. Não é clone de Jev: é a mesma aposta noutro domínio. São modelos pequenos que decidem sobre elementos de interface (que valor vai no campo, clicar ou deixar quieto) em vez de texto, e eles usam a expressão System 1 pelo mesmo motivo, dizendo explicitamente que é analogia de engenharia para decisão rápida e limitada, não classificação de arquitetura. Código MIT, pesos abertos no Hugging Face, sem alegação de desempenho. Não existe relação nenhuma com a TypeSafe, nem citação nem parceria: procurei, e o nome deles não aparece uma vez. É por isso que serve de segundo dado. A categoria está nascendo em mais de um lugar ao mesmo tempo, e a versão aberta dela é inspecionável, coisa que o Jev fechado não é.

O que isso significa pra você: o formato provavelmente vira commodity. O que não vira commodity é saber quais decisões da sua operação são decisões fechadas, e ter o conjunto de teste que prova a troca.

Construa em cima do contrato, não em cima do fornecedor.

o adapter.mjs daqui já provou: trocar o motor por trás do mesmo contrato é mudar uma linha

Três caminhos, do mais direto ao mais indireto.

1. API direta. POST https://api.typesafe.ai/v1/systemone, com a chave no cabeçalho e um corpo com state, model e questions. É o que roda aqui.
2. SDK de Python ou de JavaScript, que já repete sozinho quando bate no limite.
3. Pelos intermediários. OpenRouter, Vercel AI Gateway e Zapier já expõem o Jev, então dá pra usar sem conta na TypeSafe. No Gateway o id é typesafe-ai/jev, e ele não funciona pelos endpoints compatíveis com OpenAI: precisa da API de evaluation do AI SDK. Entraram também o Cloudflare Workers AI (como typesafe/jev) e o LiteLLM, que passou a suportar o endpoint deles com contagem de custo (esta via veio de resumo de IA, não de fonte primária: confira antes de contar com ela).

Onde aprender: docs.typesafe.ai/llms.txt é o índice, e qualquer página vira markdown puro botando .md no fim da URL. O console tem um Playground com três casos prontos e mostra a latência real de cada chamada.

Duas coisas do console que valem copiar

• Mande o texto como objeto JSON com campos nomeados e aponte pro campo na pergunta com crase: `user_message`. É como o exemplo pronto deles faz, e é melhor que mandar texto cru.
• jev-latest é apelido e hoje aponta pro jev-1.13.0. Se você calibrar um corte de confiança, fixe a versão, porque o apelido anda.

Ligar em produção sem quebrar o que já funciona

Três regras do manual do Denderson, que são de operação e não de modelo:

1. Rollout em três estágios. Primeiro observação (registra a decisão e não muda nada), depois consultivo (a decisão vira sugestão reversível), e só então seleção automática, quando a comparação sustentar. Intervenção sensível começa em observação, sempre.
2. A chave de cache não é o texto. Ela precisa levar junto o tenant, a versão do modelo, a versão das perguntas, o estado normalizado e a evidência. Mesmo texto vindo de outra conta não é o mesmo evento, e decisão de autorização não se reaproveita nunca.
3. Fallback em cinco casos: timeout, 429, 5xx, JSON inválido e confiança baixa. Todos caem no fluxo que existia antes. Retry cego é desaconselhado, e falha em sequência deve abrir o circuito.

Você processa dado que não é seu: paciente de clínica, lead, extrato bancário. Então isto não é detalhe.

O que está escrito, e onde diverge

Treinar nos seus dados. A política de privacidade é categórica: não treinam nem ajustam modelo com o que você manda. Mas o contrato diz outra coisa em dois pontos. Ele proíbe incluir dado do cliente em treino sem o consentimento prévio do cliente (ou seja, com consentimento, pode). E trata telemetria (logs, estatísticas, classificações e aprendizados ligados ao uso) como coisa que eles podem processar sem restrição, inclusive pra melhorar o produto. Telemetria é derivada do seu dado e fica fora da promessa.

• Retenção: não existe prazo publicado. Nenhum documento diz por quantos dias guardam. O contrato vai na direção oposta: diz que eles não têm obrigação de guardar e podem apagar quando quiserem.
• Zero data retention existe, em uma linha, e só pra enterprise. Pede-se por e-mail.
• O DPA é público e vale pra todo cliente, porque o contrato o incorpora. Ele traz aviso de incidente em até 72 horas, auditoria uma vez por ano às custas do cliente, e transferência internacional coberta por cláusulas padrão da União Europeia.

As três coisas que eu destacaria pra você

2. Não existe menção a LGPD nem à ANPD, e o serviço é hospedado nos Estados Unidos. A base legal do dado que você manda é responsabilidade sua: o contrato diz expressamente que o cliente declara ter obtido os consentimentos necessários.

3. O teto de responsabilidade deles é o maior entre o que você pagou nos últimos 12 meses e US$ 50. Com o preço deles, na prática:

Detalhe comercial: os créditos comprados expiram, no fim do contrato ou 12 meses depois da compra, o que vier primeiro.

O gargalo não é acesso ao modelo. Qualquer um tem em 5 minutos.

O gargalo é saber quais decisões da sua operação são decisões fechadas, e ter o conjunto de teste que prova que a troca funcionou.

1. Liste as decisões, não as tarefas. Onde hoje um modelo caro é chamado só pra devolver um rótulo, uma nota, ou um sim ou não. Aqui na casa eu já listei 29 desses lugares.
2. Ache a verdade que já existe de graça. A sua planilha de categorias. O que você já respondeu na mão mês passado. O que você já escolheu publicar. Sem isso, você não tem como saber se melhorou.
3. Meça antes de ligar. Cem casos, os dois modelos, três colunas: acerto, custo, tempo. Foi o que separou aqui isto vale ligar hoje de isto não tem solução.
4. As contas, escritas. Tokens evitados são os do baseline menos os do modelo principal com o Jev; a economia é isso dividido pelo baseline; o custo total novo é o modelo principal mais o Jev mais infraestrutura; o acerto é decisões certas sobre decisões avaliadas; e a cobertura automática é decisões aplicadas sem fallback sobre eventos elegíveis. Três armadilhas: compare p50 e p95, não a média; token economizado não vira dólar quando o modelo caro é assinatura e não API; e não mude duas coisas de uma vez, como baixar o nível de raciocínio do modelo junto e creditar a diferença ao Jev.
5. Use a confiança como portão desde o primeiro dia. A parte de cima roda sozinha, a parte de baixo continua com você. É o que transforma 84% de acerto em 100% de acerto na metade do trabalho.

A oportunidade comercial

Aparece em dois dos vídeos e encaixa direto no que você vende: a maior parte das automações que os seus alunos e clientes montam hoje queima modelo grande numa etapa de triagem.

Trocar essa etapa é um ganho de custo mensurável e fácil de mostrar numa call, porque a prova é uma coluna de centavos.

Cada uma diz o que a casa faz hoje e o que muda. As marcadas foram rodadas de verdade; as outras não, e estão aqui como lista de candidatas.

• provado que funciona, com número
• provado que NÃO funciona