System-Nachrichten und Tool-Änderungen mitten im Gespräch

Systemanweisungen befinden sich normalerweise im Top-Level-Feld system, vor jeder Nachricht im Gespräch. Diese Position ist ideal für Prompt-Caching: Der „system prompt“ (System-Prompt) ist Teil des stabilen Präfixes, sodass nachfolgende Turns den Cache treffen. Sie ist eine schlechte Position für Anweisungen, deren Notwendigkeit du erst mitten in einer Sitzung erkennst, denn das Bearbeiten des Top-Level-Felds system ändert den allerersten Teil des Prompts und macht den Cache für alles Nachfolgende ungültig.

System-Nachrichten mitten im Gespräch („mid-conversation system messages“) schließen diese Lücke. Du hängst eine {"role": "system"}-Nachricht an der Stelle im Gespräch an, an der die neue Anweisung relevant wird, anstatt das Top-Level-Feld system zu bearbeiten. Das gecachte Präfix bleibt gleich, sodass die nächste Anfrage es weiterhin aus dem Cache liest, und die neue Anweisung wird trotzdem als Systemanweisung angewendet und nicht als gewöhnlicher Benutzertext.

Tool-Änderungen mitten im Gespräch

Das tools-Array liegt im gehashten Anfragepräfix noch weiter vorne als das Top-Level-Feld system, sodass seine Bearbeitung den Prompt-Cache für das gesamte Gespräch ungültig macht. Tool-Änderungen mitten im Gespräch sind das Tool-Gegenstück zu System-Nachrichten mitten im Gespräch. Anstatt die Tool-Liste für die gesamte Lebensdauer des Gesprächs festzulegen, änderst du zwischen den Turns, welche Tools dem Modell angeboten werden: Deklariere den vollständigen Tool-Satz vorab in tools und verwende dann tool_addition- und tool_removal-Blöcke, um dem Modell ab einem bestimmten Punkt im Gespräch ein Tool anzubieten oder es zurückzuziehen. Das tools-Array selbst ändert sich nie, sodass das gecachte Präfix intakt bleibt.

tool_addition und tool_removal sind Content-Blöcke im content-Array einer role: "system"-Nachricht und können in derselben Nachricht mit text-Blöcken gemischt werden. Die Nachricht folgt denselben Platzierungsregeln wie jede System-Nachricht mitten im Gespräch (siehe Einschränkungen), und die Änderung gilt ab diesem Punkt im Gespräch. Das tool-Feld jedes Blocks referenziert ein Tool, anstatt eines zu definieren: {"type": "tool_reference", "name": "..."} benennt ein im tools-Array der Anfrage deklariertes Tool, und MCP-Connector-Tools können einzeln mit mcp_tool_reference (server_name und name) oder als ganzes Toolset mit mcp_toolset_reference (server_name) referenziert werden. Das Referenzieren eines Namens, der nicht in tools deklariert ist, gibt einen 400-Fehler zurück.

Jedes in tools deklarierte Tool wird dem Modell ab Beginn des Gesprächs angeboten, es sei denn, es ist mit defer_loading: true deklariert, wodurch es zurückgehalten wird, bis ein tool_addition-Block es verfügbar macht. tool_addition bietet auch ein Tool erneut an, das ein früherer tool_removal-Block zurückgezogen hat.

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    betas=["mid-conversation-tool-changes-2026-07-01"],
    # Der vollständige Tool-Satz wird vorab deklariert und ändert sich nie, sodass das
    # gecachte Präfix intakt bleibt.
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a location.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {"type": "string", "description": "City name"},
                },
                "required": ["location"],
            },
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "Say OK.",
        },
        # Ziehe get_weather ab diesem Punkt zurück. Der Block referenziert
        # das Tool per Name, statt `tools` zu bearbeiten, sodass frühere Turns
        # byte-identisch bleiben und der Cache weiterhin trifft.
        {
            "role": "system",
            "content": [
                {
                    "type": "tool_removal",
                    "tool": {"type": "tool_reference", "name": "get_weather"},
                },
            ],
        },
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Tool-Änderungen mitten im Gespräch befinden sich in der Beta-Phase. Um sie zu verwenden, füge den Beta-Header mid-conversation-tool-changes-2026-07-01 in deine Anfragen ein.

