"System One" como Categoria de Modelo: Onde o Jev 1.13 se Encaixa

"System One" é o termo de categoria que a TypeSafe usa para sua divisão entre um modelo que decide e um modelo que escreve, e o Jev 1.13 (typesafe/jev-1.13) é seu primeiro membro — um modelo que retorna respostas tipadas em vez de frases. Não é um modelo novo. A TypeSafe lançou o Jev em 2026-09-15, e esta página não é um artigo de lançamento: o modelo tem quinze dias e está fora da janela de sete dias para a qual este blog escreve. O que aconteceu dentro da janela foi que a OrcaRouter adicionou o modelo ao seu catálogo em 2026-09-24 e abriu o card do modelo do Jev 1.13 em https://www.orcarouter.ai/models/typesafe/jev-1.13 — a primeira vez que ele pode ser chamado por meio de um gateway de terceiros em vez de apenas pelo endpoint da própria TypeSafe. A ideia de categoria é a razão pela qual esta página existe; a mudança de disponibilização é a razão pela qual ela está datada de hoje.

A versão simples da categoria: pergunta-se a um LLM uma questão, e ele escreve uma resposta para uma pessoa ler. Pergunta-se a um modelo System One uma questão, e ele retorna um valor com base no qual um programa ramifica. O próprio posicionamento da TypeSafe é que "os LLMs produzem palavras para pessoas", enquanto "o Jev produz decisões tipadas e é mais parecido com código: confiável, rápido, autoconsistente e seguro em termos de tipos". Essa frase é a categoria inteira comprimida em uma única oração, e vale a pena destrinchá-la devagar, porque os quatro adjetivos fazem quantidades diferentes de trabalho e um deles faz mais do que os outros.

O que "mais parecido com código" realmente afirma

Considere as quatro afirmações em ordem, porque não são quatro reformulações de "é melhor".

• Confiável — o formato da saída é fixado de antemão. Você declara a pergunta; a resposta só pode voltar como um dos valores que você permitiu. A TypeSafe afirma claramente que "o modelo nunca comete erros de tipo" e observa que esta é a única afirmação sua que é "matematicamente impossível" de falsificar com um contraexemplo, porque um valor que não está no seu conjunto declarado não é um valor que o modelo possa emitir.

• Rápido — todas as respostas são produzidas em uma única passada, em vez de um token após o outro. O post de lançamento da TypeSafe descreve assim: "a Jev emite todas as probabilidades em paralelo, em vez de gerar autorregressivamente token a token". Na nossa própria janela de serviço de sete dias, encerrada em 2026-09-30, o tempo mediano até o primeiro token em typesafe/jev-1.13 é de 151 ms e o p95 é de 247 ms.

• Autoconsistente — o mesmo estado com as mesmas perguntas tende a produzir as mesmas respostas. Uma analogia com programação é o que torna isso legível, mas é também onde a analogia deixa de ser uma prova: o determinismo de um compilador é uma propriedade de sua construção, ao passo que isto é uma afirmação sobre um comportamento. Nossas próprias medições são a leitura honesta disso — a taxa de erro no tráfego do nosso playground ao longo da mesma janela de sete dias é de 0,49%, então ele é autoconsistente como uma boa função é autoconsistente, não como a aritmética é.

• Seguro em termos de tipos — e este é o que carrega mais peso. Seguro em termos de tipos não é um adjetivo de qualidade aqui; é uma afirmação sobre onde o modelo se situa em relação a um verificador de tipos. Num pipeline generativo comum, o sistema de tipos começa depois que o modelo termina: o modelo escreve texto, um parser adivinha o formato, um validador o verifica, e um caminho de falha trata os casos em que a adivinhação estava errada. Um modelo System One move a declaração de tipo para antes da chamada. As três primitivas que o nosso card documenta são o sistema de tipos: noul, um julgamento de verdadeiro/falso retornado com uma probabilidade calibrada; choice, um rótulo escolhido entre até 255 opções rotuladas; e score, uma avaliação numa escala ordenada de 2 a 10 níveis. Você escolhe a primitiva, você fornece os rótulos ou os critérios, e o valor devolvido é extraído desse conjunto.

A TypeSafe publica uma diferença entre a sua própria documentação e a nossa que vale a pena mencionar em vez de resolver: a documentação do fornecedor apresenta um exemplo de Score com índice iniciado em zero, enquanto o nosso cartão documenta a escala como 2 a 10 níveis. Ambos descrevem a mesma primitiva. Se estiver a construir um limiar, leia a página do fornecedor para saber a indexação exata da sua versão do SDK.

