O Jev é Open Source? Os Pesos São Fechados, as Ferramentas Não

Não. Jev 1.13 (typesafe/jev-1.13) não é de código aberto, não há repositório de pesos para encontrar, e por mais que se percorra a organização da TypeSafe no GitHub não aparecerá um checkpoint, um documento de arquitetura ou uma contagem de parâmetros. O que existe é o software em torno do modelo: onze repositórios públicos, todos eles MIT ou Apache-2.0, nenhum deles contendo o próprio Jev. Essa é a resposta honesta de uma linha — as ferramentas são abertas, o modelo não — e é a metade da história que um leitor nunca obtém apenas de "fechado, alojado, não publicado". Duas datas enquadram isto. A TypeSafe lançou o modelo em 2026-09-15, o que está fora da janela de sete dias sobre a qual este blog escreve, portanto isto não é um artigo de lançamento e nada nele deve ser lido como tal. O evento datado é 2026-09-24, quando a OrcaRouter adicionou typesafe/jev-1.13 ao seu próprio catálogo: a primeira vez que o Jev é invocável através de um gateway de terceiros, em vez de apenas através do endpoint da própria TypeSafe. Essa é a exceção em que esta página se baseia — um modelo que se tornou executável onde não o era.

O que isso muda para o leitor é restrito e prático. Antes de 2026-09-24, avaliar o Jev significava abrir uma segunda relação com fornecedor antes de conseguir testar uma única decisão. Depois disso, o Jev fica na mesma chave que a metade generativa do mesmo fluxo de trabalho: uma API para mais de 200 modelos, 0% de markup (preço de tabela do fornecedor repassado, então cortes de preço dos fornecedores entram em vigor aqui no mesmo dia), com o modelo acessível em typesafe/jev-1.13. Você ainda o chama na sua própria forma — POST /v1/systemone, sem streaming — porque essa não é a rota de chat-completions da OpenAI, mas o contrato que você assina e a chave que você rotaciona são os que você já tem.

A resposta são duas respostas, e ambas são necessárias.

“O Jev é de código aberto?” soa como uma pergunta de sim ou não e se comporta como uma pergunta de duas partes. Primeira parte: o modelo. Ele é fechado. A TypeSafe não publicou pesos, nem arquitetura, nem valor de computação de treinamento e nem contagem de parâmetros para o Jev 1.13, e não há repositório com o nome dele. Segunda parte: o software ao redor. Ele é aberto, mantido ativamente e genuinamente útil, e é a razão pela qual um leitor que procura um repositório não fica simplesmente sem sorte.

Confundir os dois leva à conclusão errada nos dois sentidos. Presuma que tudo está aberto e você vai passar uma tarde procurando um ponto de verificação que não existe. Presuma que tudo está fechado e você vai perder a peça que realmente importa, se estiver preocupado com lock-in — um adaptador licenciado sob MIT que permite construir sobre a interface de decisão tipada e trocar o que está por trás dela.

O que a TypeSafe realmente publica

Lido em 2026-09-30, a organização tem onze repositórios públicos. As contagens de estrelas e as datas de push mudam, portanto, trate isto como um instantâneo, e não como uma propriedade fixa do projeto. Todas as licenças são MIT ou Apache-2.0, salvo indicação em contrário.

• skills — MIT, aproximadamente 2,4 mil estrelas, último push em 2026-09-12. "Habilidades de agente para construir com a API System One da TypeSafe."

• system-one-adapter-python — MIT, 356 estrelas, último push em 2026-09-22. "Substituto drop-in do TypeSafeClient, com base em APIs de LLM."

• typesafe-sdk-js — MIT, 257 estrelas, último push em 2026-09-15. A biblioteca oficial em TypeScript/JavaScript para a API TypeSafe.

• typesafe-sdk-python — MIT, 254 estrelas, último push em 2026-09-26. A biblioteca oficial de Python; a v0.7.2 adicionou um extra `http2` naquele dia, e a v0.7.1, em 2026-09-21, adicionou exemplos de uso com gateways de IA.

• daggerverse — Apache-2.0, 23 estrelas, último push em 2026-09-25. Uma coleção de módulos Dagger.

• WorkflowEvals — Apache-2.0, 7 estrelas, último push em 2026-09-29. "código de workflow do evals.typesafe.ai publicado."

• n8n-nodes-typesafe-ai — MIT, 1 estrela, último push em 2026-09-29.

typesafe-ai.github.io — nenhuma licença declarada, 2 estrelas, último push em 2026-06-04.

Mais três são forks de projetos não relacionados e são abordados abaixo: pulumi-clickhouse, LLaDA e vllm.