Wann eine System-Nachricht mitten im Gespräch sinnvoll ist

Prompt-Caching hasht das Anfragepräfix der Reihe nach: tools, dann system, dann messages. Ein Cache-Treffer erfordert, dass das Präfix bis zum Cache-Breakpoint Byte für Byte exakt mit einer kürzlich gestellten Anfrage übereinstimmt.

Diese Reihenfolge bedeutet, dass das Top-Level-Feld system ganz am Anfang des gehashten Präfixes liegt. Jede Änderung daran, selbst das Anhängen eines Satzes, erzeugt einen anderen Hash, und die Anfrage verfehlt den Cache für den System-Prompt und jede gecachte Nachricht danach.

Mit System-Nachrichten mitten im Gespräch kannst du die Anweisung stattdessen am Ende des Nachrichtenverlaufs hinzufügen. Alles vor der neuen Anweisung bleibt unverändert, sodass der bestehende Cache-Eintrag weiterhin passt und nur die neue Nachricht als frische Eingabe verarbeitet wird.

Einige Situationen, in denen das wichtig ist:

• Richtlinien- oder Persona-Änderungen mitten in der Sitzung. Eine lange agentische Sitzung benötigt nach Dutzenden gecachter Turns eine neue Einschränkung („schreibe ab jetzt alle SQL-Abfragen als parametrisierte Queries“). Sie dem Top-Level-Feld system hinzuzufügen, würde den gesamten Verlauf neu verarbeiten.
• Turn-bezogener Kontext, der maßgeblich sein muss. Du möchtest einen Aktualitätshinweis, eine Sitzungsfrist oder eine Änderung der Tool-Verfügbarkeit mit Systemgewicht einfügen, und er ändert sich zu oft, um im gecachten Präfix zu stehen.
• Turn-bezogene Erinnerungen, die sich nicht anhäufen sollen. Ein Harness stupst das Modell nach jedem Stapel von Tool-Ergebnissen an („fordere unabhängige Lesevorgänge gemeinsam an“, „der Benutzer hat schon eine Weile nichts von dir gehört“) und möchte, dass das Modell nur die neueste Kopie sieht. Eine turn-bezogene System-Nachricht wird für einen Turn gerendert und kostet danach nichts, ohne dass etwas aus dem Verlauf gelöscht wird.
• Zustandsänderungen, die deine Anwendung beobachtet. Deine Anwendung bemerkt etwas, das Claude als Tatsache auf Betreiberebene behandeln sollte: Dateien auf der Festplatte haben sich geändert, der Benutzer hat eine Auto-Approve-Einstellung umgeschaltet, die verfügbaren Tools haben sich geändert oder das verbleibende Token-Budget ist unter einen Schwellenwert gefallen.
• Benutzereingaben, die eine agentische Schleife nicht unterbrechen sollen. Ein Benutzer tippt eine Nachfrage, während Claude noch Tools für die vorherige Anfrage ausführt. Wenn du sie nach dem nächsten Tool-Ergebnis als System-Nachricht weiterleitest, kann Claude die neue Eingabe in die bereits laufende Arbeit einbeziehen, anstatt sie als neue Anfrage zu behandeln, zu der gewechselt werden muss. Siehe Platzierung nach Tool-Ergebnissen.
• Moduswechsel, die dauerhafte Berechtigungen erteilen. Ein Modus auf Sitzungsebene kann eine System-Nachricht mitten im Gespräch verwenden, um eine dauerhafte Zustimmung zu einer teuren Fähigkeit zu erteilen, etwa dem automatischen Starten von Multiagenten-Workflows, mit einer kurzen Auffrischung alle paar Turns und einem Hinweis beim Verlassen, wenn der Modus ausgeschaltet wird. Ein ausgearbeitetes Beispiel findest du unter Einen Orchestrierungsmodus erstellen.

