Beherrschen Sie die 3 Kernmechanismen der Claude API-Cache-Abrechnung: Preisvergleich für 5-Minuten- vs. 1-Stunden-Cache-Schreibvorgänge und detaillierte Erklärung zur Cache-Isolierung über Konten hinweg

Autorhinweis: Tiefgehende Analyse des Claude API Cache-Abrechnungsmechanismus, Vergleich der Preisunterschiede zwischen 5-Minuten- und 1-Stunden-Cache-Schreibvorgängen, Klärung der Frage nach Cache-Treffern über Konten hinweg und Gegenüberstellung der Cache-Abrechnung zwischen AWS Bedrock und der offiziellen Anthropic API.

Das Prompt Caching der Claude API ist ein zentrales Mittel, um die Kosten für API-Aufrufe zu senken. Viele Entwickler sind sich jedoch über die Details der Cache-Abrechnung unsicher: Sollte man den 5-Minuten- oder den 1-Stunden-Cache wählen? Können Caches über Konten hinweg geteilt werden? Wie unterscheidet sich die Cache-Abrechnung bei AWS Bedrock von der offiziellen API?

Kernnutzen: Nach dem Lesen dieses Artikels wirst du die 3 zentralen Mechanismen der Claude API Cache-Abrechnung vollständig verstehen, die optimale Methode zur Auswahl der Cache-Strategie beherrschen und unnötige Kosten vermeiden.

Kernpunkte der Claude API Cache-Abrechnung

Grundmultiplikatoren für die Claude Cache-Abrechnung

Das Prompt Caching der Claude API verwendet ein einheitliches Multiplikator-Abrechnungssystem. Unabhängig davon, welches Modell (Opus 4.6, Sonnet 4.6 oder Haiku 4.5) verwendet wird, sind die Multiplikatorregeln für Cache-Operationen vollständig identisch:

• Cache-Schreiben (5 Minuten TTL): Grundpreis Eingabe × 1.25
• Cache-Schreiben (1 Stunde TTL): Grundpreis Eingabe × 2.0
• Cache-Lesen (Treffer): Grundpreis Eingabe × 0.1

Das bedeutet, dass du bei jedem Cache-Treffer nur 10 % des Standard-Eingabepreises zahlst. Nehmen wir Claude Sonnet 4.6 als Beispiel: Der Standard-Eingabepreis beträgt 3 $/MTok, der Cache-Trefferpreis nur 0,3 $/MTok – eine Einsparung von 90 % bei den Eingabekosten.

Amortisationsberechnung für die Claude Cache-Abrechnung

Es ist wichtig, die Kosten-Nutzen-Rechnung des Cachings zu verstehen. Das Schreiben in den Cache verursacht zusätzliche Kosten, aber das Lesen aus dem Cache ist extrem günstig. Die entscheidende Frage ist: Nach wie vielen Treffern beginnt sich der Cache zu "amortisieren"?

• 5-Minuten-Cache: Schreiben 1,25x + Lesen 0,1x = Nach dem ersten Schreiben amortisiert sich der Cache bereits nach 1 Treffer (weil normales Lesen 1x kostet, Cache-Lesen aber 0,1x, Einsparung 0,9x > zusätzlich gezahlte 0,25x)
• 1-Stunden-Cache: Schreiben 2,0x + Lesen 0,1x = Nach dem ersten Schreiben sind 2 Treffer nötig, um die Kosten wieder einzuspielen (zusätzliche Zahlung 1,0x, Einsparung pro Treffer 0,9x)

Daher ist der 5-Minuten-Cache fast immer eine "sichere" Wahl, während der 1-Stunden-Cache sicherstellen muss, dass er innerhalb der Gültigkeitsdauer mindestens 2 Mal getroffen wird.

Claude-Cache-Abrechnung: 5-Minuten- vs. 1-Stunden-Cache im Vergleich

5-Minuten- vs. 1-Stunden-Cache: Preisunterschiede

Hier sind die konkreten Preise für das Schreiben in den 5-Minuten- und 1-Stunden-Cache für verschiedene Modelle:

Strategie zur Auswahl der TTL für Claude-Cache-Abrechnung

