Jev síncrono ou em fila: chamar na hora ou processar em lote?

Fala aí, beleza? Tem uma decisão que você toma ANTES da primeira linha de código, e ela persegue o projeto inteiro: onde a chamada ao modelo entra no seu sistema

Se ela mora no caminho da requisição do usuário, você compra latência percebida e um ponto de falha novo

Se ela mora num worker, você compra complexidade de infra e um resultado que chega depois

O Jev é o primeiro modelo System One da TypeSafe AI, anunciado em 15 de setembro de 2026 e ainda em early access por waitlist. Ele não gera texto: avalia perguntas tipadas contra um state e devolve decisões tipadas (Noul, Choice e Score) com probabilidade e confiança. E é justamente por causa disso que essa escolha de arquitetura fica diferente do de sempre…

O que muda no desenho porque o Jev não é um chat

Com LLM de texto, o padrão mental é: stream, token a token, usuário olhando a resposta nascer

Com o Jev não tem stream pra disfarçar espera. A resposta é um objeto tipado, ou você tem a decisão ou não tem

O retorno vem em três primitivas: Noul (sim/não probabilístico), Choice (uma opção de um conjunto) e Score (escala ou rubrica ordenada), sempre com probabilidades junto. Isso é um dado que seu código consome direto no if, sem parsing de texto no meio do caminho

A chamada também é diferente. Não é /chat/completions, é rota própria de System One: um POST único em https://api.typesafe.ai/v1/systemone, com o body carregando o state, o model e um mapa de perguntas

E se liga nisso, porque é o detalhe que sustenta o resto do post: todas as perguntas de uma mesma requisição são avaliadas em paralelo e de forma isolada contra o mesmo state. Uma pergunta não influencia a outra

Dois números da TypeSafe fecham o cenário:

• latência ponta a ponta reportada de 70 ms a 500 ms, que é o que torna o síncrono defensável
• preço de US$ 0,042 por milhão de tokens de entrada e US$ 0,00 por milhão de tokens de saída, que muda a conta quando o volume cresce

Com saída de graça, o que você paga é basicamente o tamanho do state que sobe. Guarde isso, porque é o argumento central do meio-termo lá na frente

Síncrono x fila: comparação lado a lado

Quando chamar o Jev no caminho da requisição

O critério é um só: a decisão é insumo da resposta HTTP e o usuário já está parado esperando

Se o resultado do modelo define o que vai na tela agora, adiar não resolve nada, só transforma uma espera em dois estados na interface

Os casos clássicos:

• Moderação antes de publicar: o comentário sobe ou não sobe, não tem meio termo pra mostrar pro usuário
• Roteamento de ticket na abertura: o cliente termina o formulário e já quer saber pra onde foi
• Liberar ou barrar uma ação na tela: aprovar um saque, permitir um upload, soltar um desconto
• Validação de formulário que depende de julgamento e não de regex

Aqui entra a parte boa: como as perguntas rodam em paralelo e isoladas, adicionar perguntas quase não altera o tempo de resposta, porque o state é enviado uma vez só

Ou seja, no mesmo POST que pergunta "isso é spam?" você pergunta "tem dado sensível?", "qual a categoria?" e "qual a gravidade de 1 a 5?"

O esqueleto no SDK Python oficial é o cliente síncrono, direto no handler:

from typesafe_sdk import TypeSafeClient

# lê TYPESAFE_API_KEY do ambiente e usa jev-latest como modelo padrão (TYPESAFE_DEFAULT_MODEL)
with TypeSafeClient() as client:
    ...

Repare no jev-latest: ele é o modelo padrão do SDK, definido em TYPESAFE_DEFAULT_MODEL, e não um modelo à parte. Os números de preço e de teto de tokens que eu cito no post são da ficha do jev-1.13, então se você quer previsibilidade, deixe a versão explícita na config em vez de ficar no apelido

Tome cuidado com outra coisa: síncrono sem timeout curto é convite pra thread pendurada. Defina o timeout e defina o que acontece quando ele estoura, antes de subir pra produção

Quando jogar para um worker assíncrono

Agora o outro lado. Se ninguém está olhando a tela esperando aquela decisão, prender uma conexão HTTP é desperdício

Cenários onde a fila ganha fácil:

• reprocessar backlog histórico (aqueles 800 mil registros que ninguém classificou ainda)
• enriquecer uma base inteira de documentos com Score e Choice
• jobs noturnos de recategorização
• pipelines de ingestão, onde o dado entra bruto e sai rotulado
• qualquer fluxo em que a espera simplesmente não é visível pro usuário

O critério aqui é volume alto, pico irregular ou necessidade de retentar sem segurar ninguém do outro lado. É a mesma lógica de processamento em lote via API, com o detalhe de que a fila é sua: o Jev só recebe o POST

No SDK Python, o caminho é o cliente assíncrono:

from typesafe_sdk import AsyncTypeSafeClient

async with AsyncTypeSafeClient() as client:
    ...

Instalação com pip install typesafe-sdk (Python 3.10+), e o cliente lê TYPESAFE_API_KEY do ambiente, com TYPESAFE_BASE_URL apontando pra https://api.typesafe.ai por padrão

Se seu worker já vive dentro de uma stack de abstração, dá pra não trocar de ferramenta: o LiteLLM tem provider pass-through da TypeSafe e o Pydantic AI documenta o modelo TypeSafe (Jev)

E tem os pontos de execução que talvez já façam parte da sua infra: o Jev está na Workers AI da Cloudflare, com binding próprio, e também no AI Gateway da Vercel, que cobra apenas tokens de entrada

