Inbox do Obsidian entupida: como usar o Jev para decidir o destino de cada nota solta?

fluxo do Jev Obsidian decidindo o destino de notas soltas da inbox
Resposta rápida

Usar o Jev no Obsidian resolve um problema específico: decidir o destino de cada nota solta da pasta de entrada, sem gerar texto nenhum. O Jev é o modelo System One da TypeSafe AI, recebe um state e perguntas tipadas (Noul, Choice e Score) e devolve resposta estruturada com probabilities e confidence, tudo num POST para https://api.typesafe.ai/v1/systemone. A parte que decide a qualidade da triagem não é o código: é a lista de destinos escrita antes, com o que entra, o que não entra, exemplos e uma opção de escape. O resto é ler o confidence e mandar o duvidoso pra revisão humana.

Fala aí, beleza? Abre a pasta Inbox do teu vault do Obsidian agora e conta quantas notas tem lá dentro

Se passou de trinta, tu já sabe no que deu: ninguém revisa mais, e a pasta virou cemitério de ideia boa

O detalhe é que o problema aqui não é escrever nada. É DECIDIR: essa nota vira tarefa? vira nota permanente? junta com uma que já existe? ou some?

E decisão tipada é exatamente o que o Jev faz. Ele é o primeiro modelo System One público da TypeSafe AI: em vez de gerar texto, ele recebe um estado e perguntas tipadas, e devolve respostas estruturadas com probabilidades e confiança que o teu código usa direto num if

Ou seja: ele não escreve a nota por você, ele vota o destino dela

Bora montar esse fluxo? E se liga que o passo mais importante acontece ANTES de qualquer linha de código

O que você precisa antes de começar:

  • Um vault do Obsidian com uma pasta de entrada definida (Inbox, 00 Inbox, tanto faz, só precisa ser uma só)
  • A chave da API: no console da TypeSafe, em console.typesafe.ai, abrir API Keys, criar a chave e guardar na variável de ambiente TYPESAFE_API_KEY, que vai como Bearer token no header Authorization
  • O modelo: jev-1.13 (id versionado) ou o alias jev-latest, que acompanha a versão mais nova
  • O endpoint, que é um só: POST https://api.typesafe.ai/v1/systemone

Sobre custo, é simples de engolir: o Jev é cobrado somente por token de entrada, US$ 0,042 por milhão de tokens de input, e o output sai sem custo

E o acesso hoje, tá aberto?

Aqui vai o aviso honesto, porque a linha do tempo foi corrida

O lançamento foi em 15/09/2026 com waitlist, em 20/09 a waitlist caiu e o cadastro abriu pra qualquer pessoa com US$ 5 de crédito inicial, e em 22/09/2026 a TypeSafe pausou novos cadastros por excesso de demanda

Contas já criadas continuam funcionando normalmente, e a empresa diz que trabalha pra reabrir o acesso

Se tu não tem conta no console, o Jev também está disponível fora dele: no Vercel AI Gateway e no OpenRouter, onde o typesafe/jev-1.13 é servido por um endpoint de decisions próprio (não é o chat/completions de sempre), com o mesmo preço publicado de US$ 0,042 por milhão de input e US$ 0 de output

Se você vai codar isso com agente:

Existe skill oficial da TypeSafe. No Claude Code:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Depois de instalar, reinicia o Claude Code ou roda /reload-plugins, e o comando /typesafe:typesafe-ai já pode ser chamado direto

Em outros agentes, a alternativa é:

npx skills add typesafe-ai/skills --skill typesafe-ai

Passo a passo: da lista de destinos ao triador rodando

  1. Escreva os destinos possíveis antes de escrever código

Esse é o passo que define se a triagem presta ou não. Não é o prompt, não é o modelo, é a LISTA

Um bucket bom tem quatro coisas: nome, o que entra, o que não entra e exemplos. E a doc do Choice orienta justamente isso: pergunta completa no campo instructions, lista completa de opções, e uma opção de escape tipo other / none of the above pra quando a entrada não couber em nada

Os formatos estruturados em JSON são aceitos (descrição de opção com what, not_for, examples), o que ajuda demais a separar bucket de bucket. Guarda esse arquivo num canto, porque ele vai entrar INTEIRO dentro da pergunta Choice lá no passo 5:

