O que enviar de uma nota markdown longa para o Jev (e o que cortar)?

Fala aí, beleza? A nota do teu vault tem 12 mil palavras, e o Jev quer um state pra devolver uma decisão tipada com probabilidade calibrada, não um textão

Aí vem a parte chata: manda o quê? Só o título? Os primeiros parágrafos? As tags? Os links? Um resumo gerado por outro modelo?

E tem um detalhe que a maioria inverte: o problema não é o limite de tokens

O problema é escolher o recorte que faz o modelo decidir CERTO

O Jev é o modelo System One da TypeSafe AI, anunciado em 19/09/2026: tu manda o conteúdo a avaliar mais perguntas tipadas, e ele responde com probabilidades calibradas em vez de prosa

Ele não escreve, ele decide

E decisão boa depende de contexto RELEVANTE, não de contexto grande… a própria documentação orienta incluir apenas o contexto relevante para as perguntas atuais, justamente pra evitar distração e context rot

Bora ver como recortar isso na prática? 😀

O que você precisa antes de montar o state

Nada de PC da Nasa aqui, é bem simples:

• Conta de API com acesso ao endpoint POST https://api.typesafe.ai/v1/systemone
• Um dos SDKs oficiais: typesafe-sdk no Python ou @typesafe-ai/sdk no JavaScript (ou chamada HTTP direta mesmo)
• As perguntas já definidas, e definidas de verdade: Choice escolhe uma opção de um conjunto, Score pontua contra níveis que você define, e Noul é uma proposição sim/não que devolve um valor entre zero e um
• Um punhado de notas reais do teu vault pra testar, de preferência as feias, as longas, as bagunçadas

Um aviso antes de começar: a entrada do Jev é somente texto

Imagem, áudio e vídeo não são suportados

Markdown é texto puro, então tá tudo certo, mas o PDF que tu linkou na nota não vai junto, e o print colado também não

Como decidir o recorte da nota, passo a passo

A ordem importa mais do que parece

Quase todo mundo começa pelo recorte e só depois pensa na pergunta… e aí fica testando tamanho de excerto no escuro

Inverte isso:

1. Escreva a pergunta antes do recorte

A documentação recomenda perguntas o mais explícitas, estreitas, específicas e atômicas possível, quebrando perguntas complexas em várias, cada uma avaliando uma propriedade

E é a pergunta que define o que é contexto relevante

"Essa nota é uma decisão de arquitetura?" pede os primeiros parágrafos

"Essa nota tem segredo hardcoded?" pede o corpo inteiro ou um scan local antes

"Qual tag combina melhor?" pede título, começo do corpo e a lista de tags candidatas

Perguntas diferentes, recortes diferentes

O erro comum deste passo: escrever uma pergunta guarda-chuva do tipo "essa nota é útil?" e depois jogar a nota inteira no state pra compensar a vagueza. Não compensa, só encarece

2. Estime o tamanho do recorte em tokens

No jev-1.13 o limite é de 32k tokens para o state mais a maior pergunta, e 64k para o state mais todas as perguntas juntas

O state é contado uma vez por requisição, o que muda bastante a conta quando você tem várias perguntas (já chego nisso)

Pra dimensionar antes de enviar, a estimativa publicada é de perto de 4 caracteres por token em prosa, e algo mais perto de 3 caracteres por token em JSON denso, cheio de ids e estrutura

def estimate_tokens(text: str, chars_per_token: float = 4.0) -> int:
    return int(len(text) / chars_per_token)

# prosa em markdown
estimate_tokens(note_body)

# state montado como JSON denso: use 3
estimate_tokens(json.dumps(state), chars_per_token=3.0)

O erro comum deste passo: estimar o corpo da nota e esquecer que o envelope conta. Título, nomes de campo, lista de tags candidatas, tudo isso entra no orçamento

3. Monte o recorte mínimo e estruture como objeto

O recorte mínimo costuma ser título + primeiros N caracteres do corpo + os metadados que a pergunta realmente usa

A documentação diz que o state pode ser string, objeto ou array JSON, e recomenda objetos estruturados para requisições não triviais, pra manter explícitas as relações entre os pedaços de contexto

Ou seja: quando tem mais de um pedaço, não concatena tudo num blocão de texto