5-Minuten- und 1-Stunden-Cache schließen sich nicht gegenseitig aus. Du kannst je nach Anwendungsfall flexibel wählen und sie sogar in derselben Anfrage kombinieren.

Anwendungsfälle für 5-Minuten-Cache:

• Häufige API-Aufrufe (mehrmals pro Minute), bei denen der Cache innerhalb von 5 Minuten kontinuierlich aktualisiert wird.
• Interaktive Dialoge, bei denen der Nutzer fortlaufend Nachrichten sendet und der Cache automatisch verlängert wird.
• Kostenbewusste Projekte, bei denen die Schreibkosten niedriger sind.

Anwendungsfälle für 1-Stunden-Cache:

• Batch-Verarbeitungsaufgaben, bei denen ein Datensatz erst nach mehreren Minuten oder Stunden erneut verarbeitet wird.
• Große System-Prompts mit hohen Schreibkosten, die länger im Cache verbleiben sollen.
• Geplante Aufgaben (Cron-Jobs), die z.B. alle 15-30 Minuten ausgeführt werden.

Wichtiger Mechanismus: Der 5-Minuten-Cache wird bei jedem Treffer automatisch erneuert (TTL-Refresh). Wenn deine Aufrufe also häufig genug sind (mindestens eine Anfrage innerhalb von 5 Minuten), kann der Cache praktisch unbegrenzt leben, ohne dass du den 1-Stunden-Cache wählen musst.

🎯 Technischer Tipp: In den meisten Fällen reicht der 5-Minuten-Cache völlig aus. Wenn du die Claude-API über die APIYI-Plattform apiyi.com aufrufst, gelten die gleichen Cache-Abrechnungsregeln wie bei der offiziellen API, und du kannst die Cache-Strategien für mehrere Modelle über eine einheitliche Schnittstelle verwalten.

Gemischte TTL-Nutzung in der Claude-Cache-Abrechnung

Anthropic erlaubt die gleichzeitige Verwendung von 1-Stunden- und 5-Minuten-Cache-Kontrolle in derselben Anfrage, mit einer wichtigen Einschränkung:

TTL-Reihenfolge von lang nach kurz: Das 1-Stunden-Cache-Tag muss vor dem 5-Minuten-Cache-Tag erscheinen.

In der Praxis kannst du zum Beispiel selten ändernde System-Prompts mit 1-Stunden-Cache und etwas häufiger wechselnde Few-Shot-Beispiele mit 5-Minuten-Cache versehen:

import anthropic

client = anthropic.Anthropic(
    api_key="YOUR_API_KEY",
    base_url="https://vip.apiyi.com"  # Aufruf über APIYI
)

response = client.messages.create(
    model="claude-sonnet-4-6-20260320",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Du bist ein professioneller Assistent für technische Dokumentation...(umfangreicher System-Prompt)...",
            "cache_control": {"type": "ephemeral", "ttl": "3600"}  # 1-Stunden-Cache
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Hier ist das Referenzdokument...(umfangreicher Kontext)...",
                    "cache_control": {"type": "ephemeral"}  # Standard-5-Minuten-Cache
                },
                {
                    "type": "text",
                    "text": "Bitte beantworte basierend auf dem obigen Dokument: Was ist Prompt Caching?"
                }
            ]
        }
    ]
)

import anthropic

client = anthropic.Anthropic(
    api_key="YOUR_API_KEY",
    base_url="https://vip.apiyi.com"
)

response = client.messages.create(
    model="claude-sonnet-4-6-20260320",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Dein System-Prompt-Inhalt (muss >= 1024 Tokens sein, um Caching auszulösen)",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": "Hallo"}]
)

# Cache-Nutzung prüfen
usage = response.usage
print(f"Eingabe-Tokens: {usage.input_tokens}")
print(f"Cache-Schreib-Tokens: {usage.cache_creation_input_tokens}")
print(f"Cache-Lese-Tokens: {usage.cache_read_input_tokens}")

# Cache-Status bestimmen
if usage.cache_read_input_tokens > 0:
    print("Cache-Treffer! 90% der Eingabekosten gespart.")
elif usage.cache_creation_input_tokens > 0:
    print("Cache erstmalig beschrieben, zukünftige Anfragen werden den Cache treffen.")

