Du hast den Agentic Loop gebaut. Tools werden aufgerufen, Ergebnisse kommen zurück, das Modell überlegt sich den nächsten Schritt — das Ganze schnurrt wie ein kleines autonomes Gehirn. Dann öffnest du nach einem Tag Testen das Anthropic-Usage-Dashboard. Diese Zahl ist kein Tippfehler. Das sind die Kosten dafür, dass du denselben System-Prompt und dieselben Tool-Schemas bei jeder einzelnen Iteration zum vollen Preis an eine zustandslose API schickst, die keine Ahnung hat, was du ihr vor drei Sekunden geschickt hast.

Und falls du am 16. April 2026 auf Opus 4.7 aufgerüstet hast — was du wahrscheinlich getan hast — hat Simon Willison gemessen, dass der neue Tokenizer für identische System-Prompts 1,46× mehr Tokens erzeugt. Deine Kosten sind über Nacht um 35-40% gestiegen, für buchstäblich denselben Text. Finouts Analyse (27. April 2026) bestätigt das Muster über verschiedene Workloads hinweg.

Warum "optimier halt deine Prompts" nicht reicht

Die naheliegende Antwort: Prompts kürzer machen. Klar, streich das Überflüssige. Aber in einem echten Agentic Loop erreicht dein statischer Prefix — System-Prompt, Tool-Definitionen (Schemas, die dem Modell sagen, welche Tools es aufrufen kann und welche Parameter sie akzeptieren), und der angesammelte Gesprächsverlauf — locker 10.000+ Tokens. Mit 6 Tools und einem ordentlichen System-Prompt landest du bei ~11.000 Tokens identischen Inhalts, der bei jedem Turn neu gesendet wird.

Über 10 Iterationen sind das 110.000 Tokens reiner Wiederholung bei $5/MTok auf Opus 4.7. Das sind $0,55 allein an Input-Kosten — nur für Bytes, die der Server schon gesehen hat. Skalier das auf 50 Turns und du verbrennst Dollar für eine einzige Konversation.

Kein noch so radikales Prompt-Trimming behebt ein fundamental zustandsloses Protokoll. Du brauchst den Server dazu, sich zu erinnern.

Die Lösung: Prompt Caching

Anthropics Prompt-Caching-API (GA seit 17. Dezember 2024) erlaubt dir, Nachrichtenblöcke mit einem cache_control-Breakpoint zu markieren — ein Marker, der dem Server sagt: "Speicher alles bis hierhin." Bei nachfolgenden Requests liest der Server bei exakter Byte-Übereinstimmung aus dem Cache und berechnet dir 10% des normalen Input-Preises. Laut Anthropics Dokumentation kostet der 5-Minuten-Cache (Standard) 1,25× beim initialen Schreiben; der 1-Stunden-Cache kostet 2×.

Die Rechnung ist simpel: Einmal 25% Aufschlag zahlen, dann 90% Rabatt auf jeden folgenden Hit. In einem 10-Turn-Loop heißt das 1 Write + 9 Reads. Das amortisiert sich nach dem ersten Cache-Hit.

Schritt 1: System-Prompt cachen

Der System-Prompt ist der stabilste Inhalt in deinem Loop. Er ändert sich nie zwischen Iterationen. Mach ihn cachebar:

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": "Dein langer System-Prompt mit Anweisungen...",
        "cache_control": {"type": "ephemeral"},  # 5-min TTL
    }],
    messages=[...],
)

Das entscheidende Detail: Bei Opus 4.7 (und Opus 4.5, Haiku 4.5) beträgt der minimale cachbare Block 4.096 Tokens. Wenn dein System-Prompt kürzer ist, ignoriert Anthropic den cache_control-Marker stillschweigend — kein Fehler, kein Cache, nur verschwendete Absicht. Bei Sonnet liegt das Minimum bei 1.024 Tokens.

/faion ist der faion-network Umbrella-Skill — er zieht relevante Methodik aus 12 Spezialistendomänen in die Konversation. Bevor du also deine Cache-Strategie entwirfst, frag ihn:

/faion
Ich implementiere Anthropic Prompt Caching für einen Multi-Tool Agentic Loop.
Was ist die beste Strategie für die Platzierung von cache_control-Breakpoints,
wenn ich einen System-Prompt, 6 Tool-Schemas und wachsenden
Konversationsverlauf habe?

Schritt 2: Tool-Definitionen cachen

Tool-Schemas — die JSON-Beschreibungen von Name, Parametern und Zweck jedes Tools — sitzen im tools-Array und werden in der Cache-Hierarchie vor dem System-Prompt verarbeitet. Setz den cache_control auf das letzte Tool im Array, um alle mit einem Breakpoint zu cachen:

tools = [
    {"name": "search_web", "description": "...", "input_schema": {...}},
    {"name": "read_file", "description": "...", "input_schema": {...}},
    {"name": "run_code", "description": "...", "input_schema": {...}},
    {"name": "write_file", "description": "...", "input_schema": {...}},
    {"name": "list_dir", "description": "...", "input_schema": {...}},
    {"name": "submit_result", "description": "...", "input_schema": {...},
     "cache_control": {"type": "ephemeral"}},  # cached ALLE Tools darüber
]

Kritische Regel: Die Cache-Hierarchie ist tools → system → messages. Wenn du irgendeine Tool-Definition zwischen Iterationen änderst (Tool hinzufügen, Parameter umbenennen), invalidiert das den Cache für Tools, System UND Messages. In einem Agentic Loop: halt dein Toolset eingefroren.

Schritt 3: Konversationsverlauf-Prefix cachen