{
  "title": "Migração do worker de fila para Rust",
  "excerpt": "Primeiros 2000 caracteres do corpo da nota...",
  "frontmatter": {
    "created": "2026-08-12",
    "existing_tags": ["infra", "rascunho"]
  },
  "candidate_tags": ["arquitetura", "infra", "pessoal", "estudo"]
}

Repara que cada coisa tem nome

O modelo não precisa adivinhar que aquele trecho do meio era uma tag

É a mesma lógica de cortar uma skill que virou manual: o que não serve à decisão só atrapalha

O erro comum deste passo: colar a nota inteira "só pra garantir". Garantir o quê? Você aumenta a chance de context rot e paga mais por isso

4. Mande todas as perguntas na mesma chamada

As perguntas rodam em paralelo contra o mesmo state, então a orientação oficial é mandar numa única chamada todas as perguntas que o teu código pode precisar

Como o state é contado uma vez por requisição, sete perguntas numa chamada custam MUITO menos que sete chamadas com o mesmo recorte repetido

O erro comum deste passo: fazer um loop de uma pergunta por chamada porque ficou mais fácil de escrever. Aí você multiplica o state pelo número de perguntas e ainda se aproxima do teto de 64k por outro caminho

5. Use pré-filtro com Noul quando a nota não cabe em recorte nenhum

Tem nota que é diário de seis meses, e aí nenhum "primeiros 2000 caracteres" resolve

O padrão documentado pra isso é quebrar a nota em chunks e fazer uma pergunta Noul por chunk ("esse trecho é relevante para X?"), mandando pra pergunta principal só os trechos que passaram

É um funil: primeiro o barato decide o que entra, depois o state final fica pequeno e afiado

O erro comum deste passo: juntar os chunks aprovados de qualquer jeito. O repositório jev-wide documenta que o merge ingênuo de chunks joga fora 83% do valor do reranking, medido no BEIR scifact

Três recortes que já rodam em projetos reais

Em vez de teorizar, dá pra olhar o que projetos abertos já escolheram mandar

E repara como cada recorte existe por causa da pergunta, nunca o contrário

Auto Tagger (Jev): título + começo do corpo + tags candidatas

O plugin Auto Tagger (Jev) para Obsidian, de parthsidpara, envia à TypeSafe o título da nota, os primeiros caracteres do corpo e os nomes das tags candidatas

Uma pergunta só, do tipo Choice: qual tag combina melhor?

O quanto do corpo vai junto é configurável em "Note body characters", contado a partir do início, com padrão de 2000 caracteres

Dois detalhes que eu acho muito massa nesse desenho: ele inclui a opção "None of these fit well" entre as alternativas, e mostra a tag escolhida junto da confiança do modelo numa notificação

Opção de escape evita que o modelo seja obrigado a chutar uma tag ruim

E confiança na tela deixa você calibrar o olho antes de confiar no automático

Se a tua lista de tags for gigante, vale pensar em como modelar a decisão com muitas opções, porque uma pergunta Choice aceita no máximo 255 opções e a opção 256 volta com erro 400

jev-the-janitor: excerto redigido + 7 perguntas tipadas

O jev-the-janitor, de kylehovance-ai, vai por outro caminho

Ele envia trechos da nota, redigidos localmente antes de sair da máquina, mais sete perguntas tipadas por nota: bucket, persist, secret, duplicate, decision, actionable e git-safe

Sete perguntas, um state só, uma chamada… exatamente o padrão do passo 4 lá em cima

E as ações são conservadoras de propósito: ele nunca apaga nem reescreve o corpo da nota

No máximo adiciona um bloco de frontmatter, ou move um suspeito de segredo pra _janitor/quarantine/<caminho relativo do vault>, registrando cada movimento em _janitor/quarantine/manifest.jsonl

Isso é o tipo de guardrail que eu gosto de ver: decisão automática sim, destruição de conteúdo não 😀

jev-wide: quando o recorte não cabe de jeito nenhum

O repositório jev-wide documenta que o limite real de uma chamada é de aproximadamente 32.768 tokens, e não só as 255 opções da Choice

Ou seja: o teto que te pega primeiro costuma ser o orçamento de tokens, não a contagem de alternativas

E é ali que mora o cuidado com o merge dos chunks que citei no passo 5

Como testar recortes diferentes sem chutar