Os dois modos de falha que deixam de existir

A consequência interessante de "sem prosa" não é estética. É que as duas falhas que dominam os pipelines generativos de produção estão ausentes neste design, em vez de serem mitigadas por ele.

O desvio de formato é o primeiro. Um LLM instruído a retornar JSON retorna JSON na maioria das vezes, e algo próximo de JSON no restante — um comentário no final, uma cerca de markdown, um campo renomeado para um sinônimo, um objeto aninhado onde o esquema queria uma string. As correções no nível do prompt (instruções mais fortes, exemplos few-shot, um esquema na mensagem de sistema) são todas tentativas de manter uma forma que o modelo tem liberdade para abandonar, porque a forma é um pedido, não uma restrição. O enquadramento da TypeSafe torna o contraste explícito: com strings, "possíveis saídas e estrutura" são solicitadas e as respostas "precisam ser parseadas + validadas", com "sempre algum risco de a IA sair dos trilhos". Quando as possíveis saídas são declaradas de antemão, o desvio não tem para onde ir.

A saída não analisável vem em segundo lugar, e é realmente a mesma falha em um momento pior — não um campo que retornou ligeiramente errado, mas uma resposta que o analisador não consegue ler de forma alguma, chegando no ponto menos conveniente de um fluxo de trabalho. Um modelo que emite um valor tipado não tem esse estado.

Este é um argumento estrutural, e deveria ser apresentado como tal. Ele não diz nada sobre se uma resposta individual está correta — uma questão de escolha pode escolher o rótulo errado, e um noul pode retornar true com alta confiança quando a resposta honesta é falsa. O que desaparece é a categoria de falha que um parser teria capturado. Essa é uma redução real e útil, e não é a mesma afirmação que "as respostas estão corretas."

Por que o preço é uma forma, não um desconto

O modelo tem um preço de $0.042 por milhão de tokens de entrada, com a saída faturada a zero — e esse zero não é uma tarifa promocional, é um artefacto do design. Um modelo que emite três tokens de resposta estruturada não tem volume de saída para medir, pelo que o preço por token de saída não tem nada a que se associar. A forma de faturação é uma cobrança por token de entrada e uma decisão. O nosso catálogo repassa o preço de tabela do fornecedor com 0% de markup, pelo que os $0.042 são um número da TypeSafe e não um número que nós definimos, e uma alteração de preço do fornecedor entraria em vigor no mesmo dia.

Coloque as duas formas lado a lado e a diferença não é uma porcentagem. O custo de um pipeline generativo escala com o quanto o modelo diz: uma resposta prolixa custa mais do que uma concisa para a mesma decisão, e um modelo de raciocínio em cadeia cobra pelos tokens que gasta pensando antes de responder, melhore a resposta ou não. O custo de uma chamada do System One escala com o quanto você mostra a ele — o estado e as perguntas. Faça uma pergunta com base em um documento longo e você paga pelo documento. Coloque quarenta perguntas contra o mesmo estado (o orçamento de entrada no nosso card é de 65.536 tokens somando estado e perguntas, aproximadamente 64K; se você viu a cifra "aproximadamente 32.000 tokens" em artigos anteriores do OrcaRouter, esse é apenas o orçamento de estado, não um total concorrente) e você paga pelo documento uma vez e recebe quarenta decisões de volta.

É por isso que custo por decisão, e não custo por token, é a unidade certa para esta classe — e por que o medidor corre no sentido oposto ao que a maioria das equipes espera. A típica medida de redução de custos em IA generativa é "fazer o modelo dizer menos". Aqui não há nada de que dizer menos.

Os próprios números da TypeSafe, que são relatados pelo fornecedor e não foram replicados de forma independente, visam diretamente essa comparação: "193,6x mais rápido, 444,6x mais barato", com nota de rodapé "baseado em fluxos de trabalho para tarefas do System One (comprovação)", com um exemplo prático que diz "TypeSafe AI Custo $0,000081 Concluído em 0,114s / LLMs Custo $0,013880 Concluído em 8,566s". A página inicial também lista "$42 por bilhão de tokens de entrada" contra "preço de entrada 238x menor que o Claude Fable 5.1". Trate tudo isso como o argumento do fornecedor, não como um resultado medido: o post de lançamento admite que "nossas avaliações publicadas são geralmente executadas em nossos laptops na Costa Oeste" e que "não podemos provar que não é subsidiado; precisaremos do longo prazo para provar a sustentabilidade de nosso preço (que esperamos que diminua, não aumente)". Essas duas concessões são do próprio fornecedor, e são o enquadramento correto para cada multiplicador na página.

