Memory & Context Editing

Experte

Zuletzt verifiziert: 2026-06-26.

Beide Funktionen befinden sich in der Beta-Phase. Tool-Type-Strings, Beta-Header, Standardwerte und die gemeldeten Benchmark-Gewinne ändern sich — überprüfe dies in der offiziellen memory-tool- und context-editing-Dokumentation, bevor du darauf aufbaust.

Bestätige anhand der offiziellen Quelle.

Ein langlaufender Agent hat zwei Feinde: Er vergisst in dem Moment, in dem das Gespräch endet, was er gelernt hat, und sein Kontextfenster füllt sich mit veralteter Tool-Ausgabe, bis es überläuft. Anthropic liefert für jedes Problem ein Primitiv — das memory tool (Persistenz) und Context Editing (Beschneidung) — und sie sind dafür gedacht, gemeinsam genutzt zu werden.

What you'll learn

• Was das memory tool ist — ein clientseitiger Dateispeicher unter /memories, den du implementierst, nicht Anthropic
• Die sechs Befehle, die dein Handler beantworten muss: view, create, str_replace, insert, delete, rename
• Warum die Validierung gegen Path-Traversal nicht verhandelbar ist, wenn du es einbindest
• Wie Context Editing alte Tool-Ergebnisse automatisch löscht, sobald der Kontext einen Token-Schwellenwert überschreitet
• Wie man beides unter einem Beta-Header kombiniert, und die Fallstricke bei Caching und Reihenfolge

Zwei Probleme, zwei Tools

Halte die beiden Ideen in deinem Kopf getrennt:

• memory tool = Persistenz über Sitzungen hinweg. Claude liest und schreibt Dateien; du speicherst sie.
• Context Editing = Beschneidung innerhalb einer Sitzung. Die API entfernt veraltete Tool-Ergebnisse aus dem Prompt, bevor er Claude erreicht.

Diese Seite ergänzt Prompt Caching und die Token-Ökonomie für die Kostenseite sowie Context Engineering und Harnesses für langlaufende Agenten für das Warum.

Memory- & Kontext-Vokabular

Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.

1 / 5

Das memory tool ist ein Tool, das du implementierst

Das verwirrt die Leute: Das Aktivieren des memory tool gibt dir nicht einen von Anthropic gehosteten Speicher. Es ist ein clientseitiges Tool. Claude gibt Tool-Aufrufe wie view oder create aus; deine Anwendung führt sie gegen ein beliebiges Backend deiner Wahl aus — lokale Dateien, eine Datenbank, verschlüsselte Blobs, Cloud-Speicher — und gibt das Ergebnis zurück. Du bestimmst, wo die Bytes liegen (was auch der Grund ist, warum es Zero-Data-Retention-fähig ist).

Wenn das Tool aktiviert ist, fügt Anthropic eine Systemanweisung ein, die Claude anweist, vor allem anderen sein Memory-Verzeichnis zu prüfen und den Fortschritt während der Arbeit aufzuzeichnen, sodass nichts verloren geht, falls der Kontext zurückgesetzt wird.

Schritt 1 — das Tool aktivieren

Füge das Tool zu deiner Anfrage hinzu. Der Type-String ist die datierte Version memory_20250818.

Python

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=2048,
    messages=[{"role": "user", "content": "Help me respond to this support ticket."}],
    tools=[{"type": "memory_20250818", "name": "memory"}],
)

print(message)

TypeScript

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const message = await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 2048,
  messages: [{ role: "user", content: "Help me respond to this support ticket." }],
  tools: [{ type: "memory_20250818", name: "memory" }],
});

console.log(message);

