Ich betreibe ein Multi-Agent-System in n8n Cloud mit 11 Claude-Haiku-Sub-Workflows, von denen jeder 6–10 Tools und 8–10 Tool-Loop-Iterationen pro Ausführung enthält. Da das Modell bei jeder Iteration der Tool-Loop die vollständige Systemmeldung + Tool-Definitionen erneut versendet, wachsen die Input-Token schnell an, auch bei einem kostengünstigen Modell wie Haiku. Prompt Caching würde das erheblich reduzieren und auch die Latenz etwas verbessern.
Der Standard-Node lmChatAnthropic/AI Agent stellt keine Cache-Control-Header bereit. Es gibt keine Möglichkeit, Systemmeldungen oder Tool-Definitionen in der integrierten LangChain-Integration als cachebar zu markieren. PR #22318 wurde dafür eingereicht und im Mai 2026 ungefiltert geschlossen. Und da ich n8n Cloud nutze (nicht selbstgehostet), ist das Patchen oder Forken des Nodes keine Option.
Der einzige Hebel, den ich gefunden habe, ist der HTTP-Request-Node, mit dem man den Anthropic-API-Aufruf mit korrekten Cache_Control-Headern handschriftlich erstellen kann. Das bedeutet aber, die Tool-Loop manuell neu aufzubauen, was schnell kompliziert wird (Tool-Dispatch, Ergebnis-Injection, Loop-Fortsetzungslogik alle in Code-Nodes).
Das erkunde ich gerade:
Einen Cloudflare Worker, der Cache_Control transparent injiziert, bevor er zu Anthropic weitergeleitet wird.
Manuelle HTTP/Code-Node-Tool-Loop für die teuersten Agents.
Warten auf natives Support von n8n.
Hat jemand:
Den HTTP-Node-Ansatz mit manueller Tool-Loop umgesetzt? Ist das wartbar?
Proxy-/Middleware-Muster gefunden, die Cache_Control injizieren, ohne die Loop neu aufzubauen?
Für die unter euch, die speziell Cloud nutzen – habt ihr andere Workarounds gefunden?
Die Anthropic-Caching-Dokumentation wirkt unkompliziert, aber auf API-Ebene ist es rein ein n8n-Layer-Problem. Ich bin neugierig, wie andere damit umgehen oder ob ihr einfach die Kosten akzeptiert habt.
Der Cloudflare Worker Proxy ist der sauberste Weg für n8n Cloud – du leitest alle Anthropic API-Aufrufe durch einen Worker, der den POST-Body abfängt, "cache_control": {"type": "ephemeral"} in das system-Array und jeden tools-Eintrag injiziert und dann an api.anthropic.com weiterleitet. Deine AI Agent Node-Anmeldedaten zeigen einfach auf die Worker-URL statt direkt auf Anthropic. Der manuelle HTTP-Loop-Ansatz funktioniert zwar, wird aber schwierig zu warten, sobald du die Tool-Result-Injection und Loop-Continuation zuverlässig über 6-10 Iterationen hinweg handhaben musst. Der Worker-Ansatz ermöglicht es dir, das native Agent Node-Verhalten beizubehalten.
Testen Sie vor dem Routing aller Anthropic-Aufrufe über den Worker die Verbindung zunächst bei einem Agent mit hohem Ausgabenniveau und protokollieren Sie die Anthropic-Nutzungsfelder für drei Durchläufe: input_tokens, cache_creation_input_tokens und cache_read_input_tokens. Falls cache_read bei 0 bleibt, injiziert der Proxy wahrscheinlich cache_control in die falsche Ebene oder der System-/Tools-Text ändert sich zwischen den Iterationen.
Was konsistent bleiben muss, ist der Cache-Schlüssel: gleiches Modell, gleicher System-Text und gleiche Tool-Definitionen. Halten Sie dynamische Benutzer-/Task-Daten außerhalb der Cache-markierten Blöcke, sonst erhalten Sie die Komplexität eines Proxys ohne den Einsparungsvorteil.
Vielen Dank, @nguyenthieutoan und @oimrqs_ops - Das ist wirklich hilfreiches Feedback. Ich hatte nicht daran gedacht, die eigentlichen Anthropic-Anmeldedaten dazu zu ändern. Ich werde das testen und berichte der Community Bescheid, inklusive relevanter JSON-Daten. Das scheint tatsächlich eine ziemlich gute und relativ einfache Lösung zu sein.
So @nguyenthieutoan und @oimrqs_ops - das war überraschend einfach zu implementieren, aber ich bin auf ein Problem gestoßen, bei dem nur die Systemmeldung gecacht werden soll. Was ich stattdessen bekomme, sind alle Iterationen der Tool-Schleife, die sie durchläuft, und all diese zusätzlichen Daten werden zum Cache hinzugefügt, aber nicht wiederverwendet. Es gibt praktisch keine Einsparungen.
Ich habe darüber mit Claude diskutiert, aber wir sind noch nicht auf eine Lösung gekommen. Kennst du einen Weg, das zu umgehen?
Das klingt so, als würde der Worker einen sich bewegenden Breakpoint markieren. Anthropic Caching basiert auf Präfixen: Es cached alles bis zum cache_control-Block, daher wird die Tool-Loop-History zu Cache Writes und kann nicht wiederverwendet werden, wenn der Marker nach assistant/tool_result-Turns landet.
Für den n8n Cloud Agent Path halte den Worker streng: Füge cache_control nur zum letzten statischen system/tool-definition-Block hinzu und niemals zu Nachrichten, die während der Loop erstellt werden. Falls n8n dem Worker nur ein sich änderndes Messages-Array sendet, könnte dieser Path keinen sauberen system-only-Breakpoint haben. Kannst du ein redigiertes Before/After-Payload posten, das genau zeigt, wo der Worker cache_control einfügt?
Ich habe die Idee des CF Worker-Proxys mit n8ns AnthropicApi-Credential umgesetzt und dabei eine Base URL verwendet, die auf einen CF Worker zeigt, der cache_control injiziert und Nutzung protokolliert (durch das Parsen von message_start/message_delta), da n8n cache_read_input_tokens nicht nativ zur Verfügung stellt.
Zwei Ergebnisse:
Einzeln-Agents cachen sauber. Statischer System-Prompt + Pro-Anfrage User-Message: Worker markiert den System-Block, Anthropic liest ihn über Läufe hinweg mit 1h TTL zurück. ~75% Einsparung bei den Input-Tokens dieses Prompts.
Multi-Turn Tool-Loops sind immer noch ein Problem. Agent-Node, Haiku + 4–10 Tool-Turns mit erweitertem Denken aktiviert: Auch wenn nur der System-Block markiert wird und cache_control vollständig aus den Nachrichten entfernt wird, cached Anthropic die wachsende Chronik trotzdem automatisch bei jeder Iteration und liest sie nie zurück. Ergebnis: +21% Kosten vs. ohne Cache bei 1h TTL, -10% bei 5m TTL (laut Claudes Auswertung der Logs).
Es scheint, dass Anthropic automatisch über den expliziten Breakpoint hinaus cached, wenn das Gespräch wächst, aber die Tool-Loop-Chronik ist nicht byte-stabil von Turn zu Turn, sodass die Prefix-Entsprechung nach dem System-Block bricht. Wahrscheinlicher Übeltäter: Extended-Thinking-Blöcke (oder ChatAnthropic, das Assistant/Tool_Result-Turns zwischen Iterationen anders serialisiert), die zwischen Iterationen unterschiedlich sind.
Fragen für jeden, der tiefer gegangen ist:
Hat jemand Erfolg dabei gehabt, Tool-Loop-Chroniken über Iterationen hinweg cache-read zu lassen? Was war die Lösung?
Gibt es eine Möglichkeit, Anthropic über einen CF Worker Proxy mitzuteilen „cache nur bis zu diesem Breakpoint, nichts darüber hinaus
Die Extended-Thinking-Blöcke sind fast sicher der Schuldige für Q1 und Q3. Jeder thinking-Inhaltsblock enthält ein signature-Feld, das Anthropic bei jedem Turn neu generiert – es ist nicht byte-stabil, daher bricht das Präfix auch wenn der System- und Tools-Block identisch ist. Die Lösung: Falls diese Sub-Agenten Extended Thinking nicht wirklich benötigen, deaktiviere es. Ohne Thinking-Blöcke ist der einzige dynamische Inhalt in Assistant-Turns tool_use-Ausgabe, die das Präfix zwar immer noch verschiebt, aber zumindest strukturell konsistent bleibt.
Bei Q2 – man kann Anthropic nicht über einen bestimmten Punkt hinaus anweisen, Auto-Caching zu unterdrücken, aber der explizite Breakpoint deines Workers am System-Block ist bereits der richtige Ansatz. Die +21% mit 1h TTL sind der Cache-Write-Overhead – das ist beim ersten Durchlauf zu erwarten. Falls das Präfix bei nachfolgenden Turns tatsächlich übereinstimmte, würdest du Cache-Reads sehen. Falls du sie nicht siehst, bricht das Präfix vor dem System-Block, wahrscheinlich wegen der Thinking-Signaturen upstream.
Bei Q3 – ja, n8ns ChatAnthropic-Node round-trippt Thinking-Blöcke mit ihren Signaturen intakt. Das wird von der Anthropic API verlangt (man kann sie nicht entfernen). Also deaktiviere Extended Thinking auf den Haiku-Sub-Agenten und teste nochmal – das sollte das Präfix ausreichend stabilisieren, um Cache-Reads auf dem System- und Tools-Block über Iterationen hinweg zu ermöglichen.