In all diesen Fällen könntest du die Anweisung in eine reguläre user-Nachricht setzen, und Claude befolgt durchaus Anweisungen, die in Benutzer-Turns eintreffen. Der Unterschied liegt in der Priorität: Eine user-Nachricht wird so behandelt, als käme sie vom Endbenutzer, während eine system-Nachricht so behandelt wird, als käme sie von dir, dem Betreiber der Anwendung. Wenn beide in Konflikt stehen, haben Systemanweisungen Vorrang. Verwende daher die system-Rolle für Tatsachen und Einschränkungen auf Betreiberebene, die auch dann gelten sollen, wenn der Endbenutzer etwas anderes verlangt. Eine System-Nachricht mitten im Gespräch behält diese Priorität auf Betreiberebene, ohne die Cache-Miss-Kosten für das Bearbeiten des Top-Level-Felds system zu zahlen.

So funktioniert es

Füge dem messages-Array eine Nachricht mit "role": "system" hinzu. Verwende für content einen einfachen String oder Content-Blöcke, genau wie bei einem user- oder assistant-Turn. Die Anweisung gilt ab diesem Punkt im Gespräch. Wenn Anweisungen in Konflikt stehen, haben spätere System-Nachrichten Vorrang vor früheren, und System-Nachrichten mitten im Gespräch haben für die nachfolgenden Turns Vorrang vor dem Top-Level-Feld system.

Du kannst das Top-Level-Feld system weiterhin für Anweisungen setzen, die für das gesamte Gespräch gelten sollen. Reserviere System-Nachrichten mitten im Gespräch für Anweisungen, die erst später relevant werden oder die du hinzufügen möchtest, ohne das gecachte Präfix ungültig zu machen.

