Prompt Caching Strategien für Kosteneinsparung mit Claude

1. Warum Prompt Caching ein Kostenhebel ist

Viele Anwendungen mit Claude schicken bei jeder einzelnen Anfrage denselben grossen, statischen Kontext mit: einen ausfuehrlichen System Prompt, eine komplette API Dokumentation, einen ganzen Codebestand oder ein umfangreiches Regelwerk. Ohne Prompt Caching wird dieser Kontext bei jeder Anfrage vollstaendig neu verarbeitet und vollstaendig abgerechnet, obwohl sich der Inhalt zwischen zwei Anfragen nicht veraendert hat.

Prompt Caching loest genau dieses Problem: statische Anteile eines Prompts werden serverseitig fuer eine begrenzte Zeit vorgehalten, sodass nachfolgende Anfragen mit identischem Praefix nur noch die neuen, variablen Anteile voll bezahlen muessen. Der wiederverwendete Teil wird zu einem Bruchteil der regulaeren Input Kosten abgerechnet. Bei Anwendungen mit langen, wiederkehrenden Kontexten summiert sich diese Ersparnis ueber tausende Anfragen zu einem erheblichen Betrag.

Dieser Artikel zeigt, wie Prompt Caching in der Claude API technisch funktioniert, wo Cache Breakpoints sinnvoll platziert werden, welche TTL Strategie zum jeweiligen Anwendungsfall passt, und wie man die tatsaechliche Kostenersparnis in der Praxis misst statt sie nur zu vermuten.

2. Wie Prompt Caching bei Claude technisch funktioniert

Technisch basiert Prompt Caching auf dem Prinzip, dass ein bestimmter Praefix der Konversation, markiert durch einen Cache Breakpoint, serverseitig als verarbeiteter Zustand gespeichert wird. Trifft eine nachfolgende Anfrage mit exakt demselben Praefix ein, muss Claude diesen Anteil nicht erneut vollstaendig verarbeiten, sondern greift auf den zwischengespeicherten Zustand zurueck. Das reduziert sowohl die Latenz bis zur ersten Antwort als auch die abgerechneten Input Tokens fuer den zwischengespeicherten Anteil erheblich.

Wichtig ist das Verstaendnis, dass Prompt Caching auf exakter Praefix Uebereinstimmung basiert. Jede Aenderung, und sei es nur ein zusaetzliches Leerzeichen, vor einem Cache Breakpoint invalidiert den Cache fuer diesen Abschnitt. Die Reihenfolge im Prompt ist deshalb entscheidend: statische Anteile wie System Prompt, Tool Definitionen und lange Referenzdokumente muessen konsequent vor den variablen Anteilen wie der eigentlichen Nutzeranfrage stehen.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": large_system_prompt,  # long, static instructions
            "cache_control": {"type": "ephemeral"}  # mark as cacheable
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": full_documentation,  # large static reference doc
                    "cache_control": {"type": "ephemeral"}  # second breakpoint
                },
                {"type": "text", "text": user_question}  # variable part, no caching
            ]
        }
    ]
)

print(response.usage.cache_creation_input_tokens)  # tokens written to cache
print(response.usage.cache_read_input_tokens)       # tokens read from cache

3. Cache Breakpoints richtig platzieren

Ein Cache Breakpoint markiert das Ende eines wiederverwendbaren Blocks im Prompt. Die Claude API erlaubt mehrere Breakpoints innerhalb einer Anfrage, was fuer gestaffelte Prompt Caching Strategien genutzt werden kann: ein Breakpoint nach dem System Prompt, ein weiterer nach einem grossen Referenzdokument, das sich seltener aendert als die Konversation selbst. Jeder Breakpoint erzeugt einen eigenen Cache Eintrag mit eigener Guelltigkeit.

