Enquanto todo mundo briga pra ver qual LLM escreve melhor, uma startup decidiu que gerar texto é perda de tempo. A TypeSafe AI acabou de lançar o Jev, um modelo que não conversa, não escreve código, não cria poesia. Ele só faz uma coisa: tomar decisões estruturadas. E faz isso 200 vezes mais rápido que o GPT-6 Astra.

O conceito é tão simples que irrita. Você manda um JSON com um estado (um e-mail, um log, um ticket de suporte) e uma lista de perguntas tipadas. O Jev devolve respostas tipadas com probabilidades calibradas. Sem enrolação, sem “como posso te ajudar hoje?”, sem tokens de saída desperdiçados. E por US$ 0,042 por milhão de tokens de entrada, com saída custando literalmente zero.

Parece bom demais? Eu também achei. Vamos destrinchar.

O que são System One Models?

O nome é uma referência ao livro “Thinking, Fast and Slow” do Daniel Kahneman. O “Sistema 1” é o pensamento rápido, intuitivo, automático. O “Sistema 2” é o raciocínio lento, deliberado, analítico. LLMs tradicionais tentam ser o Sistema 2: pensam passo a passo, geram raciocínio em cadeia, e cobram caro por cada token produzido.

A TypeSafe AI aposta que a maioria das decisões em produção não precisa de Sistema 2. Quando seu sistema precisa rotear um ticket de suporte para o departamento certo, classificar um e-mail como spam, ou decidir se um usuário é fraudulento, você não precisa de um modelo gerando parágrafos de explicação. Precisa de uma resposta tipada, rápida e barata.

System One Models são essa categoria. Modelos treinados especificamente para decisões estruturadas, sem capacidade de geração de texto. É como comparar uma calculadora com um notebook: a calculadora não abre o Word, mas resolve a conta na hora.

Quem está por trás?

Diogo Almeida, co-autor do paper InstructGPT (o paper que transformou o GPT-3 no ChatGPT que conhecemos), fundou a TypeSafe AI. Não é um random saindo do acelerador do Y Combinator. É alguém que ajudou a construir o RLHF na OpenAI e decidiu que existe um caminho diferente.

A empresa levantou US$ 40 milhões em seed, o que é bastante agressivo para um modelo que não gera texto. Mas quando você entende os números de performance, começa a fazer sentido.

Como o Jev funciona (de verdade)

Esqueça autoregressive decoding. O Jev não gera tokens sequencialmente. Ele processa tudo em um único forward pass paralelo, devolvendo todas as saídas simultaneamente. Isso é o que permite latências de 70 a 500 milissegundos, contra 3 a 329 segundos de modelos tradicionais.

O modelo trabalha com três primitivos de saída:

Choice

Você define até 255 opções possíveis. O Jev retorna a distribuição de probabilidade entre elas.

{
  "input": "Meu cartão foi cobrado duas vezes",
  "query": {
    "type": "choice",
    "options": ["billing", "technical", "sales"]
  }
}

Resposta:

{
  "result": {
    "billing": 0.85,
    "technical": 0.08,
    "sales": 0.07
  },
  "confidence": 0.82
}

Score

Um valor contínuo em uma escala definida por você. Útil para scoring de risco, relevância, prioridade.

{
  "input": "Usuário não logou há 45 dias, cancelou upgrade ontem",
  "query": {
    "type": "score",
    "scale": [0, 1],
    "label": "churn_risk"
  }
}

Noul

Um “boolean calibrado”, o nome é um portmanteau de “boolean” invertido. Retorna uma probabilidade de sim/não com confiança associada. Perfeito para perguntas binárias como “esse commit introduz uma vulnerabilidade?” ou “esse review é fake?”.

RLCD: O treinamento que ninguém está usando

Aqui fica interessante. Todo mundo conhece RLHF (Reinforcement Learning from Human Feedback), o método que a OpenAI usou no ChatGPT. Modelos de raciocínio usam RLVR (Reinforcement Learning with Verifiable Rewards). O Jev usa algo diferente: RLCD, Reinforcement Learning for Calibrated Decisions.

A diferença é sutil, mas importante. RLHF otimiza para “o humano prefere essa resposta”. RLVR otimiza para “a resposta está matematicamente correta”. RLCD otimiza para calibração: quando o modelo diz que tem 70% de confiança, ele deveria estar certo em aproximadamente 70% dos casos.