{
  "archive": {
    "what": "nota de referência já completa, que só precisa ser guardada e encontrada depois",
    "not_for": "nota que pede uma ação minha, ou fragmento que só faz sentido colado em outra nota",
    "examples": ["resumo de artigo lido", "trecho de doc copiado com a fonte"]
  },
  "task": {
    "what": "nota que descreve algo que EU preciso fazer, com ação implícita ou explícita",
    "not_for": "ideia sem dono, anotação de estudo, referência",
    "examples": ["ligar pro contador sobre a nota fiscal", "testar o plugin X no vault"]
  },
  "merge": {
    "what": "fragmento curto que continua um assunto que já tem nota permanente no vault",
    "not_for": "assunto novo que ainda não existe em lugar nenhum",
    "examples": ["uma linha solta sobre um tema já coberto"]
  },
  "discard": {
    "what": "nota sem conteúdo aproveitável: duplicada, teste, rascunho vazio",
    "not_for": "qualquer coisa que eu ainda possa querer ler de novo",
    "examples": ["Untitled vazia", "colagem duplicada"]
  },
  "other": {
    "what": "não encaixa em nenhum dos anteriores, vai pra revisão humana"
  }
}

O erro comum deste passo: destinos que se sobrepõem. Se "arquivar" e "juntar" aceitam a mesma nota, a culpa da confusão é tua, não do modelo. O not_for existe pra isso, usa ele com raiva 😀

É a mesma disciplina de quem usa o Jev pra qualificar leads no funil: o modelo escolhe bem, mas a lista é responsabilidade tua

  1. Monte o state com o conteúdo da nota

O state é "o que olhar". Pra triagem de vault, o mínimo que funciona é o caminho do arquivo, o título e o corpo em markdown

Se teu vault tem nota gigante, corta. O orçamento de contexto é de 64k tokens por requisição, cobrindo o state mais todas as perguntas somadas, com 32k valendo pro state mais a pergunta mais longa

O erro comum deste passo: jogar a nota inteira de 40 páginas e ainda anexar cinco perguntas grandes. Estourou o orçamento, quebrou o pipeline no meio do lote

  1. Escolha a primitiva certa pra cada decisão

São três tipos de pergunta na API, e cada um responde uma coisa diferente:

Primitiva Pra que serve O que volta
Noul afirmação sim/não probabilidade de ser sim, entre 0 e 1 (sem campo de confidence separado)
Choice escolher uma opção de um conjunto definido choice, probabilities por opção e confidence
Score posicionar em níveis ordenados e descritivos definidos por você score, probabilities por nível e confidence

O Noul não tem confidence separado porque a distribuição tem só dois resultados, a própria probabilidade já conta a história

Pro destino da nota, é Choice. Sem dúvida

O erro comum deste passo: tentar usar Score pra destino. Destino não é escala, é conjunto. Score é pra coisa que tem ORDEM (urgência, maturidade), onde a resposta pode legitimamente cair entre dois níveis

  1. Confirme a chave no ambiente
export TYPESAFE_API_KEY="sua-chave-do-console"

O erro comum deste passo: commitar a chave dentro do script de triagem que tá no mesmo repo do vault sincronizado. Já vi história assim terminar mal, guarda no ambiente e pronto

  1. Monte o request com state, model e questions

Cada requisição carrega três coisas: state (o que olhar), model (qual modelo olha) e questions (um mapa dos julgamentos a fazer)

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

E o request.json segue essa espinha:

{
  "state": "caminho: Inbox/ideia-solta.md\n\n# Titulo da nota\n\ncorpo da nota em markdown...",
  "model": "jev-1.13",
  "questions": {
    "destino": {
      "instructions": "Para qual destino esta nota da Inbox deve ir? Escolha uma opcao considerando o que entra e o que nao entra em cada uma.",
      "<campo de opcoes do Choice>": {
        "archive": { "what": "...", "not_for": "...", "examples": ["..."] },
        "task": { "what": "...", "not_for": "...", "examples": ["..."] },
        "merge": { "what": "...", "not_for": "...", "examples": ["..."] },
        "discard": { "what": "...", "not_for": "...", "examples": ["..."] },
        "other": { "what": "..." }
      }
    }
  }
}

Duas coisas pra reparar aqui