A calibração é a segunda metade da ideia.

Se a categoria fosse apenas “saída estruturada”, ela descreveria function calling com etapas extras. O que a torna algo à parte é que toda resposta chega acompanhada de uma probabilidade, e as probabilidades são o alvo de treinamento. A TypeSafe chama o método de Reinforcement Learning for Calibrated Decisions (RLCD) — termo deles, não uma sigla genérica — e a tabela comparativa no post de lançamento o coloca ao lado de RLHF e RLVR: RLHF otimiza para o que avaliadores humanos preferem, RLVR para saídas que podem ser verificadas programaticamente, e RLCD para “respostas com probabilidades epistemicamente honestas em tarefas de System One.”

A diferença prática está em para que serve a probabilidade. Num pipeline generativo, a estimativa de confiança é uma segunda geração: você pergunta ao modelo quão seguro ele está e ele escreve um número, que é, ele próprio, prosa com os mesmos modos de falha. Aqui, a probabilidade vem junto com a decisão, na mesma passagem, e é nela que você se baseia para ramificar. A própria formulação da TypeSafe sobre o retorno é que um modelo que consegue realizar uma tarefa 95% das vezes, mas "não diz quando está nos 5%", não pode ser usado para automatizar a tarefa; a confiança dá a você um lugar para colocar a escalação, para uma pessoa ou para um modelo de raciocínio.

A página inicial da TypeSafe declara isso como "Zero Alucinações", explicando que toda decisão carrega uma estimativa de confiança para que o software possa "agir quando a confiança é alta e escalar quando não for". Leia isso com atenção: é uma afirmação sobre estimativas de confiança, não uma afirmação de que nenhuma resposta jamais está errada. Nosso próprio card é o contrapeso — uma taxa de erro de 0,49% nos sete dias terminados em 30/09/2026, no nosso tráfego, medida por nós. Esse número é uma janela móvel, não um conjunto de testes fixo: ele estava registrando 0,57% alguns dias antes, na mesma janela, e vai mudar novamente.

Onde o System One fica ao lado do System Two

O vocabulário rápido/lento é muito anterior à TypeSafe. Ele vem do livro de Kahneman, Rápido e Devagar, e vem sendo emprestado por pesquisadores de IA há anos, antes disso — o rótulo "Sistema 2" foi atribuído a modelos de cadeia de pensamento e raciocínio deliberado muito antes de a TypeSafe existir, e a TypeSafe não afirma ter cunhado nenhum dos dois termos. O que eles fizeram foi aplicar a distinção a uma fronteira de produto, e não a um modo de prompting.

• Um modelo de raciocínio System Two usa mais computação antes de responder e fica melhor em problemas que precisam disso. Sua saída ainda é prosa, e a computação extra é cobrada como tokens de saída.

• Um modelo System One no sentido da TypeSafe não pensa por mais tempo para responder melhor. Ele responde em uma única passagem, e o que abre mão em troca da velocidade é a capacidade de produzir qualquer coisa que não seja um valor tipado.

• Os dois são complementares em um fluxo de trabalho, não rivais em uma comparação. Uma chamada do System One dá conta das decisões que precisam ser rápidas, baratas e legíveis; o modelo de raciocínio fica com os casos que a pontuação de confiança sinalizou como incertos. A saída tipada é o que torna a transferência limpa — você está passando um valor e uma probabilidade para a próxima etapa, não uma frase para ser reanalisada.

O ponto em que o vocabulário fica escorregadio é tratar "modelo System One" como uma categoria estabelecida que outros fornecedores adotaram. Não há evidências disso, e esta página não deve ser lida como se estivesse alegando isso. A TypeSafe usa o termo para sua própria classe de modelos; a ressalva em nosso próprio card diz o mesmo por omissão, listando um único tipo de endpoint para um único modelo. Se outro laboratório começar a usar a expressão para a mesma arquitetura, isso será um fato que vale a pena reportar, e será preciso usar as palavras do próprio laboratório para reportá-lo.