Nada nessa lista é o modelo. Não há repositório do Jev, nem arquivos de pesos, nem tokenizador, nem configuração de serving — nada que permita montar uma cópia funcional. Os repositórios são acessórios do lado do cliente: dois SDKs oficiais, um pacote de agent-skills, uma coleção de módulos de CI, uma suíte de avaliação publicada, um nó do n8n, o site da organização e o adaptador. Essa é uma superfície real e bem mantida, e não é o modelo.

O único repositório que importa se você está tentando evitar o lock-in

system-one-adapter-python é a entrada de maior consequência para qualquer pessoa que esteja tomando uma decisão de adoção, e sua própria descrição deixa claro o ponto: um "substituto direto do TypeSafeClient, respaldado por APIs de LLM".

Leia isso com atenção, porque está fazendo algo específico. O ativo durável em uma integração com o System One é a interface, não o endpoint por trás dela: você define um pedaço de estado e um conjunto de perguntas nomeadas, e algo retorna uma resposta tipada por pergunta. É em torno desse contrato que sua base de código acaba se moldando. O adaptador desacopla o contrato da implementação — você continua construindo em cima da interface de decisões tipadas, e o que produz as decisões é, por baixo, uma chamada de API de LLM substituível.

Duas ressalvas honestas. Um adaptador não é o modelo: respostas produzidas por um LLM geral por este caminho não são as probabilidades calibradas que o Jev retorna, então é uma forma de manter a interface portátil, não uma forma de obter o comportamento do Jev sem o Jev. E é explicitamente um projeto TypeSafe — o mecanismo de escape é construído pelo fornecedor do qual você pode querer escapar, o que é melhor do que nada e não é o mesmo que um independente.

As duas bifurcações, e a inferência que elas convidam

Três dos onze repositórios são forks. pulumi-clickhouse é um provedor Pulumi para o ClickHouse Cloud, Apache-2.0, 3 estrelas, último push em 2026-07-08. Os outros dois são os que acabam sendo lidos como evidência, e ambas as leituras estão erradas.

• vllm — Apache-2.0, 3 estrelas, último push em 2025-05-23. Um fork do motor de inferência e serviço de alto rendimento.

• LLaDA — MIT, 12 estrelas, último push em 2025-06-17. Um fork da implementação oficial em PyTorch para "Large Language Diffusion Models."

A inferência preguiçosa se escreve sozinha: eles fizeram um fork de um repositório de modelo de linguagem de difusão, então o Jev deve ser baseado em difusão. Não é, e o fork não diz nada sobre a arquitetura do Jev. Um fork é uma cópia do código de outra pessoa, sob a licença de outra pessoa, que está numa organização por razões que a data do seu próprio último push torna óbvias — maio e junho de 2025, mais de um ano antes de o Jev ser lançado publicamente, e sem alterações desde então. Nenhum dos dois repositórios faz parte do que a TypeSafe lançou em setembro. Se você quer saber como o Jev funciona, a TypeSafe não publicou isso, e nenhum fork em sua organização preenche a lacuna.

O que fechar os pesos realmente custa a você

Quatro coisas, e são concretas em vez de filosóficas.

• Você não pode auto-hospedar. Não há artefato para executar, então uma indisponibilidade do fornecedor ou uma alteração de acesso não é algo que você possa contornar subindo sua própria cópia.

• Você não pode auditar. A TypeSafe publica uma página de jaggedness para o Jev 1.13 — revisada pela última vez em 2026-09-17 — que nomeia onde o modelo é não confiável: leitura literal do texto em detrimento da intenção, qualquer coisa envolvendo aritmética, comparação de datas e horas, indireção e negativas duplas, estados grandes cheios de detalhes irrelevantes, conteúdo adversarial no estado, instruções e critérios contraditórios, e invariantes estruturais que ele não garante, como uma resposta verdadeiro/falso e sua escolha equivalente sim/não discordarem entre si. Essa página é excepcionalmente franca, e ainda assim é o fornecedor corrigindo a própria prova. Ninguém fora da TypeSafe inspecionou os pesos.

• Você não pode fazer fine-tuning. Não há modelo base para adaptar, então uma tarefa de decisão que o Jev executa mal continua mal executada até que o fornecedor a altere — as próprias soluções da página de irregularidade são contornos no seu código, não execuções de treinamento.

• Você não pode fixar uma versão além do alias do fornecedor. typesafe/jev-1.13 é um nome hospedado, então o que responder a uma chamada no próximo mês será o que a TypeSafe estiver servindo sob esse nome naquele momento.

Nada disso é exclusivo do Jev e nada disso é escândalo; é a troca que um modelo de decisão hospedado faz, e o contrapeso é que você nunca carrega um checkpoint, uma fatura de GPU ou uma pilha de inferência. Vale a pena saber em que lado dessa troca você está antes de construir sobre ela.