Die Reihenfolge der Blockplatzierung entscheidet ueber die Wirksamkeit des Prompt Caching: Inhalte, die sich am seltensten aendern, sollten am weitesten vorne stehen, gefolgt von Inhalten mittlerer Aenderungshaeufigkeit, und ganz am Ende die tatsaechlich variable Nutzeranfrage. Wird diese Reihenfolge verletzt, etwa wenn eine variable ID mitten im sonst statischen System Prompt eingebettet wird, bricht der Cache fuer den gesamten nachfolgenden Block, selbst wenn der Rest identisch ist.

Fuer mehrstufige Konversationen mit wachsendem Verlauf empfiehlt sich zusaetzlich ein Breakpoint am Ende des bisherigen Gespraechsverlaufs, sodass bei jeder neuen Nutzerantwort nur der neue Beitrag ausserhalb des Caches liegt und der gesamte bisherige Dialog aus dem Cache bedient wird. Diese Technik ist besonders wirksam in laengeren Support Chats oder Coding Sessions mit vielen Hin und Her Nachrichten.

{
  "system": [
    {
      "type": "text",
      "text": "<static system instructions, rarely changes>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "<large reference document, changes weekly>",
          "cache_control": {"type": "ephemeral"}
        },
        {
          "type": "text",
          "text": "<conversation history so far>",
          "cache_control": {"type": "ephemeral"}
        },
        {"type": "text", "text": "<newest user message, never cached>"}
      ]
    }
  ]
}

4. TTL Wahl: 5 Minuten oder 1 Stunde

Die Claude API bietet fuer Prompt Caching zwei TTL Optionen: eine kurze fuenfminuetige Cache Lebensdauer und eine laengere einstuendige Variante gegen einen etwas hoeheren Schreibpreis. Die richtige Wahl haengt vom Anfragemuster der Anwendung ab. Bei einem interaktiven Chat Interface, bei dem Nutzer typischerweise innerhalb weniger Minuten mehrere Nachrichten senden, reicht die fuenfminuetige TTL meist aus und ist die guenstigere Option.

Bei Batch Verarbeitungen mit laengeren Pausen zwischen Anfragen, etwa einer taeglichen Analyse eines grossen Dokumentenbestands ueber mehrere Stunden hinweg, verhindert die fuenfminuetige TTL, dass der Cache zwischen den Anfragen ueberhaupt greift. Hier zahlt sich die einstuendige TTL trotz hoeherer Schreibkosten aus, weil sie die Trefferquote ueber den gesamten Verarbeitungszeitraum deutlich erhoeht. Eine grobe Faustregel: sobald die durchschnittliche Pause zwischen Anfragen die fuenf Minuten spuerbar ueberschreitet, lohnt sich die Pruefung der einstuendigen Variante.

5. Typische Anwendungsfaelle mit hohem Einsparpotenzial

Der groesste Hebel fuer Prompt Caching entsteht dort, wo ein grosser, stabiler Kontext wiederholt mit unterschiedlichen kleinen Anfragen kombiniert wird. Ein Support Chatbot, der bei jeder Nutzeranfrage die komplette Produktdokumentation als Kontext mitschickt, ist ein Paradebeispiel: die Dokumentation aendert sich selten, die Nutzerfrage aendert sich bei jeder Anfrage. Ohne Caching wird die komplette Dokumentation bei jeder einzelnen Anfrage voll abgerechnet.

Ein zweites starkes Beispiel ist ein Coding Assistent, der bei jeder Anfrage denselben grossen Codebestand als Kontext benoetigt, um Aenderungen im richtigen Zusammenhang vorzuschlagen. Ohne Prompt Caching summieren sich die Kosten fuer die wiederholte Verarbeitung desselben Codes ueber eine gesamte Entwicklungssession zu einem erheblichen Betrag. Auch Few Shot Prompting mit vielen Beispielen profitiert deutlich: die Beispielsammlung bleibt ueber viele Anfragen konstant und eignet sich hervorragend als gecachter Block vor der eigentlichen variablen Aufgabe.