Nosso cartão também lista a irregularidade como parte do limite honesto, e não como uma surpresa: nove modos de falha nomeados. As entradas de leitura literal e de indireção são as que decorrem diretamente da analogia "mais como código" — um modelo que responde à pergunta que você escreveu, e não à que você queria dizer, está se comportando como uma função que fez exatamente o que o código dizia. A entrada sobre contagem não. Um modelo que "reconhece a forma de uma resposta em vez de contabilizá-la" não se parece em nada com código, e é por isso que a recomendação da própria TypeSafe é contar em código e, quando um julgamento for realmente necessário, fazer uma pergunta por item e somar as respostas você mesmo.

Dois limites que moldam o design, não a pontuação

Ambos vêm do mesmo lugar: sem strings, não há nada para transmitir nem nada para enviar em pedaços.

• Não streaming — a primeira saída é a resposta pronta, então uma chamada do System One é uma única resposta, não um stream. A questão não é se ela consegue fazer streaming, mas o que faria streaming.

• Um único formato de requisição — o modelo é servido via POST /v1/systemone no nosso catálogo, em vez do formato chat-completions, e essa é a versão honesta de uma afirmação antiga de que ele "fala seu próprio formato de requisição". É uma diferença real na forma como você o chama: entram um objeto de estado e um mapa de perguntas nomeadas; sai uma resposta estruturada por pergunta. Você escreverá um mapeador para ele e, como a saída é tipada, o mapeador é a integração inteira — não há nenhuma camada de parsing defensiva por baixo dele.

Vale a pena saber antes de fazer teste de carga: a latência não é uniforme entre os tipos de pergunta. A TypeSafe explica por quê, em suas próprias palavras: "Para escolhas de cardinalidade mais alta, fazemos um sistema de dois estágios, pontuando de forma independente e depois fazendo uma escolha explícita, daí a lentidão ocasional." Uma decisão de roteamento com 4 opções e uma classificação com 200 opções são a mesma primitiva no papel e quantidades diferentes de trabalho na prática. Nossas medianas diárias nos sete dias terminados em 2026-09-30 são 175, 170, 163, 161, 170, 147, 143 ms. Um dia nessa série, 2026-09-28, teve um p95 de 2.448 ms — um verdadeiro outlier de um único dia que se encaixa honestamente na série, mas não é o formato do serviço.

A outra coisa que você precisa saber antes de uma primeira integração é com o que você está se conectando. O ferramental em torno do Jev é de código aberto sob as licenças MIT e Apache-2.0 — os SDKs de Python e JavaScript, um adaptador que apresenta o mesmo cliente respaldado por APIs comuns de LLM, o código do workflow-evals e um conjunto de habilidades de agente, todos nos repositórios públicos da TypeSafe, com contagens de estrelas e datas de push que mudaram tão recentemente quanto 2026-09-26 e 2026-09-29. O modelo não é. Não há repositório de pesos: a arquitetura do Jev, a contagem de parâmetros, a computação de treinamento e os pesos não foram publicados, e quem estiver verificando isso não deve se deixar enganar pelos três repositórios naquela organização que são forks de projetos não relacionados — um fork do vLLM, um lançamento de modelo de linguagem de difusão de 2025 e um provedor Pulumi. Nenhum deles diz nada sobre como o Jev é construído. A resposta em uma linha é que o ferramental é aberto e o modelo não.

Executando-o hoje, e o que muda para um leitor

O Jev 1.13 está no OrcaRouter como typesafe/jev-1.13, acessível na mesma chave que mais de 200 outros modelos, com o preço de tabela do provedor repassado com 0% de markup. O valor prático disso numa página sobre uma categoria é limitado e vale a pena declarar exatamente: experimentar um modelo System One já não exige uma conta separada, uma chave separada e uma fatura separada para um modelo que você talvez ainda não saiba que quer. Ele fica ao lado da metade generativa do mesmo fluxo de trabalho — o classificador e o redator numa única credencial, num único lugar, com as contagens do que você realmente chamou.

Nada aqui muda o que o modelo é. Ele foi lançado em 15 de setembro de 2026 e a TypeSafe ainda o descreve como acesso antecipado; o que ele é não mudou desde então. O que mudou em 24 de setembro de 2026 é que agora um leitor pode descobrir quanto isso lhe custa na prática sem primeiro firmar uma relação com um segundo fornecedor. Se você estava esperando para ver se a categoria vale um protótipo, foi isso que mudou.