Recall-Caching

Wiederholte Abrufe, zum Zehntel des Preises.

Aktiviere es pro Anfrage, und WOS cached das Suchergebnis unter dem Abfragetext, mit denselben Präfixregeln wie beim Prompt Caching von LLMs. Solange der Cache warm ist, nutzt eine wiederholte oder erweiterte Abfrage das vorherige Ergebnis wieder, und der gecachte Teil wird mit 10% des normalen Token-Preises berechnet.

Nur Tablet und Scroll. Caching funktioniert auf jedem Tablet- und Scroll-Modell, heute und in Zukunft. Book unterstützt es nicht: Book denkt über deine Erinnerungen nach und lernt zwischen den Aufrufen, dieselbe Frage kann also berechtigt eine andere Antwort ergeben, und ein gecachtes Ergebnis wäre konstruktionsbedingt falsch. Wer cache_control an Book sendet, bekommt ein klares 403.

Ein Gespräch, drei Runden

So sieht es wirklich aus, wenn ein Agent immer weiter mit seinem Gedächtnis spricht. Jede Runde schickt das bisherige Gespräch als Abfrage, mit aktiviertem cache_control.

writeRunde 1 - „Alice: Ich bin letzten Frühling nach Lissabon gezogen.“

Die gesamte Abfrage wird gesucht und gecacht: Eingabe zum 2-fachen (TTL 5 Minuten).

extendRunde 2 - derselbe Text plus „Bob: Wie ist das Wetter dort?“

Nur Bobs Satz wird indexiert und gesucht. Der alte Teil kostet 0,1x, der neue Satz 2x, und der Cache endet jetzt dort.

hitRunde 3 - exakt dieselbe Abfrage noch einmal (ein Retry, ein Refresh)

Gar kein Engine-Aufruf. Alles zu 0,1x: der 90%-Rabatt.

Die Preise

Vorgang	Token-Abrechnung	Bedeutung
Cache-Schreiben - TTL 5 Minuten	2×	Die erste Anfrage. Ihr Ergebnis wird 5 Minuten aufbewahrt, und jedes Lesen verschiebt das Fenster nach vorn.
Cache-Schreiben - TTL 1 Stunde	3×	Die erste Anfrage, eine volle Stunde aufbewahrt.
Cache-Lesen - Treffer oder Präfix-Treffer	0.1×	Jede Anfrage nach dem Schreiben: Der gecachte Teil kostet ein Zehntel des normalen Token-Preises.

Was es spart

Ein konkretes Beispiel: Dein Agent schickt ein Gespräch mit 3.000 Tokens als Abfrage und wiederholt oder verlängert es 10-mal innerhalb von fünf Minuten. Ohne Caching sind das 30.000 Eingabe-Tokens zum vollen Preis. Mit einem 5-Minuten-Cache sind es 6.000 für das erste Schreiben (2x) plus rund 2.700 für die neun Cache-Lesevorgänge: 8.700 abgerechnete Tokens, 71% weniger. Je länger das Gespräch läuft, desto größer die Ersparnis.

Die Präfixregel

Der Abgleich erfolgt am Anfang der Abfrage. Bleibt der Anfang identisch und wird nur neuer Text angehängt, wird der gecachte Teil wiederverwendet und nur der neue Teil gesucht. Ändert sich etwas vor dem Ende des gecachten Textes, kann nichts wiederverwendet werden.

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

○ Treffer - der Anfang ist unverändert, nur E ist neu
✗ Fehltreffer - der Anfang hat sich geändert, die gesamte Abfrage wird neu gesucht und neu gecacht

Drei Regeln zum Merken

Erweitern cached bis zum neuen Ende neu. Nach [A B C D E F G] + E endet der Cache jetzt bei E: Das Ende wird einmal zum Schreibtarif berechnet, und die nächste Runde kann wieder ganz A..E als Präfix abgleichen.
Ein zusammenhängendes Präfix pro Anfrage. Eine Abfrage kann nicht in zwei Cache-Segmente geteilt werden; nur ihr Anfang kann übereinstimmen.
Schreibvorgänge invalidieren sofort. Jedes store, store-turn, bulk-store, forget, supersede oder Löschen des Stores verwirft dessen Cache. Eine gecachte Antwort kann nie veraltet sein.

So wird es aktiviert

   
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"

Antwort - das cache-Objekt meldet, was passiert ist

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

Für all das brauchst du kein SDK. Caching ist ein Feld in einem HTTP-Aufruf und funktioniert daher aus jeder Programmiersprache. Der curl-Tab ist das universelle Rezept, und die Python-, TypeScript- und Rust-SDKs sind bequeme Hüllen um genau denselben Aufruf.

Das Caching ist innerhalb deines Workspace pro Store und pro Modell isoliert und standardmäßig aus: Ohne cache_control ändert sich an deinen Anfragen nichts.

Product

Models

Start