Isso muda tudo em produção. Se você está roteando 10 milhões de tickets por dia, não quer um modelo que erra 5% mas diz que tem 99% de certeza. Quer um modelo que, quando diz 70%, acerta 70%. Porque aí você pode definir thresholds reais: acima de 90%, roteia automaticamente; abaixo de 60%, manda para humano; entre 60% e 90%, segunda opinião de outro modelo.

A TypeSafe não publicou o paper completo da arquitetura ainda. Isso incomodou bastante gente no Hacker News, e com razão. Mas os early adopters relatam que a calibração funciona como prometido.

Os números que fizeram o HN pirar

Eu geralmente ignoro benchmarks de startup porque todo mundo cherry-picka os cenários favoráveis. Mas os números do Jev são tão absurdos que vale examinar:

Output custando zero faz sentido quando você entende que o modelo não gera tokens de saída. Ele retorna um struct pré-definido. Não existe decode loop. É como a diferença entre gerar uma imagem pixel por pixel e fazer lookup numa tabela.

Na demo ao vivo, o Jev respondeu em 0,114 segundos enquanto o GPT-5.6 Terra levou 8,566 segundos para a mesma tarefa de classificação. 75x mais rápido no cenário real, não no benchmark de marketing.

O asterisco importante

A TypeSafe criou seus próprios “workflow evals” internos em vez de usar benchmarks públicos. Eles compararam o Jev contra a média das predições do GPT-6 Astra e do Fable 5.1, uma metodologia que a galera do HN questionou bastante. Sem benchmark público padronizado para modelos de decisão estruturada, fica difícil saber exatamente onde o Jev brilha e onde falha.

Pra ser justo: não existe benchmark público para essa categoria porque a categoria não existia até ontem. Mas a ausência de validação externa é um ponto de atenção.

“Nunca alucina”: verdade ou marketing?

A TypeSafe diz que o Jev “não pode alucinar”. Isso é tecnicamente verdade num sentido muito específico: como o modelo só retorna valores de um schema pré-definido, ele nunca vai inventar uma string que não existe nas opções. Se suas opções são [“billing”, “technical”, “sales”], a resposta vai ser uma dessas três. Sempre.

Mas “não alucinar” é diferente de “não errar”. O modelo pode retornar {"billing": 0.95} para um ticket que é claramente técnico. A resposta é válida no schema, mas errada no conteúdo.

O próprio CEO da TypeSafe reconheceu essa distinção na thread do Hacker News. Honestidade refrescante para uma startup de IA.

Onde isso muda o jogo

Pensa nos cenários onde empresas gastam fortunas usando LLMs como classificadores glorificados:

Roteamento de suporte: Milhões de tickets por dia, cada um passando por um GPT que gera “Eu classifiquei esse ticket como técnico porque…” quando tudo que você precisa é {"technical": 0.92}. Com o Jev, essa operação custa centavos.

Guardrails de outros modelos: Usar Jev como camada de verificação rápida antes ou depois de um LLM. “Essa resposta do ChatGPT contém informação sensível?” Em vez de rodar outro LLM para verificar (lento e caro), o Jev responde em 100ms.

Agentes de IA em produção: Quando um agente precisa decidir qual tool usar, qual branch seguir, qual API chamar, ele não precisa de geração de texto. Precisa de uma decisão tipada. O Jev encaixa como uma luva nesse cenário.

NPCs em jogos: A TypeSafe demonstrou o Jev jogando DOOM. Cada frame, o modelo decide que ação tomar (mover, atirar, virar) em tempo real. Tenta fazer isso com um LLM. Vai travar no segundo frame.

Classificação em escala: Imagine taguear 50 milhões de registros. Com um LLM a US$ 2/MTok, a conta explode. Com o Jev a US$ 0,042/MTok e sem custo de output, você processa o dataset inteiro pelo preço de um café.

O que o Jev NÃO faz

E aqui mora o detalhe que separa hype de utilidade real:

• Não gera texto. Nenhum. Zero. Nem uma frase.
• Não processa imagem ou áudio. Só texto e JSON.
• Não faz raciocínio de longa cadeia. Janela de contexto de 32K tokens.
• Não conversa. Não tem chat, não tem memória de conversa.
• Não gera código. Não substitui Copilot, Claude Code, nem nada parecido.