Die offiziellen SDKs liefern Memory-Helfer mit, damit du die Tool-Schnittstelle nicht selbst zusammenbauen musst — leite BetaAbstractMemoryTool ab (Python, C#), verwende betaMemoryTool (TypeScript) oder implementiere BetaMemoryToolHandler (Java). Sie geben dir einen sauberen Hook, an dem du deinen Speicher einklinkst.

Schritt 2 — die sechs Befehle beantworten

Dein Handler muss diese implementieren. Die Strings, die Claude zurückerwartet, sind spezifisch — passe sie an, damit das Modell die Ergebnisse korrekt interpretiert.

Guided walkthrough1 of 6

1. Liste ein Verzeichnis auf (Dateien bis zu 2 Ebenen tief, mit menschenlesbaren Größen) oder gib den Inhalt einer Datei mit 1-indizierten Zeilennummern zurück. Optionales view_range, um einen Ausschnitt zu lesen.

Ein echtes view des Verzeichnisses gibt etwa Folgendes zurück — beachte den wörtlichen Header und die tabulatorgetrennten Größen, die das Modell zu parsen trainiert ist:

Here're the files and directories up to 2 levels deep in /memories, excluding hidden items and node_modules:
4.0K	/memories
1.5K	/memories/customer_service_guidelines.xml
2.0K	/memories/refund_policies.xml

Schritt 3 — Pfade absichern (überspringe das nicht)

Das memory tool erlaubt einem Modell, beliebige Pfad-Strings auszugeben. Ein vergiftetes Gespräch oder eine Prompt-Injection-Payload kann versuchen, aus /memories auszubrechen und Dateien an anderer Stelle auf deinem System zu lesen oder zu überschreiben. Behandle jeden eingehenden Pfad als feindselig.

Watch out

• Weise jeden Pfad ab, der nicht innerhalb von /memories aufgelöst wird.
• Kanonisiere vor der Prüfung — in Python Path(p).resolve() und prüfe dann, dass .relative_to(memories_root) keine Ausnahme auslöst.
• Blockiere ../, ..\ und URL-kodierte Traversal wie %2e%2e%2f.
• Begrenze Dateigrößen und Lese-Länge, damit ein außer Kontrolle geratener Agent nicht die Festplatte erschöpfen oder den nächsten Prompt sprengen kann.

Dieser Validator ist das ganze Spiel — fixiere und teste ihn, bevor irgendetwas anderes ausgeliefert wird:

Path-Traversal-Schutz (Python)

from pathlib import Path

MEMORY_ROOT = Path("/srv/agent/memories").resolve()

def safe_path(requested: str) -> Path:
  # Map the model's /memories/... onto your real root, then prove containment.
  rel = requested.removeprefix("/memories").lstrip("/")
  candidate = (MEMORY_ROOT / rel).resolve()
  candidate.relative_to(MEMORY_ROOT)  # raises ValueError if it escaped
  return candidate

Context Editing verhindert das Überlaufen des Fensters

Memory löst das Vergessen. Das gegenteilige Problem — ein Kontextfenster, vollgestopft mit alten tool_result-Blöcken aus 40 Web-Suchen zuvor — ist das, was Context Editing löst. Sobald der Prompt einen Token-Schwellenwert überschreitet, löscht die API die ältesten Tool-Ergebnisse (und ersetzt sie durch einen kurzen Platzhalter, damit Claude weiß, dass sie entfernt wurden), bevor der Prompt an das Modell gesendet wird. Dein Client behält die vollständige, unbearbeitete Historie; nur das, was das Modell erreicht, wird gekürzt.

Es läuft über einen Beta-Header:

anthropic-beta: context-management-2025-06-27

Du konfigurierst es mit einem context_management.edits-Array. Die Hauptstrategie ist clear_tool_uses_20250919:

Python

message = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=2048,
    betas=["context-management-2025-06-27"],
    messages=[...],
    tools=[{"type": "memory_20250818", "name": "memory"}],
    context_management={
        "edits": [
            {
                "type": "clear_tool_uses_20250919",
                "trigger": {"type": "input_tokens", "value": 30000},  # start clearing past 30k
                "keep": {"type": "tool_uses", "value": 3},            # always keep the last 3
                "clear_at_least": {"type": "input_tokens", "value": 5000},
                "exclude_tools": ["memory"],                          # never clear memory calls
                "clear_tool_inputs": False,                           # keep the call args, drop results
            }
        ]
    },
)

TypeScript

const message = await anthropic.beta.messages.create({
  model: "claude-opus-5",
  max_tokens: 2048,
  betas: ["context-management-2025-06-27"],
  messages: [...],
  tools: [{ type: "memory_20250818", name: "memory" }],
  context_management: {
    edits: [
      {
        type: "clear_tool_uses_20250919",
        trigger: { type: "input_tokens", value: 30000 },
        keep: { type: "tool_uses", value: 3 },
        clear_at_least: { type: "input_tokens", value: 5000 },
        exclude_tools: ["memory"],
        clear_tool_inputs: false,
      },
    ],
  },
});