Eine role: "system"-Nachricht kann auch output_config.effort tragen, um die Effort-Stufe ab dem nächsten user-Turn zu ändern. Dies befindet sich auf Claude Fable 5.1, Claude Mythos 5.1 und Claude Opus 5 auf der Claude API in der Beta-Phase und erfordert den Beta-Header mid-conversation-output-config-2026-07-01. Siehe Effort pro Nachricht.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    # Automatisches Prompt-Caching: Jede Anfrage cacht die bisherige Konversation,
    # und die nächste Anfrage liest das unveränderte Präfix aus dem Cache.
    cache_control={"type": "ephemeral"},
    system="You are a code review assistant. Be concise.",
    messages=[
        {
            "role": "user",
            "content": "Review process() in utils.py for performance issues.",
        },
        {
            "role": "assistant",
            "content": "The list comprehension is fine for small inputs. For large inputs, consider a generator to avoid materializing the full list.",
        },
        {
            "role": "user",
            "content": "Now review the calling code that invokes process().",
        },
        # Der Reviewer merkt mitten in der Sitzung, dass alle Vorschläge auch
        # die strikte Typisierungsrichtlinie des Teams erfüllen müssen. Die Anweisung
        # hier anzuhängen hält frühere Turns byte-identisch, sodass das von der
        # vorherigen Anfrage gecachte Präfix weiterhin aus dem Cache gelesen wird.
        {
            "role": "system",
            "content": "From now on, every suggestion must include explicit type annotations.",
        },
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Dieses Beispiel aktiviert automatisches Caching mit dem Top-Level-Feld cache_control. Prompt-Caching ist Opt-in: Wenn eine Anfrage kein cache_control-Feld hat (automatisch oder als expliziter Breakpoint), wird nichts gecacht und jede Anfrage zahlt den regulären Input-Token-Preis für das gesamte Gespräch. Bei aktiviertem Caching lässt das Anhängen der System-Nachricht die bereits gecachten Turns unverändert, sodass die Anfrage, die die neue Anweisung trägt, sie weiterhin aus dem Cache liest, anstatt sie erneut zu verarbeiten. Caching erfordert außerdem, dass das Gespräch die minimale cachebare Prompt-Länge erreicht; ein so kurzes Beispiel wie dieses liegt darunter, sodass cache_creation_input_tokens und cache_read_input_tokens bei 0 bleiben, bis das Gespräch wächst.

Eine System-Nachricht mitten im Gespräch muss unmittelbar auf einen user-Turn folgen (oder auf einen assistant-Turn, der mit einem Server-Tool-Ergebnis endet) und muss entweder der letzte Eintrag in messages sein oder unmittelbar von einem assistant-Turn gefolgt werden. Eine user-Nachricht, die tool_result-Blöcke trägt, zählt: In einer agentischen Schleife kannst du die System-Nachricht direkt nach den Tool-Ergebnissen platzieren, vor Claudes nächstem Turn. Jede andere Position, einschließlich zwischen einem assistant-tool_use-Block und dem tool_result, das ihn beantwortet, gibt einen 400-Fehler zurück.

Platzierung nach Tool-Ergebnissen

In einer agentischen Schleife steht die System-Nachricht nach der user-Nachricht, die die Tool-Ergebnisse liefert. Hier kann deine Anwendung auch Eingaben weiterleiten, die der Benutzer getippt hat, während Claude arbeitete, sodass der neue Kontext aufgenommen wird, ohne den Turn neu zu starten:

[
  { "role": "user", "content": "Run the test suite and fix any failures." },
  {
    "role": "assistant",
    "content": [{ "type": "tool_use", "id": "toolu_01", "name": "run_tests", "input": {} }]
  },
  {
    "role": "user",
    "content": [
      { "type": "tool_result", "tool_use_id": "toolu_01", "content": "12 passed, 0 failed" }
    ]
  },
  {
    "role": "system",
    "content": "The user sent the following message while you were working: also update the changelog before you finish."
  }
]

Formuliere den Systeminhalt als Kontext und nicht als Befehl, der den Benutzer übersteuert. Nenne die Tatsache („neue Eingabe vom Benutzer eingetroffen: X“, „das verbleibende Token-Budget beträgt jetzt Y“) und lass Claude darauf reagieren. Claude ist darauf trainiert, Anweisungen zu widerstehen, die gegen den Benutzer zu arbeiten scheinen, und dieser Schutz gilt auch für die System-Rolle. Formulierungen wie „ignoriere, was der Benutzer gesagt hat“ sind daher weniger wirksam als die Angabe, was sich geändert hat.

Dieses Muster dient dazu, Eingaben des eigenen Endbenutzers des Gesprächs weiterzuleiten. Verwende es nicht, um Tool-Ausgaben, abgerufene Dokumente oder andere Inhalte Dritter zu übergeben; belasse solche Inhalte in tool_result-Blöcken (siehe Einschränkungen).

Turn-bezogene System-Nachrichten

Um eine role: "system"-Nachricht auf den aktuellen Turn zu beschränken, setze ihr clear_at-Feld. Es nimmt einen von zwei Werten an:

• "never" (der Standard): Die Nachricht wird bei jeder Anfrage, die sie enthält, an ihrer Position gerendert. Das Weglassen des Felds ist identisch.
• "next_user_message": Die Nachricht ist turn-bezogen („turn-scoped“). Ihr Text wird nur gerendert, solange in messages keine role: "user"-Nachricht nach ihr kommt. Eine Benutzernachricht, die nur tool_result-Blöcke trägt, zählt hier als Benutzernachricht. Sobald eine spätere Benutzernachricht existiert, ist die Nachricht geleert („cleared“): Sie bleibt im Array, rendert aber nichts und kostet keine Input-Token, bei dieser Anfrage und jeder späteren.

Turn-bezogene System-Nachrichten befinden sich in der Beta-Phase. Füge den Beta-Header mid-conversation-system-clear-at-2026-08-21 ein. Ohne ihn wird clear_at als unbekanntes Feld abgelehnt.

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "First privately list what you need next; then request every item that doesn't depend on another's result in this one response."
}