A primeira: o state carrega o caminho do arquivo junto com o título e o corpo, igualzinho ao que combinamos no passo 2, senão tu recebe o voto e não sabe qual nota mover

A segunda: aquele <campo de opcoes do Choice> é PLACEHOLDER, não é nome de campo de verdade. É ali que a lista de destinos do passo 1 entra inteira, com what, not_for e examples, porque a doc orienta dar a lista completa de opções no Choice e deixar a pergunta completa no instructions

O nome exato desse campo (e dos campos de cada tipo de pergunta) tá na doc de primitives, confere lá antes de colar

O erro comum deste passo: pedir resumo junto. O Jev não é indicado pra escrever, resumir, aritmética precisa nem entrada de imagem. Ele julga, não redige

  1. Leia choice, probabilities e confidence

A resposta do Choice traz a opção escolhida em choice, uma probabilidade pra CADA opção em probabilities, e um confidence de 0 a 1

Esse confidence é o atalho: ele colapsa a forma da distribuição num número único, pro teu código aplicar um limite sem fazer a matemática na mão

O erro comum deste passo: olhar só o choice e ignorar o resto. Aí você trata um empate de 0,34 contra 0,33 como se fosse certeza absoluta

  1. Aplique o limite de confiança e mande o resto pra revisão humana
if answer["confidence"] >= 0.8:
    mover_para(destinos[answer["choice"]])
else:
    mover_para("Inbox/_revisar")

Duas coisas caem em _revisar: confidence abaixo do teu limite e qualquer resposta other

O erro comum deste passo: automatizar o discard como delete de verdade logo de cara. Faz o discard MOVER pra uma pasta, nunca apagar, pelo menos até você confiar no fluxo

  1. Rode em dez notas antes de deixar mexer no vault inteiro

Seleciona dez notas que você conhece bem, roda o triador em modo leitura (só imprimindo o destino sugerido) e compara com o que você faria

Se duas ou três destoarem, quase sempre a correção é no not_for do bucket, não no código

Bateu nas dez? Então o triador tá de pé: agora sim tu solta ele na Inbox inteira, com o discard só MOVENDO de pasta, tudo abaixo do teu limite caindo em _revisar e o objeto usage logado pra tu saber o gasto do lote 🙂

Além do destino: outras perguntas que valem na mesma requisição

Se liga nisso, que é onde a economia aparece: uma mesma requisição pode conter VÁRIAS perguntas sobre o mesmo state

O estado é ingerido uma vez e avaliado contra todas as perguntas, que são respondidas de forma independente e em paralelo

Então, na mesma chamada que decide o destino, tu pode perguntar também:

  • Noul: "esta nota contém segredo, credencial ou chave de API?", com a probabilidade entre 0 e 1 voltando direto. Esse mesmo tipo de julgamento sim/não é a base de quem usa Jev pra moderar conteúdo enviado por usuários
  • Score: urgência ou maturidade da nota, em níveis ordenados que VOCÊ descreve ("rascunho bruto", "esboço com estrutura", "pronta pra publicar"), e a resposta pode cair entre dois níveis
  • Choice: o destino, que é o prato principal aqui

O estado é o mesmo, a nota não é lida quatro vezes

E pra acompanhar o custo sem chute: toda resposta traz um objeto usage com input_tokens e output_tokens, e só a entrada é faturada. Loga esse objeto no teu script e você sabe exatamente o que o lote gastou

A TypeSafe afirma inferência até 200x mais rápida e custo até 400x menor que LLMs comparáveis em tarefas de classificação. É afirmação da empresa, então trata como afirmação da empresa, mas o usage do teu próprio lote é dado teu, e esse não mente

Vídeo: Claude Code + Obsidian na prática

Pra começar do zero com agente mexendo no vault do Obsidian, esse vídeo do canal mostra o método Karpathy aplicado no Claude Code, que é a base de trabalho pra qualquer automação em cima das tuas notas

Projetos que já fazem isso (e o que copiar deles)

Não precisa inventar a roda sozinho, já tem gente rodando esse tipo de fluxo

O jev-the-janitor é um projeto aberto de referência pra triagem de vault markdown. A divisão de trabalho lá é exatamente a que eu descrevi: o Jev vota o bucket de cada nota, o código do usuário arquiva, e a pilha de baixa confiança fica pra revisão humana

