State: o que você manda para o Jev avaliar

O state é o conteúdo que você pede ao modelo para avaliar. Pode ser uma mensagem de suporte, um trecho de documento ou o estado atual da sua aplicação. Ele vai em um campo próprio da requisição, ao lado das perguntas que você quer responder.

A regra estrutural é simples e vale memorizar: uma requisição, um state, várias perguntas. Todas as perguntas veem o mesmo state e são avaliadas de forma independente. Nada do que uma pergunta responde vira contexto para a outra. É essa independência que permite mandar dez perguntas de uma vez sem que elas se contaminem, como explicam as primitivas.

Os três formatos

A documentação recomenda o objeto para a maioria das requisições, por um motivo prático: cada parte ganha um nome descritivo, as relações ficam visíveis e as perguntas podem apontar para a parte certa. String serve quando o caso é simples de verdade.

Uma imagem mental que a documentação usa: pense no state como o material que você entregaria a um painel de especialistas antes de pedir um julgamento. Você entrega o que é necessário para decidir, organizado, e não a pasta inteira do cliente.

Um state pode ter várias partes

Este objeto é um state, mesmo contendo uma conversa, um pedido e uma política:

{
  "ticket": {
    "assunto": "Cobrança duplicada",
    "mensagens": [
      {"de": "cliente", "texto": "Fui cobrado duas vezes no pedido A-104. Quero o estorno da duplicada."},
      {"de": "suporte", "texto": "Estamos verificando as cobranças."}
    ]
  },
  "pedido": {
    "id": "A-104",
    "cobrancas": [
      {"valor_brl": 249, "status": "capturada"},
      {"valor_brl": 249, "status": "capturada"}
    ]
  },
  "politica_de_estorno": "Cobranças duplicadas dão direito a estorno."
}

Junte informações relacionadas quando a decisão exigir comparar essas partes. O caso acima é o exemplo perfeito: só dá para responder “a política sustenta o estorno?” com a política e as cobranças no mesmo state.

Separe conteúdo de pergunta

Essa é a distinção que mais economiza retrabalho. O state carrega o conteúdo e os fatos de apoio. As perguntas carregam o julgamento a ser feito. Se você se pegar escrevendo instrução dentro do state, ou colando conteúdo dentro da pergunta, o desenho saiu do trilho.

Com state estruturado, aponte a parte avaliada dentro da instrução, usando o caminho da chave entre crases:

questions = {
    "pediu_estorno": {
        "type": "noul",
        "instructions": "`ticket.mensagens[0].texto` pede estorno?",
    },
    "politica_sustenta": {
        "type": "noul",
        "instructions": (
            "`politica_de_estorno` sustenta o estorno pedido em "
            "`ticket.mensagens[0].texto`, considerando `pedido.cobrancas`?"
        ),
    },
}

O caminho explícito faz duas coisas: diz ao modelo o que julgar e documenta para o próximo desenvolvedor qual parte do state aquela pergunta usa.

Tamanho tem preço em acurácia, não só em token

Existe um limite técnico e existe um limite prático.

O técnico está na página oficial de modelos: 64 mil tokens por requisição no total, e 32 mil tokens para o state mais a pergunta mais longa. A documentação descreve esse orçamento como o equivalente a cerca de 150 mil caracteres de texto em inglês.

O prático é pior e aparece muito antes do limite: a documentação lista “state grande cheio de detalhe irrelevante” entre os modos de falha conhecidos do jev-1.13. Material sem relação com a decisão funciona como distrator, a acurácia cai, e fica mais difícil descobrir qual parte da entrada produziu a resposta errada. O nome que a documentação usa para o efeito é context rot.

As duas saídas recomendadas:

1. Filtrar em código antes. Recupere e selecione só os campos de que a pergunta precisa. É a opção padrão.
2. Filtrar com o próprio modelo. Quando não dá para filtrar antes, use um Noul de relevância por trecho e descarte o que não passa do limiar. A receita oficial de classificação de passagens de RAG faz exatamente isso.

O restante dos limites declarados da versão está em os limites do jev-1.13, e a visão geral da classe de modelos em o que é um modelo System One. O índice do vocabulário fica em conceitos.

Uma observação sobre português

A TypeSafe declara que o inglês é a língua principal de treino e onde a acurácia está melhor hoje, e que outras línguas são atendidas mas não igualmente bem. Isso não impede state em português — os nossos testes de 18 de setembro de 2026 rodaram com textos brasileiros e estão publicados com método —, mas reforça duas práticas: testar no seu próprio conteúdo e olhar a confiança antes de automatizar.