Der Hauptanwendungsfall ist eine turn-bezogene Erinnerung in einer Tool-Schleife. Hänge die Erinnerung jedes Mal nach der tool_result-Nachricht an, wenn das Modell sie sehen soll, und lass jede frühere Kopie dort, wo sie ist. Das Modell sieht nur die Kopien, die nach der letzten Benutzernachricht kommen, sodass sich die Erinnerung nie anhäuft. Nichts Früheres in messages ändert sich, sodass der Prompt-Cache weiterhin passt. Auf Claude Fable 5.1 bleiben dadurch auch spätere Thinking-Blöcke gültig: Das Löschen einer früheren Erinnerung würde das Gespräch vor diesen Blöcken ändern und die Gesprächsprüfung fehlschlagen lassen, während eine geleerte Nachricht im Array bleibt und dieses Gespräch unverändert lässt.

Die folgende Anfrage ist ein späterer Schritt einer Agentenschleife. messages[3] wurde bei der früheren Anfrage gerendert, als es die letzte Nachricht im Array war. Sobald messages[5] (eine spätere Benutzernachricht) existiert, ist messages[3] geleert: Die geleerte Nachricht bleibt im Array, sodass das Gespräch vor dem Thinking-Block in messages[4] unverändert ist, aber das Modell sieht ihren Text nicht mehr. messages[6] und messages[7] werden beide gerendert, in dieser Reihenfolge.

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "messages": [
    { "role": "user", "content": "Fix the failing test." },
    {
      "role": "assistant",
      "content": [
        { "type": "thinking", "thinking": "", "signature": "..." },
        {
          "type": "tool_use",
          "id": "toolu_01",
          "name": "read_file",
          "input": { "path": "test_auth.py" }
        }
      ]
    },
    {
      "role": "user",
      "content": [{ "type": "tool_result", "tool_use_id": "toolu_01", "content": "..." }]
    },
    {
      "role": "system",
      "clear_at": "next_user_message",
      "content": "Request independent reads in one turn."
    },
    {
      "role": "assistant",
      "content": [
        { "type": "thinking", "thinking": "", "signature": "..." },
        {
          "type": "tool_use",
          "id": "toolu_02",
          "name": "read_file",
          "input": { "path": "auth.py" }
        },
        {
          "type": "tool_use",
          "id": "toolu_03",
          "name": "read_file",
          "input": { "path": "tokens.py" }
        }
      ]
    },
    {
      "role": "user",
      "content": [
        { "type": "tool_result", "tool_use_id": "toolu_02", "content": "..." },
        {
          "type": "tool_result",
          "tool_use_id": "toolu_03",
          "content": "...",
          "cache_control": { "type": "ephemeral" }
        }
      ]
    },
    {
      "role": "system",
      "clear_at": "next_user_message",
      "content": "Request independent reads in one turn."
    },
    {
      "role": "system",
      "clear_at": "next_user_message",
      "content": "The shell exited with status 137."
    }
  ]
}

Regeln für turn-bezogene Nachrichten:

• Sende geleerte Nachrichten wortwörtlich erneut. Eine geleerte Nachricht ist weiterhin Teil des Gesprächsverlaufs. Sie aus dem aktuellen Zustand neu aufzubauen (eine frische Token-Zählung, ein Zeitstempel), sie als redundant wegzulassen oder ihren clear_at-Wert zu ändern, ist eine Bearbeitung einer früheren Nachricht. Der Prompt-Cache verfehlt ab diesem Punkt, und auf Claude Fable 5.1 schlägt jeder danach erzeugte Thinking-Block bei der Gesprächsprüfung fehl.
• Nur Text. content besteht aus einem oder mehreren text-Blöcken (oder einem String). tool_addition- und tool_removal-Blöcke geben bei einer turn-bezogenen Nachricht einen 400-Fehler zurück, ebenso output_config. Verwende dafür eine separate role: "system"-Nachricht ohne clear_at.
• Kein cache_control auf ihren Blöcken. Eine geleerte Nachricht ist nie Teil eines Cache-Schlüssels, sodass ein Breakpoint auf ihr nie passen könnte. Setze den Breakpoint stattdessen auf den letzten Block des vorangehenden Benutzer-Turns, wie es das Beispiel tut. Das Top-Level-Feld für automatisches Caching überspringt turn-bezogene Nachrichten, wenn es einen Breakpoint wählt. Bei der Anfrage, die eine Nachricht leert, endet das wiederverwendbare gecachte Präfix beim Benutzer-Turn davor, sodass nur der eine Assistant-Turn zwischen dieser Nachricht und der neuen Benutzernachricht neu verarbeitet wird.
• Platzierungsregeln gelten weiterhin, geleert oder nicht. Eine turn-bezogene Nachricht muss auf einen user-Turn folgen (oder auf einen assistant-Turn, der mit einem Server-Tool-Ergebnis endet) und einem assistant-Turn vorangehen oder das Array beenden, wie jede System-Nachricht mitten im Gespräch. Eine, die das Array beendet, wird immer gerendert. Eine, auf die direkt eine weitere user-Nachricht folgt, ist ein 400-Fehler, keine geleerte Nachricht: Setze alle Ergebnisse einer Tool-Runde in eine Benutzernachricht und die Erinnerungen danach.
• Assistant-Turns leeren sie nicht. Ein vorausgefüllter oder pausierter Assistant-Turn nach der Nachricht oder eine serverseitige Tool-Schleife fügt keine Benutzernachricht hinzu, sodass die Nachricht bei dieser Fortsetzung weiterhin gerendert wird. Um eine Erinnerung während einer clientseitigen Tool-Schleife sichtbar zu halten, hänge sie nach jeder tool_result-Nachricht erneut an.
• Die Token-Zählung folgt dem, was gerendert wird. Eine geleerte Nachricht fügt weder usage.input_tokens noch einer Token-Zählung etwas hinzu.
• Importierter Verlauf. In einem Transkript, das du in einem Schritt konstruierst (Few-Shot-Beispiele, ein migriertes Gespräch), ist eine turn-bezogene Nachricht, nach der bereits ein Assistant-Turn und eine Benutzernachricht stehen, ab der ersten Anfrage geleert und wird nie gerendert. Das ist der richtige Zustand für eine turn-bezogene Erinnerung, die du übernimmst. Lass clear_at nur bei einer Nachricht ungesetzt, die das Modell bei jeder Anfrage sehen soll.

Die Validierungsfehler sind:

messages.3.clear_at: Extra inputs are not permitted
messages.3.clear_at: clear_at is only permitted on role 'system' messages
messages.3.clear_at: Input should be 'next_user_message' or 'never'
messages.3: a turn-scoped system message supports text blocks only (clear_at: 'next_user_message')
messages.3: output_config is not permitted on a turn-scoped system message (clear_at: 'next_user_message')
messages.3.content.0: cache_control is not permitted on a turn-scoped system message (clear_at: 'next_user_message')

Der erste ist der Fehler, der ohne den Beta-Header zurückgegeben wird. Auf Amazon Bedrock und Google Cloud übergibst du den Beta-Wert wie unter Beta-Header beschrieben.