Was die Stellschrauben bedeuten:

Parameter	Standard	Was es steuert
trigger	100.000 Input-Tokens	Wann das Löschen einsetzt
keep	3 Tool-Verwendungen	Wie viele aktuelle Tool-Verwendungs-/Ergebnis-Paare immer erhalten bleiben
clear_at_least	keiner	Mindestanzahl pro Aktivierung freigegebener Tokens — verwende es, damit eine Cache-Invalidierung sich tatsächlich lohnt
exclude_tools	keine	Tools, die nie gelöscht werden (z. B. memory, web_search)
clear_tool_inputs	false	Ob auch die Tool-Aufrufargumente verworfen werden, nicht nur das Ergebnis

Die Antwort sagt dir unter context_management.applied_edits, was sie getan hat — z. B. cleared_tool_uses und cleared_input_tokens — sodass du protokollieren kannst, wie viel zurückgewonnen wurde.

Es gibt eine Schwesterstrategie, clear_thinking_20251015, die alte Extended-Thinking-Blöcke beschneidet. Wenn du beide verwendest, liste clear_thinking_20251015 zuerst im edits-Array auf.

Pro tip

• Das Löschen von Tool-Ergebnissen invalidiert jeden Prompt-Cache-Präfix am Löschpunkt — kombiniere es mit clear_at_least, damit du diese Invalidierung nur bezahlst, wenn du einen nennenswerten Block freigibst.
• exclude_tools: ["memory"] ist der übliche Zug: Du willst, dass die eigenen Notizen des Agenten bestehen bleiben und nicht mit veralteten Suchergebnissen weggefegt werden.
• Context Editing (clientseitige Kürzung) und Compaction (serverseitige Zusammenfassung) sind unterschiedliche Funktionen — bei sehr langen Läufen kannst du beide schichten.

Warum man sie kombiniert — die Zahlen

Gemeinsam genutzt lassen die beiden Funktionen einen Agenten weit über ein einzelnes Kontextfenster hinaus laufen: Context Editing hält das aktive Fenster schlank, und alles Wichtige wird ins Memory geschrieben, bevor es gelöscht würde. Anthropic berichtet, dass die Kombination von Memory mit Context Editing eine Verbesserung um 39 % bei einer agentischen Such-Evaluation brachte und dass Context Editing allein die Token-Nutzung um 84 % in einem 100-Runden-Web-Such-Test senkte.

Zuletzt verifiziert: 2026-06-26.

Diese Prozentsätze sind Anthropics eigene Benchmark-Zahlen und spiegeln spezifische Eval-Setups wider — behandle sie als richtungsweisend, nicht als Garantien für deine Arbeitslast. Überprüfe dies in der Context-Management-Ankündigung.

Bestätige anhand der offiziellen Quelle.

Ein Muster, das funktioniert: das Mehrsitzungs-Projektprotokoll

Der sauberste Einsatz von Memory besteht darin, es bewusst zu initialisieren, statt Dateien ad hoc zu schreiben:

Guided walkthrough1 of 4

1. Schreibe vor jeder echten Arbeit ein Fortschrittsprotokoll, eine Feature-Checkliste und einen Hinweis auf ein Startup-Skript, das das Projekt benötigt.

Teste dein Verständnis

Check yourself

0/3

1. 1Wo werden die Daten des memory tool tatsächlich gespeichert?
2. 2Was entfernt die clear_tool_uses_20250919-Strategie von Context Editing?
3. 3Warum musst du jeden Pfad validieren, den das memory tool empfängt?

Quellen & weiterführende Lektüre

• Memory tool — Claude API-Dokumentation — Tool-Type memory_20250818, die sechs Befehle und Sicherheitshinweise.
• Context Editing — Claude API-Dokumentation — die context-management-2025-06-27-Beta, Strategiefelder und Standardwerte.
• Kontextverwaltung auf der Claude Developer Platform — die Ankündigung mit den Benchmark-Zahlen 39 % / 84 %.
• Effektives Context Engineering für KI-Agenten — das Just-in-Time-Retrieval-Muster, für das Memory gebaut ist.
• Effektive Harnesses für langlaufende Agenten — die Fallstudie zum Mehrsitzungs-Projektprotokoll.
• Verwandt auf AILmanac: Context Engineering · Harnesses für langlaufende Agenten · Prompt Caching · Tool Use