Na Cloudflare a chamada fica no formato do binding mesmo:

const res = await env.AI.run('typesafe/jev', { /* state e perguntas */ });
// a resposta traz "model": "jev-1.13.0", que é o mesmo jev-1.13 citado no post, com o patch no nome

O meio-termo que quase ninguém considera: lote de perguntas na mesma chamada

Aqui mora a sacada que muita gente perde nessa discussão

"Em lote" não precisa significar "depois". Pode significar juntar perguntas na mesma requisição, agora

No cookbook de perguntas paralelas da TypeSafe, com 13 perguntas sobre um artigo longo, juntar tudo em uma chamada saiu 12,2x mais barato e 10,0x mais rápido que fazer 13 chamadas separadas. As respostas foram idênticas entre as repetições, com desvio padrão 0,0 na maioria dos casos

Esses números são da TypeSafe e daquele cenário específico do cookbook, não uma promessa geral pro seu state. Mas a lógica por trás é simples e vale pra todo mundo: o state sobe UMA vez, e o state é o que você paga

Porém, tem teto. E é bom conhecer antes de sair empilhando pergunta:

• 64k tokens para o state mais todas as perguntas juntas
• 32k tokens para o state mais a pergunta mais longa

Acima disso a requisição falha com erro max_tokens_exceeded (jev-1.13). A ficha do modelo no OpenRouter lista janela de contexto de 32.000 tokens para o Jev 1.13

Na prática isso vira uma regra de desenho: quebre o lote por tamanho de state, não por número de perguntas

Quando o volume estoura: 429, 529 e o que cada desenho faz

O sintoma: sob carga, parte das requisições começa a falhar. Não é bug no seu prompt, é limite

A causa: dois códigos diferentes, com significados diferentes

• 429 Too Many Requests: você bateu o rate limit da conta. No early access são 250.000 tokens por segundo e 1.200 requisições por minuto, e a própria TypeSafe avisa que esses limites são ajustados dinamicamente (maiores em planos custom/enterprise)
• 529 Overloaded: sobrecarga temporária do lado do Jev. Aqui não é limite da sua conta nem erro do seu código, é o serviço pedindo pra você voltar depois

A solução é a mesma pros dois: retry com backoff exponencial, que é a orientação oficial. Os SDKs oficiais já fazem retry com backoff honrando o header retry-after, então em boa parte dos casos você não escreve isso na mão

No SDK Python dá pra ajustar a política, inclusive desligar:

# desativa o retry automático
RetryPolicy(max_retries=0)

E o timeout é configurável, herdando http_client.timeout quando você fornece o próprio client HTTP

Agora a parte que separa os dois desenhos, que é COMO cada um reage a isso:

• No síncrono, backoff longo é veneno. O usuário não vai esperar três tentativas. Aqui a receita é timeout curto, poucas tentativas e um caminho de fallback definido (regra conservadora, fila de revisão manual, o que fizer sentido no seu produto)
• Na fila, o backoff é seu amigo. Deixa ele trabalhar, a mensagem volta pro buffer e o pico é absorvido. Você troca tempo por resiliência, e tempo é exatamente o que sobra nesse desenho

Já vi gente copiar a política de retry do worker pro handler HTTP e se perguntar por que a página demora 8 segundos pra carregar. Não faça isso 😅

Veredito: qual desenho escolher para o seu caso

Vou ser direto, três perguntas resolvem a maioria dos casos:

1. A decisão bloqueia a resposta ao usuário? Se sim, síncrono. Ponto
2. O volume cabe nos limites atuais da conta? Se você está perto dos 250.000 tokens por segundo ou das 1.200 requisições por minuto em horário de pico, fila
3. Existe tolerância a espera? Se existe, fila quase sempre sai mais barata de operar

Por perfil:

• Produto com decisão na tela (moderação, aprovação, roteamento): síncrono, com TypeSafeClient, timeout curto e fallback definido
• Pipeline de volume (ingestão, backlog, enriquecimento): fila, com AsyncTypeSafeClient ou via LiteLLM/Pydantic AI, deixando o backoff cuidar dos 429 e 529
• Híbrido (a maioria, na real): síncrono no caminho crítico com o menor state possível, fila pra tudo que é retroativo e pra reprocessamento. Mesmo conjunto de perguntas, dois caminhos de execução

E antes de fechar qualquer coisa, olhe pra qual variante do modelo você vai usar, do mesmo jeito que você faria ao escolher entre variantes de uma família de modelos: o teto de tokens e a janela de contexto são dados por versão

Último lembrete e ele é importante: o Jev segue em early access, com limites ajustados dinamicamente. Arquitetura que assume número fixo de rate limit vai quebrar em algum momento. Faça o desenho tolerar mudança, com o limite vindo de config e não de constante no código

Vídeo relacionado

Pra quem quer ver automação com IA entrando no fluxo de desenvolvimento na prática, o vídeo abaixo mostra como o Claude Code melhora sozinho com o Autoresearch:

Conclusão

A regra de decisão cabe em uma linha: se a decisão bloqueia a resposta ao usuário, chame na hora; se não bloqueia, mande pro worker e deixe o backoff trabalhar

E lembra do meio-termo, que resolve mais caso do que parece: agrupar perguntas no mesmo POST, já que o state sobe uma vez só e é ele que você paga

Próximo passo concreto: entre na waitlist em typesafe.ai, pegue a chave na seção de keys do console.typesafe.ai, rode pip install typesafe-sdk e prototipe o MESMO conjunto de perguntas nos dois desenhos antes de fechar a arquitetura

Meia hora de protótipo economiza uma refatoração inteira depois… 🙂

até o próximo post!