Playground ou API do Jev: por onde começar a validar o modelo?

Fala aí, beleza? A TypeSafe AI soltou o Jev, que ela própria apresenta como o primeiro modelo público da empresa, e ele não escreve texto nenhum

Ele recebe um state não estruturado e devolve decisão tipada com probabilidade, o tal System One

Aí bate a dúvida clássica de quem acabou de conseguir acesso: abro o Playground ou já ponho a chamada no código? O Jev foi lançado em early access em 15 de setembro de 2026, os signups diretos estão pausados desde 22/09/2026 (volto nisso mais pra frente), o tempo de quem já tem conta é curto, e a ordem em que você valida faz MUITA diferença

A real é que cada caminho responde uma pergunta diferente. Se você inverter, vai gastar uma tarde validando a coisa errada primeiro

Playground x API do Jev: o que cada um responde

É a mesma bifurcação de por onde começar com o Gemini: tem a interface pra entender o bicho e tem a integração pra decidir se ele entra no produto

Repara que não tem vencedor aqui

Tem ordem

O que resolver no Playground antes de escrever qualquer código

O Playground oficial fica no console da TypeSafe e o próprio quickstart manda abrir ele e logar ANTES de escrever código

O motivo é simples: no Jev o difícil não é a integração, é a pergunta

Escolher a primitiva certa:

São três tipos de pergunta, e a documentação das primitivas dá a régua de bolso:

• opção entre várias? Choice
• posição num espectro? Score
• sim ou não? Noul

Parece bobo, mas é aqui que a maioria erra. A pessoa pede um Score pra uma coisa que é sim ou não, e depois fica tentando interpretar cinco níveis que nunca precisaram existir

Quebrar o julgamento amplo em perguntas estreitas:

A orientação da TypeSafe é quebrar julgamento grande em perguntas estreitas e tipadas, dando a cada pergunta só o contexto que ela precisa

"Esse ticket é bom?" não é pergunta

"Esse ticket menciona cobrança?" (Noul), "qual fila atende esse ticket?" (Choice) e "qual a urgência dele?" (Score) são três perguntas que o modelo consegue responder

Entender os campos que voltam:

Isso também é trabalho de Playground, porque é leitura, não arquitetura:

• Noul volta um número só: a probabilidade de a resposta ser sim, onde 0 é não e 1 é sim
• Choice volta a opção selecionada, uma probabilidade pra cada opção e um valor de confiança pra escolhida
• Score volta o score, uma probabilidade pra cada nível e um valor de confiança

Quando você olha pra essa resposta e já sabe de cara o que é confidence e o que é probabilities, acabou o serviço do Playground

Bora pro código?

O que só aparece quando a chamada entra no seu código

Aqui mora a decisão de produto. Nenhuma interface decide isso por você

Threshold. A documentação é bem direta: você escolhe o corte com exemplos rotulados, pesando o custo do erro e o custo da revisão humana, começando conservador e ajustando com dados seus. E ela lembra de uma coisa que muita gente esquece: ações diferentes no mesmo sistema podem ter thresholds diferentes. Arquivar automático não pede a mesma certeza que mandar email pro cliente

Orçamento de tokens. São 64k tokens por requisição no total (state mais todas as perguntas), com no máximo 32k pro state mais a pergunta mais longa. Seu state real é que vai dizer se isso aperta

Perguntas em paralelo. Os três tipos podem ser misturados na mesma chamada, e cada pergunta é avaliada em paralelo e isolada contra o mesmo state. Segundo a documentação, adicionar pergunta numa requisição existente quase não mexe no tempo de resposta e custa só os tokens extras das perguntas

Isso muda o desenho do seu código, não o do seu teste manual

Custo real. US$ 0,042 por 1M de tokens de input, output a US$ 0,00. O número só vira informação útil quando multiplicado pelo tamanho do seu state vezes o seu volume

Latência da sua região. A própria TypeSafe registra no blog dela que as medições de velocidade publicadas foram feitas a partir da West Coast dos EUA, região onde o serviço roda. Se seu servidor está em São Paulo, esse número não é o seu número. Só medindo

Versão fixada. Existe a versão jev-1.13 e o alias jev-latest, que aponta pra mais recente. Em produção, fixar versão evita surpresa

Jaggedness. A documentação mantém uma página de jaggedness do Jev 1.13 descrevendo onde o desempenho do modelo é irregular. Ler isso antes de cravar threshold economiza retrabalho

Roteiro de validação: do Playground à primeira chamada em produção

1. Abra o Playground no console e faça login. É console.typesafe.ai, e o quickstart coloca esse passo antes de qualquer código. O erro comum deste passo: pular ele e ir direto pro SDK, aí você descobre o problema de formulação da pergunta depois de já ter escrito o wrapper inteiro

2. Cole um state real e monte as perguntas na primitiva certa. Pega um caso feio do seu domínio, daqueles ambíguos, e não um exemplo bonitinho. O erro comum deste passo: usar state de brinquedo. State limpo faz qualquer modelo parecer genial