import anthropic

client = anthropic.Anthropic()

def support_chatbot_reply(product_docs: str, user_question: str) -> str:
    """Product documentation stays constant across thousands of requests,
    cache it once, pay full price only for the changing user question."""
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": f"You are a support assistant. Reference documentation:\n\n{product_docs}",
                "cache_control": {"type": "ephemeral"},
            }
        ],
        messages=[{"role": "user", "content": user_question}],
    )
    print(f"cache read: {response.usage.cache_read_input_tokens} tokens")
    return response.content[0].text

6. Prompt Caching in agentischen Workflows

Agentische Systeme, bei denen Claude in einer Schleife wiederholt Tools aufruft und Zwischenergebnisse in denselben Konversationsverlauf einfliessen laesst, profitieren besonders stark von Prompt Caching. Jede weitere Runde der Schleife enthaelt den kompletten bisherigen Verlauf inklusive aller vorherigen Tool Aufrufe und Ergebnisse, und ohne Caching wachsen die Kosten pro Runde linear mit der Laenge des bisherigen Verlaufs.

Mit einem Cache Breakpoint am Ende des bisherigen Verlaufs vor jeder neuen Runde wird nur der neu hinzugekommene Anteil, typischerweise das letzte Tool Ergebnis, voll abgerechnet, waehrend der komplette historische Kontext aus dem Cache bedient wird. Bei Agenten mit zehn oder mehr Iterationsschritten macht dieser Unterschied den Einsatz von Prompt Caching von einer Optimierung zu einer wirtschaftlichen Notwendigkeit.

import anthropic

client = anthropic.Anthropic()

def agent_loop(system_prompt: str, tools: list, conversation: list, max_turns: int = 10):
    """Run an agentic loop, caching the growing conversation history each turn."""
    for turn in range(max_turns):
        # Mark the last message of the history as a cache breakpoint:
        # everything up to here is reused on the next iteration.
        if conversation:
            conversation[-1]["content"][-1]["cache_control"] = {"type": "ephemeral"}

        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=2048,
            system=[{"type": "text", "text": system_prompt, "cache_control": {"type": "ephemeral"}}],
            tools=tools,
            messages=conversation,
        )

        print(f"Turn {turn}: cache read = {response.usage.cache_read_input_tokens} tokens")

        if response.stop_reason != "tool_use":
            return response

        conversation.append({"role": "assistant", "content": response.content})
        tool_result = execute_tools(response.content)  # application specific
        conversation.append({"role": "user", "content": [tool_result]})

    return response

7. Cache Trefferquote messen und ueberwachen

Ohne Messung bleibt Prompt Caching eine Vermutung statt einer belegten Kostenersparnis. Jede Claude API Antwort enthaelt im usage Objekt die Felder cache_creation_input_tokens fuer neu geschriebene Cache Eintraege und cache_read_input_tokens fuer erfolgreiche Cache Treffer. Ein Monitoring, das diese Werte pro Anfrage protokolliert und ueber Zeit aggregiert, macht sichtbar, ob die gewaehlte Breakpoint Platzierung tatsaechlich greift.

Eine niedrige Trefferquote trotz eingerichteter Breakpoints deutet meist auf eines von zwei Problemen hin: entweder aendert sich der vermeintlich statische Praefix doch bei jeder Anfrage geringfuegig, etwa durch einen eingebetteten Zeitstempel, oder die TTL ist zu kurz fuer das tatsaechliche Anfragemuster. Ein einfaches Dashboard, das die Rate aus cache_read_input_tokens zu Gesamt Input Tokens ueber die Zeit darstellt, macht solche Regressionen sofort sichtbar, bevor sie sich in der monatlichen Rechnung als Ueberraschung zeigen.

cache_metrics = []