Se você precisa de qualquer uma dessas coisas, continue usando LLMs. O Jev não compete com eles. Ele complementa.

Comparação prática: Jev vs. LLM para classificação

Pra deixar concreto, imagina que você tem 1 milhão de e-mails para classificar em 5 categorias. Vou colocar os números lado a lado:

A diferença é brutal. E se escala pra 100 milhões? O GPT custa US$ 160 mil. O Jev custa US$ 2.100. Esse tipo de economia muda a viabilidade de projetos inteiros.

Claro, tem um catch: o LLM pode explicar por que classificou daquele jeito. O Jev te dá a distribuição de probabilidades, mas sem raciocínio. Se você precisa de auditabilidade com explicação textual, vai precisar do LLM pelo menos nos casos edge.

O padrão “LLM-in-the-loop”

A arquitetura sugerida pela TypeSafe é elegante: use um LLM para definir a lógica de decisão (quais as opções, qual o schema, quais os thresholds), e depois execute essa lógica em produção com o Jev.

Na prática:

1. Dev usa Claude ou GPT para prototipar a classificação com prompt engineering
2. Valida os resultados com dados reais
3. Converte a lógica para um schema Jev (Choice/Score/Noul)
4. Executa em produção com Jev a uma fração do custo

É o mesmo padrão que a galera de ML faz com distillation, transferir conhecimento de um modelo grande para um menor e mais eficiente. Só que em vez de treinar um modelo menor, você reconfigura o problema para caber num framework de decisão estruturada.

Os céticos têm razão (parcialmente)

A thread do Hacker News teve mais de 500 comentários. Os céticos levantaram pontos válidos:

“É só um classificador glorificado.” Parcialmente verdade. Mas um classificador com RLCD, calibração de confiança, e latência sub-100ms não é trivial. Se fosse, todo mundo já teria feito.

“Sem paper, sem credibilidade.” Concordo. A TypeSafe promete publicar os detalhes técnicos, mas enquanto isso não acontece, é investimento em confiança baseado no currículo do fundador.

“Os benchmarks são cherry-picked.” Todo benchmark de startup é. Mas a diferença arquitetural (output paralelo vs. autoregressive) justifica uma vantagem de velocidade estrutural, não marginal. A magnitude exata é discutível; a direção, não.

“Vai virar commodity em 6 meses.” Possível. Se a OpenAI ou Anthropic criarem um modo “structured decision” nos modelos existentes com latência comparável, o Jev perde a vantagem. Mas por enquanto, ninguém anunciou isso.

Impacto para devs brasileiros

Se você trabalha com automação, pipelines de dados, ou agentes de IA, o Jev é relevante agora. Mesmo em early access.

O cenário mais comum que eu vejo em empresas brasileiras: usar GPT-4 ou Claude para classificar leads, categorizar tickets, filtrar conteúdo. Cada chamada demora 2 a 5 segundos e custa centavos. Multiplica por milhões de chamadas e o custo vira um problema real.

Com o Jev, essas operações custam ordens de grandeza menos e rodam em milissegundos. A integração é simples porque input e output são JSON puro, sem parsing de texto natural, sem regex para extrair a resposta de um parágrafo.

O early access está aberto no site da TypeSafe. Não tem API pública ainda, nem integração com OpenRouter ou Bedrock. Mas vale ficar de olho.

Isso é o começo de uma nova categoria?

Se o Jev entregar o que promete em produção real (e não só em demos), estamos vendo o nascimento de uma categoria nova de modelos de IA. Não mais inteligentes. Não mais criativos. Mais especializados.

A analogia que eu gosto: LLMs são como um canivete suíço. Fazem de tudo, mais ou menos. System One Models são como uma chave de fenda elétrica. Fazem uma coisa, mas fazem absurdamente bem.

O mercado de IA está amadurecendo quando começa a separar “geração de texto” de “tomada de decisão” como problemas fundamentalmente diferentes que merecem ferramentas diferentes. E a TypeSafe, com um ex-OpenAI no comando e US$ 40 milhões no caixa, tem munição para provar que essa separação faz sentido.

Fica a pergunta: quantas das suas chamadas de API para LLM são, no fundo, classificações disfarçadas de conversas?

Fonte de inspiração: Introducing System One Models and Jev (TypeSafe AI Blog)