💡 Hinweis: Es gibt eine Mindest-Token-Anzahl für das Caching. Claude Opus 4.6 erfordert mindestens 1024 Tokens, Sonnet 4.6 und Haiku 4.5 ebenfalls mindestens 1024 Tokens. Inhalte unter diesem Schwellenwert werden nicht gecacht.

Claude-Cache-Abrechnung: Isolationsmechanismus für Caches über Konten hinweg

Das ist eine Frage, die viele Entwickler besonders beschäftigt: Kann Konto B auf einen Cache zugreifen, der von Konto A geschrieben wurde?

Die Kernregel der Claude-Cache-Isolation

Die Antwort ist eindeutig: Nein. Caches sind zwischen verschiedenen Organisationen (Organizations) vollständig voneinander isoliert.

Seit dem 5. Februar 2026 hat Anthropic die Granularität der Cache-Isolation weiter von der "Organisationsebene" auf die "Workspace-Ebene" verfeinert. Das bedeutet:

Praktische Auswirkungen der Claude-Cache-Isolation

Szenarioanalyse: Angenommen, Sie haben zwei Claude-API-Konten (zu verschiedenen Organisationen gehörig) und führen gleichzeitig einen Stapel von Datenverarbeitungsaufgaben aus.

• Konto A sendet eine Anfrage, löst einen Cache-Schreibvorgang aus und zahlt die 1,25x Schreibgebühr.
• Konto B sendet innerhalb von 5 Minuten exakt denselben Prompt.
• Ergebnis: Konto B trifft NICHT den Cache von Konto A. Konto B löst ebenfalls einen Cache-Schreibvorgang aus und zahlt erneut 1,25x.

Dieses Design dient Sicherheits- und Datenschutzzwecken – Cache-Inhalte könnten sensible System-Prompts oder Geschäftsdaten enthalten. Eine organisationsübergreifende Freigabe würde das Risiko von Datenlecks bergen.

Optimierungsstrategie: Wenn Sie benötigen, dass mehrere Dienste einen Cache teilen, um Kosten zu senken, sollten Sie deren API-Schlüssel unter demselben Workspace platzieren, anstatt Konten verschiedener Organisationen zu verwenden.

🎯 Praktischer Tipp: Auf der APIYI-Plattform apiyi.com werden Anfragen jedes Benutzers über einen einheitlichen Upstream-Kanal verarbeitet. Wenn Sie einen Cache zwischen mehreren Projekten teilen müssen, empfehlen wir, die Workspace-Struktur in der Anthropic Console sinnvoll zu planen und Projekte, die einen Cache teilen sollen, innerhalb desselben Workspace zu platzieren.

Bedingungen für einen Claude-Cache-Treffer

Neben der Workspace-Isolation gibt es eine weitere Schlüsselbedingung für einen Cache-Treffer – der Prompt muss zu 100% identisch sein.

Der Cache-Schlüssel (Cache Key) wird durch kryptografisches Hashing des Prompt-Inhalts generiert. Der Abgleich umfasst:

• tools (Werkzeugdefinitionen)
• system (System-Eingabeaufforderung)
• messages (Nachrichtenverlauf)

Diese drei Teile werden in dieser Reihenfolge verkettet, bis zur Position des cache_control-Markers. Wenn auch nur ein Zeichen abweicht (einschließlich Leerzeichen, Zeilenumbrüche), wird der Cache nicht getroffen.

Claude-Cache-Abrechnung: AWS Bedrock vs. Anthropic Offiziell im Vergleich

Unterschiede in der Cache-Abrechnung zwischen AWS Bedrock und der Anthropic API

Viele Unternehmen nutzen Claude über AWS Bedrock. Dabei gibt es folgende Unterschiede in der Cache-Abrechnung zur offiziellen Anthropic API:

Wichtige Unterschiede in der AWS Bedrock Claude-Cache-Abrechnung

Unterschied 1: Modellunterstützung für 1-Stunden-Cache

Stand Januar 2026 unterstützt AWS Bedrock den 1-Stunden-Cache-TTL nur für Claude Haiku 4.5, Sonnet 4.5 und Opus 4.5. Die neuesten Modelle Opus 4.6 und Sonnet 4.6 unterstützen auf Bedrock möglicherweise noch keine 1-Stunden-Cache-Option. Wenn du die neuesten Modelle und einen 1-Stunden-Cache benötigst, empfiehlt sich die direkte Nutzung der offiziellen Anthropic API.