E o que vale MUITO copiar dele é o que ele se recusa a fazer: o projeto não deleta nem reescreve o corpo da nota. No máximo adiciona um bloco de frontmatter, ou move um suspeito de segredo pra uma pasta de quarentena

Isso é guardrail de verdade, não é frescura. Teu vault é memória, memória não se sobrescreve no automático

Pra quem quer algo menor e dentro do próprio app, já existe plugin comunitário: o Auto Tagger (Jev), do autor parthsidpara, que sugere ou aplica uma tag na nota aberta usando o Jev e as tags que já existem no vault

Vale a distinção: tag é metadado, destino é movimento de arquivo. Se você só quer organizar por assunto sem mexer de pasta, o caminho da tag é bem mais tranquilo

E deixa registrado pra não gerar confusão: o que existe hoje entre Jev e Obsidian são projetos e plugins de COMUNIDADE, não integração oficial

Comece pela lista de destinos, não pelo código

Se eu puder deixar uma frase só desse post, é essa: a qualidade da triagem vem da definição dos buckets e do limite de confiança, não do prompt

Gente boa em vibe coding às vezes pula direto pro curl e fica caçando "o prompt certo" por uma hora, quando o problema é que "arquivar" e "juntar" tão descritos igual 🙂

Teu próximo passo concreto é chato e curtinho: abre um arquivo, escreve os quatro destinos com what, not_for e examples, coloca a opção de escape, e roda UMA requisição em dez notas antes de deixar qualquer script mover arquivo de lugar

Dois lembretes pra fechar: novos cadastros no console seguem pausados desde 22/09/2026 (contas existentes funcionam normal, e tem o caminho do Vercel AI Gateway e do OpenRouter), e o Jev não é pra escrever, resumir, fazer aritmética precisa nem ler imagem

Ele é pra decidir. E decidir é justamente o que tua Inbox tá esperando faz meses…

até o próximo post!

Perguntas frequentes

O Jev consegue decidir o destino de várias notas numa única requisição?

Sim, mas dentro de uma mesma requisição o que se repete são as perguntas sobre um state, não várias notas soltas. Você pode mandar um state (a nota) com várias questions ao mesmo tempo, tipo uma Choice pro bucket e uma Noul pra outra checagem, e o Jev ingere o estado uma vez e responde tudo em paralelo. Pra triar o vault inteiro, o normal é rodar uma requisição por nota, cada uma com seu conjunto de perguntas.

O Jev apaga ou reescreve o conteúdo da nota durante a triagem?

Não. No projeto de referência jev-the-janitor, o Jev só vota o bucket de cada nota, quem arquiva de fato é o código do usuário. No máximo o fluxo adiciona um bloco de frontmatter ou move uma nota suspeita de conter segredo pra uma pasta de quarentena, o corpo da nota fica intocado.

Existe algum projeto pronto pra usar como referência de triagem de vault com Jev?

Sim, o jev-the-janitor, no repositório kylehovance-ai/jev-the-janitor. Ele mostra o padrão votar com Jev, arquivar com código, deixar a pilha de baixa confiança pra revisão humana, que é basicamente o mesmo raciocínio do passo a passo deste post.

Já tem plugin de Obsidian pronto que usa o Jev pra organizar notas?

Tem um plugin comunitário chamado Auto Tagger (Jev), do autor parthsidpara, no repositório obsidian-auto-tagger-jev. Ele sugere ou aplica uma tag na nota aberta usando o Jev e as tags que já existem no seu vault, é um passo mais simples que o triador completo deste post.

Pra que o Jev não serve dentro de um fluxo de organização de notas?

O Jev não é indicado pra escrever texto, resumir conteúdo, fazer aritmética precisa ou processar entrada de imagem. No fluxo de triagem de vault, isso quer dizer que ele decide o destino da nota, mas não vai gerar o resumo nem reescrever o markdown pra você.

Quanto custa rodar a triagem de um vault inteiro com o Jev?

O Jev cobra só pelo token de entrada, US$ 0,042 por milhão de tokens de input, e o output sai sem custo. Como o state de uma triagem de nota costuma ser pequeno (caminho, título e corpo em markdown), o custo por nota tende a ficar bem baixo mesmo processando o vault inteiro.




Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Claude Code

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

  • 120 aulas
  • 4 projetos
  • 9h 48min

Blog | Mais populares