Über die SDKs setzt du clear_at auf dem role: "system"-Eintrag in messages und sendest den Beta-Header. Das folgende Beispiel hängt eine turn-bezogene Erinnerung nach dem Benutzer-Turn an; bei der nächsten Anfrage, sobald eine spätere Benutzernachricht existiert, bleibt die Erinnerung im Array, wird aber nicht mehr gerendert:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "Draft a short status update on the database migration for the team channel.",
        },
        # Turn-bezogene Erinnerung: wird für diesen Turn gerendert und dann gelöscht, sobald eine spätere Benutzernachricht existiert.
        {
            "role": "system",
            "clear_at": "next_user_message",
            "content": "The reader is on call: keep this reply under 50 words.",
        },
    ],
    betas=["mid-conversation-system-clear-at-2026-08-21"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Kombination mit Prompt-Caching

System-Nachrichten mitten im Gespräch und Prompt-Caching sind dafür ausgelegt, gemeinsam verwendet zu werden:

• Aktiviere Caching explizit. Caching findet nur statt, wenn die Anfrage cache_control enthält, entweder das Top-Level-Feld für automatisches Caching oder einen expliziten Breakpoint auf einem Content-Block. Eine System-Nachricht mitten im Gespräch erzeugt von sich aus keinen Cache-Eintrag, und ohne aktiviertes Caching gibt es keine Einsparungen, die bewahrt werden könnten.
• Cache das stabile Präfix wie gewohnt. Setze cache_control auf den letzten Block, der über Anfragen hinweg gleich bleibt, sei es das Ende des Top-Level-Felds system, das Ende deiner Tool-Definitionen oder ein stabiler Punkt im Nachrichtenverlauf.
• Hänge die System-Nachricht nach dem Breakpoint an. Da sie nach dem gecachten Präfix kommt, ändert sie den Präfix-Hash nicht und der Cache trifft weiterhin.
• Eine System-Nachricht mitten im Gespräch ist selbst cachebar. Sobald sie im Gespräch ist, wird sie Teil des stabilen Verlaufs. Beim nächsten Turn kannst du deinen Cache-Breakpoint hinter sie verschieben (oder dich darauf verlassen, dass automatisches Caching dies tut), und die System-Nachricht wird wie jeder andere Turn aus dem Cache gelesen.

Vermeide es, eine bereits gesendete System-Nachricht mitten im Gespräch zu bearbeiten oder zu entfernen. Wie jede andere Änderung an früheren Nachrichten macht das den Cache ab diesem Punkt ungültig. Auf Claude Fable 5.1 macht es außerdem die Thinking-Blöcke in jedem späteren Assistant-Turn ungültig. Für Anleitungen, die nur für einen Turn gelten sollen, verwende eine turn-bezogene System-Nachricht und lass sie an ihrem Platz. Wenn sich die Anweisung weiterentwickeln muss, hänge eine neue System-Nachricht an, anstatt die alte umzuschreiben. Aufeinanderfolgende System-Nachrichten werden akzeptiert und als ein einziger Systemabschnitt behandelt, der als Ganzes derselben Platzierungsregel folgt.

Einschränkungen

• Nicht für die erste Nachricht. Eine system-Nachricht, die Inhalt trägt, kann nicht der erste Eintrag in messages sein. Verwende das Top-Level-Feld system für Anweisungen, die von Anfang an gelten.
• Die Platzierung ist eingeschränkt. Eine system-Nachricht, die Inhalt trägt (text-, tool_addition- oder tool_removal-Blöcke), muss unmittelbar auf einen user-Turn folgen (einschließlich eines user-Turns, der tool_result-Blöcke trägt) oder auf einen assistant-Turn, der mit einem Server-Tool-Ergebnis endet, und muss einem assistant-Turn vorangehen oder das Array beenden. Sie kann nicht zwischen einem tool_use-Block und seinem tool_result stehen. Eine Platzierung an anderer Stelle gibt einen 400-Fehler zurück. Eine Nachricht mit leerem content, die nur output_config.effort setzt, rendert an ihrer Position nichts und wird überall in messages akzeptiert, auch an erster Stelle oder zwischen einem assistant-Turn und einem user-Turn. Aufeinanderfolgende system-Nachrichten werden gemeinsam beurteilt, sodass das Hinzufügen einer texttragenden Nachricht neben einer reinen Effort-Nachricht dazu führt, dass die gesamte Gruppe der Inhaltsregel folgt.
• Turn-bezogene Nachrichten sind reiner Text und werden wortwörtlich erneut gesendet. Eine clear_at: "next_user_message"-Nachricht trägt kein tool_addition, tool_removal, output_config oder cache_control, und sobald sie geleert ist, muss sie bei späteren Anfragen Byte für Byte in messages bleiben. Siehe Turn-bezogene System-Nachrichten.
• Kein Ort für nicht vertrauenswürdige Inhalte. Claude behandelt Systeminhalte als Betreiberanweisungen und befolgt sie. Setze keinen Text von außerhalb des Gesprächs, wie rohe Tool-Ausgaben, abgerufene Dokumente oder Webinhalte, direkt in eine System-Nachricht; dadurch erhält dieser Text Autorität auf Betreiberebene. Belasse solche Daten in tool_result-Blöcken und befolge weiterhin Jailbreaks und Prompt-Injections abschwächen.

Verwandte Themen