Unterschied 2: Granularität der Cache-Isolation

AWS Bedrock hält die Cache-Isolation auf Organization-Ebene (d.h. AWS Account-Ebene) aufrecht, während die offizielle Anthropic API bereits auf Workspace-Ebene verfeinert ist. Das bedeutet, dass bei Bedrock alle Aufrufe unter demselben AWS-Konto den Cache teilen können – die Granularität ist also gröber als bei der offiziellen API.

Unterschied 3: Unterschiede in der regionalen Preisgestaltung

Regionale Endpunkte von AWS Bedrock (wie us-east-1, eu-west-1) können im Vergleich zum globalen Endpunkt einen Preisaufschlag von etwa 10% haben. Dieser Aufschlag spiegelt sich auch in den Gebühren für das Schreiben und Lesen aus dem Cache wider.

💰 Kostenoptimierungs-Tipp: Wenn du hauptsächlich die Claude API nutzt und feingranulare Kontrolle über die Cache-Strategie benötigst, ist der Aufruf über die native Anthropic API via APIYI (apiyi.com) die flexiblere Wahl. Die Plattform unterstützt die vollständige Übergabe von Cache-Steuerungsparametern und bietet zudem günstigere Preise.

Häufig gestellte Fragen

Zusammenfassung

Die Kernpunkte der Claude API-Cache-Abrechnung:

1. 5-Minuten-Cache-Schreiben 1,25x, 1-Stunden-Schreiben 2,0x: In den meisten Szenarien reicht der 5-Minuten-Cache aus. Bei häufigen Aufrufen wird der Cache automatisch verlängert, was einem Langzeit-Cache entspricht.
2. Cache-Lesen nur 0,1x: Nach einem Cache-Treffer werden 90 % der Eingabekosten gespart. Ein einziger Treffer im 5-Minuten-Cache macht die Kosten wett.
3. Cache-Isolierung auf Workspace-Ebene: Zwischen verschiedenen Organisationen und Workspaces kann der Cache nicht geteilt werden. Die Workspace-Struktur muss entsprechend geplant werden.

Für Entwickler, die die Claude API intensiv nutzen, kann eine sinnvolle Cache-Strategie die Kosten erheblich senken. Wir empfehlen, die Claude API über die Plattform APIYI apiyi.com aufzurufen. Sie unterstützt die vollständige Übergabe von Cache-Parametern, bietet ein einheitliches Interface-Management und stellt kostenlose Testguthaben zur Verfügung, um die Wirksamkeit Ihrer Cache-Strategie zu überprüfen.

Referenzen

1. Offizielle Anthropic Prompt Caching-Dokumentation: Vollständige Erklärung der Claude API-Cache-Funktion.

   • Link: platform.claude.com/docs/en/build-with-claude/prompt-caching
   • Beschreibung: Enthält Kernparameter wie Cache-Preismultiplikatoren, TTL-Einstellungen und Mindest-Token-Anforderungen.

2. Anthropic API-Preis-Seite: Aktuelle Preise für alle Claude-Modelle.

   • Link: platform.claude.com/docs/en/about-claude/pricing
   • Beschreibung: Enthält Basispreise für Input/Output sowie detaillierte Preisangaben für Cache-Operationen.

3. AWS Bedrock Prompt Caching-Dokumentation: Anleitung zur Verwendung des Claude-Caches auf der AWS-Plattform.

   • Link: docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
   • Beschreibung: Spezifische Cache-Konfiguration und Liste der unterstützten Modelle für Bedrock.

4. AWS Bedrock 1-Stunden-Cache-Ankündigung: Ankündigung der 1-Stunden-Cache-TTL-Funktion.

   • Link: aws.amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-one-hour-duration-prompt-caching/
   • Beschreibung: Modellumfang und Nutzungsweise des 1-Stunden-Caches in Bedrock.

Autor: APIYI Technikteam
Technischer Austausch: Diskutieren Sie gerne Fragen zur Claude-Cache-Abrechnung in den Kommentaren. Weitere API-Tipps finden Sie im APIYI-Dokumentationszentrum unter docs.apiyi.com.