Recuperaciones repetidas, a la décima parte del precio.

Actívalo por solicitud y WOS almacenará en caché el resultado de búsqueda bajo el texto de la consulta, con las mismas reglas de prefijo que el prompt caching de los LLM. Mientras la caché está viva, una consulta repetida o extendida reutiliza el resultado anterior, y la parte cacheada se factura al 10% de la tarifa normal por token.

Una conversación, tres turnos

Esto es lo que ocurre realmente cuando un agente sigue hablando con su memoria. Cada turno envía la conversación acumulada como consulta, con cache_control activado.

Las tarifas

Cuánto ahorra

Un ejemplo concreto: tu agente envía una conversación de 3.000 tokens como consulta y la repite o continúa 10 veces en cinco minutos. Sin caché, son 30.000 tokens de entrada a precio completo. Con una caché de 5 minutos son 6.000 por la primera escritura (2x) más unos 2.700 por las nueve lecturas cacheadas: 8.700 tokens facturados, un 71% menos. Cuanto más larga la conversación, mayor el ahorro.

La regla del prefijo

La coincidencia se hace sobre el inicio de la consulta. Si el inicio se mantiene idéntico y solo se añade texto nuevo al final, la parte cacheada se reutiliza y solo se busca la parte nueva. Si algo cambia antes del final del texto cacheado, no se puede reutilizar nada.

cached    [ A B C D E F G ]

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

○ acierto - el inicio no cambió, E es la única parte nueva
✗ fallo - el inicio cambió, así que toda la consulta se busca y se cachea de nuevo

Tres reglas para recordar

• Extender vuelve a cachear hasta la nueva cola. Tras [A B C D E F G] + E, la caché ahora termina en E: la cola se factura una vez a la tarifa de escritura, y el siguiente turno puede volver a usar todo A..E como prefijo.
• Un solo prefijo contiguo por solicitud. Una consulta no puede dividirse en dos segmentos cacheados; solo su inicio puede coincidir.
• Las escrituras invalidan al instante. Cualquier store, store-turn, bulk-store, forget, supersede o eliminación del almacén descarta su caché, así que una respuesta cacheada nunca puede quedar obsoleta.

Cómo activarlo

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"

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

No necesitas un SDK para nada de esto. El caching es un campo en una llamada HTTP, así que funciona desde cualquier lenguaje de programación. La pestaña curl es la receta universal, y los SDK de Python, TypeScript y Rust son envoltorios de conveniencia sobre exactamente la misma llamada.