O que é o Jev, agora que você pode chamá-lo

Jev não é um modelo de chat e não gera prosa. Você envia um estado — o material a ser julgado, como texto, um objeto ou um array — mais um conjunto de perguntas nomeadas, e ele retorna uma resposta estruturada por pergunta. Toda pergunta é uma de três primitivas:

• noul — um julgamento verdadeiro/falso, retornado com uma probabilidade calibrada.

• escolha — selecione uma entre até 255 opções rotuladas.

• pontuação — classifique em uma escala ordenada de 2 a 10 níveis.

A documentação da própria TypeSafe mostra um exemplo de pontuação com índice zero; o cartão de modelo do Jev 1.13 publica níveis de 2 a 10. Ambos são material do próprio fornecedor, e esta página não inventa uma conciliação entre eles.

O método de treinamento é uma cunhagem da própria TypeSafe: Decisões Calibradas (RL), descrito no post de lançamento em comparação com RLHF e RLVR no eixo de decisões calibradas com probabilidades honestas. RL é um termo da TypeSafe, não uma sigla genérica de aprendizado de máquina, e deve ser lido como uma descrição do fornecedor, em vez de uma técnica caracterizada de forma independente.

O acesso já não está limitado: o Jev está disponível de forma geral desde 2026-09-21, e «em lista de espera» caiu em desuso. «Acesso antecipado» continua a ser a formulação atual da própria TypeSafe na sua página inicial, pelo que não é uma alegação que se deva descartar — é simplesmente o rótulo do fornecedor, e os limites operacionais que este publica a par dele são concretos.

Os números em nosso cartão: um contexto de 65.536 tokens, com o fornecedor documentando aproximadamente 64K de entrada no estado combinado somado às perguntas. Se você viu um número menor citado para Jev, esse é o orçamento de estado isoladamente, e não uma medição concorrente, e os dois não devem ser apresentados como uma contradição. O preço é US$ 0,042 por milhão de tokens de entrada, com a saída cobrada a zero — não há tokens de saída a medir, porque uma decisão tipada não é prosa.

Nossos próprios dados de serviço, do nosso tráfego em vez do benchmark do fornecedor, nos sete dias até 2026-09-30: p50 151 ms, p95 247 ms, cerca de 349 tokens de saída por segundo, taxa de erro de 0,49% e 76,2M tokens servidos. O p50 diário nessa janela foi 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, com um verdadeiro outlier — um p95 de 2.448 ms em 2026-09-28, que pertence à série sem ser a norma.

As alegações de destaque da TypeSafe, rotuladas como do fornecedor e não replicadas de forma independente: "193,6x Mais Rápido, 444,6x Mais Barato", com nota de rodapé remetendo a fluxos de trabalho do System One; um exemplo prático de US$ 0,000081 em 0,114 s contra US$ 0,013880 em 8,566 s para LLMs; "US$ 42 por bilhão de tokens de entrada"; e "Zero Alucinações", que é uma alegação sobre estimativas de confiança, e não uma prova de zero erros — a taxa de erro de 0,49% da nossa ficha é o contrapeso honesto. A TypeSafe também afirma claramente que não pode provar que sua precificação não é subsidiada, e que suas avaliações publicadas foram geralmente executadas a partir de laptops na Costa Oeste, onde o serviço está sediado. Sua própria ficha de benchmark ainda está marcada como pendente.

Os repositórios de terceiros existem, e não nos responsabilizamos por eles.

Pesquisas por "jev github" acabam por revelar repositórios que não são da TypeSafe: wrappers, coleções de prompts, experiências com adaptadores e a conhecida lista "awesome" que aparece em torno de qualquer novo modelo. Não fazem parte do que o fornecedor publica, não têm revisão do fornecedor, e as suas contagens de estrelas medem curiosidade, não correção. Podem ser úteis; não são documentação, e nada neles constitui uma afirmação sobre como o Jev funciona.

O que mudaria esta resposta

Um lançamento de pesos, uma arquitetura publicada, ou uma avaliação independente da qualidade da decisão, em vez da latência. Qualquer uma das três mudaria a primeira palavra desta página. Até então, a busca tem uma resposta estável, e a parte dela sobre a qual vale a pena agir é a cadeia de ferramentas: se a interface de decisão tipada é aquilo contra o que você está construindo, um adaptador licenciado sob MIT que troca o modelo subjacente é a diferença entre uma decisão que você pode revisitar e uma que você não pode.

Jev 1.13 está no nosso catálogo em typesafe/jev-1.13, na mesma chave que o restante de uma stack e encaminhado através do endpoint dedicado systemone, em vez do formato chat-completions. O modelo é fechado, as ferramentas são abertas, e ambas as metades disso agora estão acessíveis a partir de um único lugar.