Mit wachsender Konversation werden ältere Nachrichten statisch — sie ändern sich nicht mehr. Setz einen Breakpoint auf die letzte Nachricht im "stabilen" Teil:

messages = [
    {"role": "user", "content": "Initiale Aufgabe..."},
    {"role": "assistant", "content": "Ich fange an mit..."},
    {"role": "user", "content": [{  # letzte stabile Nachricht
        "type": "text",
        "text": "Tool-Ergebnis von Schritt 3...",
        "cache_control": {"type": "ephemeral"},
    }]},
    {"role": "assistant", "content": "Verarbeite jetzt..."},  # neu, nicht gecacht
]

Du hast jetzt 3 Breakpoints (Tools, System, Verlauf). Die API erlaubt maximal 4. Heb dir den letzten Slot für Sonderfälle auf.

Schritt 4: Der Umzugstrick

Dieser hier kommt vom Engineering-Team von ProjectDiscovery, die ihre Ergebnisse am 10. April 2026 veröffentlicht haben. Die betreiben einen 26-Schritte-Security-Scanner mit 40 Tool-Calls. Ihre anfängliche Cache-Hit-Rate war erbärmliche 7%.

Das Problem: Ihr System-Prompt enthielt Timestamps, Working Memory und Runtime-Variablen, die sich bei jedem Call änderten. Cache-Matching erfordert exakte Byte-Gleichheit — ein einziges abweichendes Zeichen und der gesamte Block verfehlt den Cache.

Die Lösung: Alle dynamischen Inhalte raus aus dem System-Prompt und in eine User-Role-Nachricht am Ende der Konversation. Der System-Prompt wird byte-identisch über alle Calls hinweg. Ihre Cache-Hit-Rate sprang von 7% auf 74% über Nacht, erreichte schließlich 84% mit weiterem Tuning — eine Kostensenkung von 70%.

/faion
Wie sollte ich statische vs. dynamische Inhalte in einem agentischen
System-Prompt trennen, um die Cache-Hit-Rate zu maximieren? Welche Patterns
gibt es für den Static-System-Prompt + Dynamic-User-Reminder-Split?

Schritt 5: Überprüfen, ob es tatsächlich funktioniert

Cache-Hits sind unsichtbar, wenn du nicht hinschaust. Die meisten SDK-Wrapper und Logging-Frameworks zeigen Cache-Metriken nicht an. Du musst explizit prüfen:

usage = response.usage
print(f"Cache geschrieben: {usage.cache_creation_input_tokens}")
print(f"Cache gelesen:     {usage.cache_read_input_tokens}")
print(f"Nicht gecacht:     {usage.input_tokens}")

hit_rate = usage.cache_read_input_tokens / (
    usage.cache_read_input_tokens +
    usage.cache_creation_input_tokens +
    usage.input_tokens
) * 100
print(f"Cache-Hit-Rate: {hit_rate:.1f}%")

Ab der zweiten Loop-Iteration sollte cache_read_input_tokens groß sein. Wenn es null ist, invalidiert irgendetwas deinen Cache — such nach Byte-Level-Unterschieden in deinen "statischen" Inhalten.

Fallstricke, die dich Geld kosten werden

1. Die 5-Minuten-Klippe. Standard-TTL (Time-to-Live — wie lange der Server deinen gecachten Inhalt im Speicher behält) ist 5 Minuten. Wenn ein Tool-Call 6 Minuten dauert (externes API-Timeout, lange Berechnung), verfällt der Cache. Du zahlst den Schreib-Aufschlag nochmal. Fix: Verwende "ttl": "1h" für langsame Workflows, aber rechne damit, dass es 2× statt 1,25× beim Write kostet. Und längere TTLs müssen im Request vor kürzeren stehen — umgekehrt gibt's einen Fehler.

2. JSON-Key-Reihenfolge. Manche Sprachen randomisieren die JSON-Key-Reihenfolge bei der Serialisierung. Andere Reihenfolge = andere Bytes = Cache-Miss. Fixier deine Serialisierungsreihenfolge oder verwende sort_keys=True.

3. Der 20-Block-Lookback. Das System durchsucht maximal 20 Content-Blöcke rückwärts nach gecachten Einträgen. In langen Konversationen (>20 Blöcke) fallen alte Cache-Breakpoints aus dem Suchfenster. Setz alle ~18 Blöcke frische Breakpoints. PwCs Studie vom Januar 2026 fand heraus, dass hier die meisten "mysteriösen Cache-Misses" herkommen.

4. Kurze Inhalte cachen kostet mehr. PwC hat gemessen, dass Prompts unter 500 Tokens durch den Overhead 10-18% schlechtere Latenz zeigen. Cach nicht deinen 200-Token-System-Prompt. Bei Opus muss er sowieso die 4.096-Token-Mindestgrenze überschreiten.

Was du jetzt tun kannst

Du hast drei Breakpoints — Tools, System, Verlaufs-Prefix — und ein Monitoring-Pattern. Derselbe Agentic Loop, der auf Opus 4.7 $0,55 pro 10-Turn-Konversation verbrannt hat, kostet jetzt ~$0,12. Das ist kein Rundungsfehler — das ist der Unterschied zwischen einem Prototyp, den du einmal vorführst, und einem System, das du tatsächlich in Produktion bringst. Die 35% Tokenizer-Steuer von Opus 4.7? Immer noch da, aber du zahlst sie einmal pro Cache-Write statt bei jedem einzelnen Turn. Willkommen in dem Teil, wo die Abrechnungsseite aufhört, dir Angstschweiss zu bereiten.