Cache de recall

Recalls repetidos, por um décimo do preço.

Ative por solicitação e o WOS armazena em cache o resultado da busca sob o texto da consulta, com as mesmas regras de prefixo do prompt caching dos LLMs. Enquanto o cache está quente, uma consulta repetida ou estendida reutiliza o resultado anterior, e a parte em cache é cobrada a 10% da tarifa normal por token.

Apenas Tablet e Scroll. O cache funciona em todos os modelos Tablet e Scroll, atuais e futuros. O Book não o suporta: o Book raciocina sobre suas memórias e aprende entre as chamadas, então a mesma pergunta pode legitimamente voltar com uma resposta diferente, e um resultado em cache seria errado por design. Enviar cache_control ao Book retorna um 403 claro.

Uma conversa, três turnos

É isto que realmente acontece quando um agente continua conversando com sua memória. Cada turno envia a conversa acumulada como consulta, com cache_control ligado.

writeTurno 1 - “Alice: Eu me mudei para Lisboa na primavera passada.”

A consulta inteira é buscada e armazenada em cache: entrada a 2x (TTL de 5 minutos).

extendTurno 2 - o mesmo texto mais “Bob: Como está o clima aí?”

Só a frase do Bob é indexada e buscada. A parte antiga custa 0,1x, a frase nova 2x, e o cache agora termina nela.

hitTurno 3 - exatamente a mesma consulta de novo (um retry, um refresh)

Nenhuma chamada ao motor. Tudo a 0,1x: o desconto de 90%.

As tarifas

Operação	Cobrança de tokens	O que significa
Escrita de cache - TTL 5 minutos	2×	A primeira solicitação. Seu resultado é mantido por 5 minutos, e cada leitura desliza a janela para frente.
Escrita de cache - TTL 1 hora	3×	A primeira solicitação, mantida por uma hora inteira.
Leitura de cache - acerto ou acerto de prefixo	0.1×	Toda solicitação após a escrita: a parte em cache custa um décimo da tarifa normal por token.

Quanto isso economiza

Um exemplo concreto: seu agente envia uma conversa de 3.000 tokens como consulta e a repete ou continua 10 vezes em cinco minutos. Sem cache, são 30.000 tokens de entrada a preço cheio. Com um cache de 5 minutos, são 6.000 pela primeira escrita (2x) mais cerca de 2.700 pelas nove leituras em cache: 8.700 tokens cobrados, 71% menos. Quanto mais longa a conversa, maior a economia.

A regra do prefixo

A correspondência é feita no início da consulta. Se o início permanece idêntico e apenas texto novo é acrescentado ao final, a parte em cache é reutilizada e apenas a parte nova é buscada. Se algo muda antes do fim do texto em cache, nada pode ser reutilizado.

prefix match

cached    [ A B C D E F G ]

○   [ A B C D E F G ] E
✗   [ B C D E F G ] E

○ acerto - o início não mudou, E é a única parte nova
✗ erro - o início mudou, então a consulta inteira é buscada e armazenada em cache novamente

Três regras para lembrar

Estender rearmazena até a nova cauda. Depois de [A B C D E F G] + E, o cache agora termina em E: a cauda é cobrada uma vez na tarifa de escrita, e o próximo turno pode casar todo o A..E como prefixo de novo.
Um único prefixo contíguo por solicitação. Uma consulta não pode ser dividida em dois segmentos de cache; apenas o seu início pode casar.
Escritas invalidam na hora. Qualquer store, store-turn, bulk-store, forget, supersede ou exclusão do store descarta o cache dele, então uma resposta em cache nunca pode ficar obsoleta.

Como ativar

   
hits = mem.search(
    "...the conversation so far...", user_id="alice",
    cache_control={"ttl": "5m"},   # or "1h"
)
const hits = await mem.search(
  "...the conversation so far...", "alice", 10,
  { cache_control: { ttl: "5m" } },   // or "1h"
);
let hits = mem.search_with(
    "...the conversation so far...", "alice", 10,
    serde_json::json!({"cache_control": {"ttl": "5m"}}),   // or "1h"
).await?;
curl -X POST https://api.wontopos.com/api/v1/memory/search \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice",
       "query":"...the conversation so far...",
       "cache_control":{"ttl":"5m"}}'   # or "1h"

Resposta - o objeto cache informa o que aconteceu

{ "memories": [ ... ],
  "cache": { "status": "hit",              // "write" | "hit" | "extend"
             "ttl": "5m",
             "cache_read_input_tokens": 412,
             "cache_creation_input_tokens": 0 } }

Você não precisa de um SDK para nada disso. O caching é um campo em uma chamada HTTP, então funciona a partir de qualquer linguagem de programação. A aba curl é a receita universal, e os SDKs de Python, TypeScript e Rust são apenas invólucros de conveniência sobre exatamente a mesma chamada.

O cache é isolado por store e por modelo dentro do seu workspace, e vem desligado por padrão: sem cache_control, nada muda nas suas solicitações.

Product

Models

Start