3. Crie a API key no dashboard e exponha em TYPESAFE_API_KEY. A chave é criada no dashboard do console e usada por essa variável de ambiente

export TYPESAFE_API_KEY="sua_chave_aqui"

# Python
pip install typesafe-sdk

# JavaScript / TypeScript
npm install @typesafe-ai/sdk

Se você já passou por esse ritual lendo a documentação da Claude API, é a mesma dança: chave, variável de ambiente, primeiro request. O erro comum deste passo: chave hardcoded no arquivo e commitada. Tome cuidado com isso, beleza? 😅

4. Reproduza o MESMO state e as MESMAS perguntas via API. O endpoint HTTP é POST https://api.typesafe.ai/v1/systemone, com header Authorization: Bearer <API_KEY> e Content-Type: application/json. No corpo, as perguntas vão num map com ids escolhidos por você, e as respostas voltam uma por pergunta, com as mesmas chaves

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @request.json

O request.json leva o state e o map de perguntas com os seus ids, exatamente o que você montou na tela. O erro comum deste passo: mudar a pergunta na hora de portar pro código. Aí quando o resultado diverge você não sabe se foi o canal ou a formulação

5. Rode um lote rotulado e escolha thresholds conservadores. Sem exemplos rotulados você não está escolhendo threshold, está chutando. Comece apertado e afrouxe com dado na mão. O erro comum deste passo: caçar um número universal tipo "0.8 tá bom". Não existe: o corte sai do custo do erro no SEU domínio, e cada ação pode ter o seu

6. Mantenha fluxo, regras determinísticas e efeitos colaterais no código. O padrão que a TypeSafe recomenda é esse: código no controle, Jev só onde precisa de julgamento. O erro comum deste passo: transformar em pergunta de modelo aquilo que é um if. Se a regra é "valor acima de X vai pra revisão", isso é código, não julgamento

Sem acesso direto? Onde mais dá para testar o Jev

Aqui tem um detalhe chato de calendário

Os signups diretos foram abertos pra todo mundo em 20/09/2026 com US$ 5 de crédito grátis, e foram pausados em 22/09/2026 por excesso de demanda. A TypeSafe afirmou que as contas já criadas seguem funcionando e que trabalha pra reabrir o acesso

Até 24 de setembro de 2026 não teve anúncio de reabertura. A orientação prática é checar o console você mesmo, em vez de confiar em terceiro dizendo que reabriu

Enquanto isso, existem outros caminhos:

• Vercel AI Gateway, com o model id typesafe-ai/jev. A página do modelo no Gateway reúne API, preço e playground do modelo, e a chamada pode sair via AI SDK com experimental_evaluate, via cliente TypeSafe existente ou pela API HTTP do próprio Gateway
• Cloudflare Workers AI, que também serve o Jev, com o id typesafe/jev

Se o seu objetivo é só sentir o formato da resposta antes de decidir qualquer coisa, esses caminhos já resolvem

Veredito: a ordem que economiza tempo

Playground pra formato

API pra decisão de produto

É isso, e é nessa ordem. O Playground não consegue te dizer se o Jev entra no seu produto, porque a coisa que decide isso (threshold contra dado rotulado, custo agregado, latência da sua região) só existe depois que a chamada está no seu código

E o contrário é pior: escrever integração pra descobrir no terceiro dia que a pergunta deveria ser um Noul e não um Score

Sobre os números que circulam: a TypeSafe reporta até 193,6x mais rápido e 444,6x mais barato que LLMs nas avaliações de workflow feitas por ela. É número do fornecedor, não medição independente. Serve pra despertar interesse, não pra fechar decisão

O argumento forte do Jev é outro, e é técnico: as probabilidades são calibradas, otimizadas contra resultados reais pra refletir incerteza, com probabilidade maior correspondendo a maior chance de a resposta estar correta. Elas foram feitas pra serem consumidas por código

E é exatamente por isso que a validação final mora no código, não na tela 🙂

Vídeo do canal:

Como o SDK oficial em JavaScript/TypeScript é o caminho mais comum de integração, vale reforçar a base da linguagem. Pra começar do zero, este vídeo do canal mostra onde praticar TypeScript:

Conclusão

Recapitulando o que importa aqui

Comece pela pergunta, não pela integração. Primitiva certa (Choice, Noul ou Score), julgamento quebrado em perguntas estreitas, campos da resposta entendidos. Isso é Playground

Depois vá pro código: chave em TYPESAFE_API_KEY, mesmo state, mesmas perguntas no POST /v1/systemone, lote rotulado e threshold escolhido com o custo do erro na mesa

Próximo passo concreto pra hoje: abra console.typesafe.ai e veja como está a disponibilidade de signup, e antes de cravar qualquer threshold, leia a página de jaggedness do jev-1.13

É um modelo novo, de uma empresa nova (a TypeSafe AI foi fundada em 2024 por Diogo Almeida, Erik Gafni e Sasha Sheng, com Almeida como CEO depois de cerca de quatro anos na OpenAI), com uma proposta bem diferente de tudo que a gente vinha plugando

Vale a curiosidade, vale o teste, e vale medir você mesmo

Até o próximo post!