Aqui tá o pulo do gato

Não existe (pelo menos publicado) uma comparação medida de acurácia entre mandar a nota inteira e mandar só o título, as tags ou um resumo

Então o recorte certo é o que funciona no TEU vault, com as TUAS perguntas

E isso se mede, não se chuta

A documentação descreve o caminho: monte um conjunto de avaliação com cerca de 100 registros reais ou anonimizados, classificados por avaliadores humanos, rode os mesmos registros pelo fluxo e compare as decisões, analisando falsos positivos, falsos negativos e desempenho em diferentes thresholds

Adaptado pra nota markdown, fica assim: pega ~100 notas, você (ou um colega) decide na mão qual é a resposta certa, e aí roda o mesmo conjunto variando SÓ o recorte

Rode os cinco, compare com o gabarito humano, e olhe os erros separados: falso positivo dói diferente de falso negativo quando o fluxo move arquivo

Depois plote confiança contra acurácia nos teus próprios dados pra escolher o threshold, como a própria documentação sugere

O racional é o código agir diferente pra resposta confiante e não confiante, escalando o caso incerto pra uma pessoa ou pra um modelo mais caro (o exemplo que aparece na doc é um corte em 0.8)

E tem duas variáveis que mudam junto com o tamanho do state, então anota elas na planilha:

• Custo: a cobrança é por token de entrada, US$ 0,042 por milhão (US$ 42 por bilhão), com tokens de saída gratuitos. Dobrar o excerto dobra a parte que você paga
• Latência: a TypeSafe reporta latência ponta a ponta entre 70 e 500 ms. Se o plugin roda a cada salvamento de nota, isso aparece na experiência

Tome cuidado com a tentação de olhar só a acurácia média: o recorte que acerta 2 pontos a mais e custa o dobro pode não valer a troca no teu fluxo

Quando dá HTTP 400 max_tokens_exceeded (e o que fazer)

Sintoma: a requisição volta com HTTP 400 e o corpo {"detail":{"error_type":"max_tokens_exceeded"}}

Costuma aparecer do nada, no meio de um fluxo que rodava bem, principalmente em sessão longa onde o state vai crescendo sem ninguém olhar

Tem caso real disso em projeto aberto: uma issue registra exatamente a sessão longa falhando com 400 porque o state passou do limite de 32k tokens

Causa: o state mais a maior pergunta passou dos 32k tokens do jev-1.13 (ou o state mais todas as perguntas passou dos 64k da requisição)

Vale lembrar que o context_window do Jev registrado no genai-prices, usado pelo Pydantic AI, é o limite de 32.000 tokens

Solução:

1. Corte o recorte de volta pro mínimo que sustenta a pergunta (título + excerto + metadados que importam)
2. Estruture o state como objeto JSON em vez de concatenar tudo, pra enxergar qual pedaço tá inchando
3. Se ainda não cabe, aplique o pré-filtro com Noul por chunk e mande só os trechos aprovados

Como prevenir: estime os tokens ANTES de enviar, com a regra de ~4 caracteres por token em prosa e ~3 em JSON denso

E trate o teto como teto, não como meta

Uma medição publicada no jev-1.13.0 mostra 32.878 tokens de entrada aceitos, com o tamanho seguinte já recusado com HTTP 400 max_tokens_exceeded

E entrada aqui é a mesma conta do passo 2, o state junto da maior pergunta, nunca o state sozinho

Ou seja: chegar perto do limite não é otimização, é viver na beirada… seu fluxo quebra no dia em que a nota cresceu um parágrafo

Conclusão

Recorte bom não é o maior nem o menor

É o MENOR recorte que ainda sustenta a decisão que você pediu

Recapitulando o caminho pra enviar uma nota markdown para o Jev sem sofrer: escreve a pergunta atômica primeiro, estima os tokens, monta o state como objeto com título, excerto e metadados relevantes, manda todas as perguntas numa chamada só, e usa pré-filtro Noul quando a nota for grande demais

O próximo passo é chato e é o que separa o fluxo que funciona do fluxo que parece funcionar: junta ~100 notas reais, classifica na mão, e mede DOIS recortes antes de soltar isso em cima do vault inteiro

Depois me conta qual recorte ganhou no teu caso, bora trocar uma ideia =)

até o próximo post!