def record_usage(response) -> None:
    """Log cache metrics per request for later aggregation into a dashboard."""
    usage = response.usage
    total_input = usage.input_tokens + usage.cache_read_input_tokens
    hit_rate = usage.cache_read_input_tokens / total_input if total_input else 0.0
    cache_metrics.append({
        "cache_read_tokens": usage.cache_read_input_tokens,
        "cache_creation_tokens": usage.cache_creation_input_tokens,
        "hit_rate": round(hit_rate, 3),
    })

def average_hit_rate(window: int = 100) -> float:
    """Rolling average over the most recent requests, flags regressions early."""
    recent = cache_metrics[-window:]
    return sum(m["hit_rate"] for m in recent) / len(recent) if recent else 0.0

8. Fallstricke: wenn Caching nicht greift

Der haeufigste Fallstrick bei Prompt Caching ist ein versteckter dynamischer Wert innerhalb eines vermeintlich statischen Blocks. Ein System Prompt, der die aktuelle Uhrzeit oder eine Session ID enthaelt, invalidiert den Cache bei jeder einzelnen Anfrage, weil der Text nie exakt identisch ist. Solche dynamischen Werte gehoeren strikt hinter den letzten Cache Breakpoint, niemals davor.

Ein weiterer Fallstrick betrifft die Reihenfolge von Tool Definitionen: werden Tools in unterschiedlicher Reihenfolge zwischen zwei Anfragen uebergeben, obwohl die Menge der Tools identisch ist, gilt der Praefix als unterschiedlich und der Cache greift nicht. Tool Listen sollten deshalb konsequent in einer festen, deterministischen Reihenfolge aufgebaut werden. Auch das nachtraegliche Aendern der Modellversion zwischen zwei Anfragen unterbricht die Cache Kontinuitaet vollstaendig, da jeder Cache Eintrag an ein bestimmtes Modell gebunden ist.

9. Kostenmodell im Vergleich

Die konkrete Kostenwirkung von Prompt Caching haengt vom Verhaeltnis zwischen gecachten und variablen Tokens ab. Die folgende Tabelle stellt typische Kostenfaktoren gegenueber Standard Input Tokens dar, ohne konkrete Preise zu nennen, da sich diese modell und anbieterabhaengig aendern koennen.

Der wirtschaftliche Vorteil von Prompt Caching entsteht aus der Anzahl der Cache Treffer im Verhaeltnis zu den Schreibvorgaengen. Bei einem Kontext, der einmal geschrieben und danach hundertfach gelesen wird, ist die Ersparnis erheblich. Bei einem Kontext, der nur einmal verwendet wird, uebersteigt der leicht erhoehte Schreibpreis den moeglichen Nutzen, weshalb Prompt Caching gezielt fuer wiederverwendete Anteile eingesetzt werden sollte, nicht pauschal fuer jede Anfrage.

10. Zusammenfassung

Prompt Caching Strategien fuer Kosteneinsparung lohnen sich ueberall dort, wo ein grosser, stabiler Kontext wiederholt mit kleinen variablen Anfragen kombiniert wird: Support Chatbots mit statischer Dokumentation, Coding Assistenten mit grossem Codebestand, und agentische Workflows mit wachsendem Konversationsverlauf. Cache Breakpoints muessen so platziert werden, dass sich seltener aendernde Inhalte konsequent vor haeufiger aendernden Inhalten stehen.

Die Wahl zwischen fuenfminuetiger und einstuendiger TTL richtet sich nach dem tatsaechlichen Anfrageabstand der Anwendung, nicht nach einer pauschalen Empfehlung. Monitoring der Felder cache_read_input_tokens und cache_creation_input_tokens macht den tatsaechlichen Effekt sichtbar und deckt versteckte dynamische Werte auf, die den Cache unbeabsichtigt invalidieren. Wer Prompt Caching gezielt und gemessen einsetzt, senkt Kosten und Latenz gleichzeitig, ohne Kompromisse bei der Antwortqualitaet einzugehen.

11. FAQ: Prompt Caching Strategien fuer Kosteneinsparung