Context Engineering für Claude 5: Der komplette Praxis-Guide

Was hat sich beim Context Engineering für Claude 5 geändert?

Context Engineering ist die Gestaltung des gesamten Arbeitskontexts eines Modells. Dazu zählen nicht nur der Nutzerprompt und `CLAUDE.md`, sondern auch Systeminstruktionen, Tool-Definitionen, Skills, Memory, gelesene Dateien, Tool-Ergebnisse und die bisherige Konversation. Das Ziel ist nicht der kürzeste Prompt, sondern der kleinste Satz hochwertiger Tokens, der eine Aufgabe zuverlässig lösbar macht.

Am 24. Juli 2026 veröffentlichte Anthropic seine neuen Regeln für Claude-5-Modelle. Der zentrale Claim: Für Modelle wie Opus 5 und Fable 5 habe das Unternehmen mehr als 80 Prozent des Claude-Code-Systemprompts gelöscht. In den internen Coding-Evaluierungen sei dabei kein messbarer Qualitätsverlust entstanden. Anthropic bezeichnet diesen Abbau historisch gewachsener Fesseln als „Unhobbling“.

Das klingt radikaler, als es praktisch ist. Anthropic hat nicht gezeigt, dass beliebige Teams vier Fünftel ihrer Anweisungen löschen können. Weder der gekürzte Prompt noch detaillierte Evaldaten oder unabhängige Reproduktionen liegen in den verwendeten Quellen vor. Der Befund gilt zunächst für Anthropics Systemprompt, die genannten Modelle und interne Programmier-Evaluierungen.

Die technische Kernthese ist trotzdem plausibel: Wenn Systemprompt, `CLAUDE.md`, Skill und Nutzerauftrag dieselbe Frage unterschiedlich beantworten, muss das Modell den Konflikt auflösen, bevor es die Aufgabe bearbeitet. Mehr Regeln können dann weniger Steuerbarkeit erzeugen. Dieser Gedanke ergänzt den bestehenden Ansatz von Prompt Engineering über Context und Harness bis Loop Engineering: Der Prompt bleibt wichtig, aber er ist nur eine Schicht des Systems.

Welche sechs Regeln empfiehlt Anthropic jetzt?

Anthropic beschreibt sechs Verschiebungen vom alten zum neuen Pattern. Keine davon ist ein absolutes Verbot. Ältere und kleinere Modelle, ungewöhnliche Schnittstellen oder regulierte Prozesse können weiterhin mehr explizite Führung benötigen.

Früheres Pattern	Neues Pattern	Praktische Konsequenz	Wichtige Grenze
Regeln vorgeben	Urteilsspielraum geben	Lokale Qualitätskriterien statt pauschaler Verbote	Sicherheit und Compliance nicht dem Ermessen überlassen
Beispiele geben	Interfaces gestalten	Typen, Enums und klare Felder statt vieler Few-Shot-Beispiele	Ungewöhnliche APIs brauchen eventuell ein gezieltes Beispiel
Alles vorab laden	Progressive Disclosure	Spezialwissen erst bei Bedarf über Skills und Referenzen laden	Ein nicht ausgelöster Skill kann kritisches Wissen verstecken
Instruktionen wiederholen	Einfache Tool-Beschreibungen	Tool-Semantik an einer Stelle pflegen	Andere Modellklassen können von Redundanz profitieren
Memory in `CLAUDE.md`	Auto-Memory	Persönliche und dynamische Erkenntnisse vom Repo-Wissen trennen	Memory kann veralten oder manipuliert werden
Einfache Spezifikationen	Reichhaltige Referenzen	Tests, Codepfade und HTML-Mockups als konkrete Zielbilder nutzen	Referenzmasse kann Context Rot verstärken

Wie ersetzt Du starre Regeln durch Qualitätskriterien?

Eine alte Anweisung wie `Never write multi-line comments` ist eindeutig, aber blind für den lokalen Code. In einer knapp kommentierten Utility-Datei kann sie passen, in einem kryptografischen Modul oder einer öffentlichen API nicht. Anthropics neues Pattern beschreibt das gewünschte Ergebnis:

Match the surrounding code's naming, comment density, and idiom.
Document non-obvious behavior when the surrounding project does so.

Damit delegierst Du eine weiche Qualitätsentscheidung. Du delegierst jedoch keine Risikogrenze. „Passe Dich dem Repository an“ darf niemals eine verbindliche Regel wie „Produktionsdaten nicht über einen anonymen Client verändern“ ersetzen.

Warum sind gute Interfaces besser als viele Beispiele?

Beispiele zeigen nur ausgewählte Pfade. Ein enges Set kann das Modell auf diese Varianten fixieren, obwohl die Schnittstelle mehr erlaubt. Ein Schema macht den zulässigen Handlungsraum explizit:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["id", "content", "status"],
  "properties": {
    "id": { "type": "string", "minLength": 1 },
    "content": { "type": "string", "minLength": 1 },
    "status": {
      "type": "string",
      "enum": ["pending", "in_progress", "completed", "cancelled"]
    }
  }
}

Das Schema ersetzt keine Dokumentation nicht offensichtlicher Seiteneffekte. Wenn `cancelled` beispielsweise bereits ausgelöste Zahlungen nicht zurücknimmt, gehört dieser Hinweis direkt in die Tool-Beschreibung.

Was bedeutet Progressive Disclosure konkret?

Code Review, Datenbankmigration, Frontend-Prüfung und Deployment müssen nicht in jeder Session vollständig im Basiskontext stehen. Claude Code kann spezialisierte Abläufe über Skills selektiv laden. Das spart statischen Kontext und trennt Verantwortlichkeiten.

Diese Trennung hat einen Preis: Laufzeit-Erkundung ist langsamer als vorab geladener Kontext. Außerdem muss die Skill-Beschreibung den Auslöser klar benennen. „Hilft bei Qualität“ ist zu vage. „Nach Änderungen an React-Komponenten ausführen; prüft Darstellung, Konsole und Tastaturbedienung“ ist auffindbar.

Wo sollte eine Tool-Anweisung stehen?

Tool-spezifische Regeln gehören möglichst in die Tool-Beschreibung oder das Schema, nicht zusätzlich in Systemprompt, `CLAUDE.md` und Skill. Eine zentrale Definition reduziert Widersprüche und Pflegeaufwand. Eine feste Token- oder Kostenersparnis lässt sich daraus ohne Messung nicht ableiten.

Was unterscheidet Auto-Memory von Projektwissen?

`CLAUDE.md` ist versioniertes Teamwissen. Auto-Memory ist maschinenlokales, dynamisches Wissen über wiederkehrende Präferenzen und frühere Sitzungen. Laut Claude-Code-Dokumentation zu Memory dient `MEMORY.md` als Index; Claude Code lädt beim Start die ersten 200 Zeilen oder die ersten 25 KB, je nachdem, welche Grenze zuerst erreicht wird. Worktrees und Unterverzeichnisse desselben Git-Repositories teilen sich ein lokales Auto-Memory-Verzeichnis; andere Rechner und Cloud-Umgebungen teilen diese Dateien nicht.

Das ist kein Grund, kritische Projektfakten ins Memory zu verschieben. Eine neue Entwicklerin, CI oder ein anderer Agent muss Repo-Regeln auch ohne Florians lokale Historie kennen.

Was sind Rich References?

Eine ausführbare Test-Suite ist eine präzisere Referenz als „Die API darf sich nicht verändern“. Ein vorhandener Codepfad zeigt Namensgebung und Fehlerbehandlung besser als eine abstrakte Stilbeschreibung. Ein HTML-Mockup enthält mehr strukturelle Information als ein Absatz über das gewünschte Layout.

Rich References bedeuten Qualität vor Masse. Lade nicht das gesamte Repository, wenn drei Dateien, ein Test und ein Schema genügen. Genau hier bleibt Context Rot relevant.

Wie baust Du eine überladene CLAUDE.md um?

Die falsche Migration lautet: Datei öffnen, 80 Prozent der Zeilen markieren, löschen. Die richtige Migration beginnt mit einer Inventur.

Schritt 1: Jede Anweisung klassifizieren

Klasse	Beispiel	Zielort
Projektfakt	Produktionsinhalte kommen aus Supabase	`CLAUDE.md`
Nicht offensichtlicher Architekturzwang	Generierte Typen bleiben in einem festen Pfad	`CLAUDE.md`
Qualitätspräferenz	Kommentardichte an die Umgebung anpassen	kurz in `CLAUDE.md` oder aus dem Code ableiten
Langer Workflow	Frontend nach Änderungen visuell prüfen	Skill
Tool-Semantik	erlaubte Statuswerte eines Tasks	Tool-Schema
Persönliche Präferenz	Antworten knapp halten	Auto-Memory
Sicherheitsgrenze	kein Produktions-Write mit Anon-Key	`CLAUDE.md` plus technische Enforcement-Schicht
Offensichtliches	vor Änderung die relevante Datei lesen	löschen, sofern der Agent das zuverlässig beherrscht

Schritt 2: Widersprüche und Dubletten entfernen

Suche nach `always`, `never`, `must`, `do not` und mehrfach beschriebenen Tools. Prüfe jede Regel gegen drei Fragen:

1. Kann Claude die Information aus Code, Dateisystem oder Schema ableiten?
2. Gilt sie wirklich für jede Aufgabe und jede Datei?
3. Welche technische Kontrolle erkennt oder verhindert einen Verstoß?

Eine Regel ohne aktuellen Grund ist historischer Ballast. Eine Sicherheitsregel ohne technische Kontrolle ist nur eine probabilistische Bitte.

Schritt 3: Den Basiskontext auf ein klares Zielbild reduzieren

Ein belastbares Ergebnis kann so aussehen:

<!-- CLAUDE.md -->

## Repository
React/TypeScript application. Production content is read from Supabase.

## Commands
- Unit tests: `npm test`
- Type check: `npm run typecheck`
- Build: `npm run build`

## Non-obvious constraints
- Keep generated Supabase types in `src/integrations/supabase/types.ts`.
- Never write production content through the anonymous Supabase client.
- Match the surrounding component's naming, comment density, and test style.

## On-demand workflows
- Frontend changes: use the `verify-frontend` skill.
- Schema changes: use the `database-migration` skill.
- Security-sensitive diffs: use the `security-review` skill.

Die Datei enthält Repozweck, echte Befehle, wenige gefährliche Gotchas und Navigation. Sie versucht nicht, jeden späteren Arbeitsablauf vorwegzunehmen. Eine universelle Soll-Länge gibt es nicht. Signalqualität, Konfliktfreiheit und Auffindbarkeit sind wichtiger als eine willkürliche Zeilenzahl.

Schritt 4: `/doctor` als Diagnose nutzen

Anthropic verweist im Artikel vom 24. Juli 2026 auf `/doctor`, um Skills und `CLAUDE.md` für die neue Modellklasse zu dimensionieren. Das Kommando ersetzt kein Review. Prüfe vorgeschlagene Kürzungen gegen Architektur, Security und unterstützte Modelle, bevor Du sie übernimmst.

Wie spielen Skills, Tools, References und Memory zusammen?

Eine saubere Kontextarchitektur verteilt Wissen nach Lebensdauer und Aufgabe:

CLAUDE.md
├── Repozweck, Befehle und dauerhafte Gotchas
├── Verweise auf bedarfsgesteuerte Workflows
└── keine Sitzungsnotizen

.claude/skills/
├── verify-frontend/SKILL.md
├── database-migration/SKILL.md
└── security-review/SKILL.md

Tool-Schemas
├── Typen, Enums und erforderliche Felder
├── Seiteneffekte und Fehlerverhalten
└── möglichst keine duplizierten Prompt-Regeln

Auto-Memory
├── persönliche Präferenzen
├── lokale Workflow-Erkenntnisse
└── überprüf- und löschbare Sitzungsnotizen

Rich References
├── ausführbare Tests
├── repräsentative Codepfade
└── strukturierte Mockups oder Rubriken

Dieses System ist ein AI Harness: Das Modell entscheidet nicht isoliert, sondern arbeitet innerhalb von Werkzeugen, Zuständen, Berechtigungen und Feedbackschleifen.

Wann brauchst Du Compaction und Tool-Result-Clearing?

Die Anthropic-Dokumentation zu Context Engineering trennt zwei Mechanismen:

Mechanismus	Was passiert?	Geeignet für	Risiko
Tool-Result-Clearing	Alte Tool-Ergebnisse werden durch kurze Platzhalter ersetzt; der Tool-Aufruf bleibt sichtbar	erneut abrufbare Dateiinhalte und API-Antworten	spätere Direktvergleiche verlieren ihre Rohdaten
Compaction	Die bisherige Historie wird in eine kompakte Zusammenfassung überführt	lange Sessions mit viel Dialog und Argumentation	Details, Zahlen oder exakte Formulierungen können verloren gehen

Tool-Result-Clearing ist ungeeignet, wenn mehrere große Ergebnisse später Zeile für Zeile verglichen werden müssen. Compaction sollte kritische Entscheidungen, offene Fehler und unveränderliche Anforderungen explizit erhalten. Beide Verfahren verwalten Kontext; keines ersetzt eine versionierte Spezifikation.

Wie baust Du Verification Loops statt Prompt-Mikromanagement?

Verification ist der entscheidende Gegenpol zu weniger Regeln. Anthropic beschreibt in seinem Beitrag vom 22. Juli 2026 vier Ausführungsmuster für Verification Loops:

Muster	Einsatz
Standalone	Ein `/verify`-Skill wird bewusst nach einer Änderung gestartet
Embedded	Die Prüfung ist fester Bestandteil eines einzelnen Workflows
Chained	Ein Skill ruft anschließend einen anderen Prüf-Skill auf
On every PR	Dieselben stabilisierten Prüfungen laufen für jede Pull Request als Team-Gate

Ein Frontend-Workflow kann beispielsweise nicht nur „sieht gut aus“ verlangen, sondern folgende Signale erheben:

## Verification
1. Run the project's type checker and targeted tests.
2. Start the application with the documented command.
3. Open the changed route at desktop and mobile viewport widths.
4. Check browser console and network failures.
5. Verify keyboard navigation for changed interactive elements.
6. Fix failures and repeat all affected checks.
7. Report commands, observed results, and remaining limitations.

Solche Loops kombinieren Modellurteil mit deterministischen Signalen. Tests, Typechecker und Schemas erkennen definierte Fehler. Ein visueller oder fachlicher Review bewertet Aspekte, die nicht vollständig formalisierbar sind. Bei Publizieren, Löschen, Deployment und Produktionszugriff bleibt ein Human-Gate sinnvoll.

Wie testest Du altes gegen neues Context Engineering?

Ohne echte Messwerte wäre „die neue Architektur ist besser“ nur eine Hypothese. Ein reproduzierbares Testprotokoll ist belastbarer als eine erfundene Erfolgsgeschichte.

Welche Bedingungen müssen identisch sein?

• dasselbe Repository und derselbe Commit,
• dieselbe mittelgroße, testbare Aufgabe,
• dasselbe Claude-5-Modell und dieselbe Claude-Code-Version,
• frische Session für jeden Lauf,
• keine gemeinsamen Memories zwischen A und B,
• identische Tools und Permissions,
• getrennte Git-Worktrees,
• mindestens drei, besser fünf Läufe pro Variante.

Als Aufgabe eignet sich beispielsweise: „Extrahiere die Validierungslogik aus einer React-Komponente in ein typisiertes Modul, ergänze Grenzfalltests und halte die öffentliche API unverändert.“ Eine Einzeilenänderung ist zu trivial; „verbessere den Code“ ist nicht objektiv auswertbar.

Was unterscheidet Variante A und B?

Bereich	Variante A: altes Pattern	Variante B: neues Pattern
`CLAUDE.md`	monolithisch, alle Regeln vorab	Repozweck, Befehle und Gotchas
Qualität	pauschale `always`- und `never`-Regeln	kontextabhängige Kriterien
Tools	Beispiele im Prompt	typisierte, selbsterklärende Schemas
Workflows	lange Checklisten im Basiskontext	Skills per Progressive Disclosure
Memory	Sitzungswissen in `CLAUDE.md`	getrenntes Auto-Memory
Referenzen	abstrakte Spezifikation	Tests und vorhandene Codepfade
Verifikation	identische technische Gates	identische technische Gates

Die technischen Gates müssen identisch bleiben. Sonst misst Du nicht die Kontextarchitektur, sondern unterschiedliche Sicherheits- und Qualitätskontrollen.

Welche Metriken zählen?

Metrik	Erhebung	Gewicht im Beispiel
Tests bestanden	automatisiert	25 %
Anforderungen erfüllt	Blindreview gegen feste Rubrik	20 %
Regressionen oder neue Fehler	Tests plus Review	20 %
unnötiger Diff und Overengineering	Blindreview	10 %
Input- und Output-Tokens getrennt	Usage-Daten	10 %
Zeit bis zum Abschluss	Laufzeitmessung	5 %
Tool-Calls und Korrekturschleifen	Transcript-Auswertung	5 %
Sicherheits- oder Policy-Verstöße	automatisierte Gates	5 %

Input- und Output-Tokens müssen getrennt erfasst werden. Weniger statischer Prompt kann durch zusätzliche Suche, Skill-Aufrufe oder Korrekturschleifen kompensiert werden. Dasselbe gilt für die Laufzeit. Qualität und Robustheit sind wichtiger als eine isolierte Tokenzahl.

| Lauf | Variante | Tests | Rubrik | Regressionen | Input-Tokens | Output-Tokens | Dauer | Tool-Calls |
|---:|---|---:|---:|---:|---:|---:|---:|---:|
| 1 | Alt | TBD | TBD | TBD | TBD | TBD | TBD | TBD |
| 1 | Neu | TBD | TBD | TBD | TBD | TBD | TBD | TBD |

Solange die Läufe nicht stattgefunden haben, bleibt jede Ergebniszelle `TBD`. Dokumentiere zusätzlich Modell, CLI-Version, Commit, Permissions und `/doctor`-Ausgabe am Testtag.

Wo scheitert Context Engineering für Claude 5?

Warum ist der 80-Prozent-Claim kein Universalgesetz?

Anthropic berichtet über den eigenen Claude-Code-Systemprompt und interne Coding-Evaluierungen. Daraus folgt weder eine proportionale Kostenersparnis noch ein allgemeiner Qualitätsgewinn. Die Aussage validiert keine Rechts-, Medizin-, Finanz- oder Compliance-Aufgabe. Sie beweist auch nicht, dass Sonnet, Haiku, ältere Claude-Versionen oder Fremdmodelle mit derselben Reduktion funktionieren.

Für Multi-Modell-Repositories gilt daher der kleinste gemeinsame Nenner. Dauerhafte Repo-Regeln müssen für alle unterstützten Agenten verständlich bleiben. Modellabhängige Optimierungen gehören in eigene Schichten und brauchen separate Evaluierungen.

Schützt ein Kontextfenster mit einer Million Tokens vor Context Rot?

Nein. Anthropic nennt für Opus 5 ein natives Kontextfenster von einer Million Tokens. Kapazität ist aber keine Garantie für gleichmäßig zuverlässigen Abruf.

Chroma untersuchte in seinem Context-Rot-Report vom 14. Juli 2025 insgesamt 18 Modelle, darunter Claude 4, GPT-4.1, Gemini 2.5 und Qwen3; wegen Kontextfenster- und Thinking-Budget-Grenzen nahm nicht jedes Modell an jedem Experiment teil. In kontrollierten Vergleichen hielten die Autoren die Aufgabenkomplexität konstant und variierten die Inputlänge; zusätzliche Versuchsreihen prüften unter anderem semantische Ähnlichkeit und Distraktoren. Die Leistung wurde mit wachsendem Input häufig schlechter oder nichtuniform. Das ist kein direkter Test von Opus 5, aber ein belastbarer Gegenpunkt zum Schluss „mehr Fenster löst das Kontextproblem“.

Die Studie Lost in the Middle von Liu et al., erstmals eingereicht am 6. Juli 2023 zeigte zudem, dass relevante Informationen in der Mitte langer Kontexte schlechter abgerufen werden können als am Anfang oder Ende. Auch diese ältere Untersuchung beweist kein konkretes Opus-5-Verhalten. Sie begründet aber, warum relevante Auswahl und Position weiterhin zählen.

Warum bleibt Prompt Injection gefährlich?

Claude Code kann Webseiten, Tickets, E-Mails, RAG-Dokumente und fremde Repositories lesen. Darin können indirekte Prompt Injections stecken. OWASP führt Prompt Injection als LLM01:2025 und empfiehlt unter anderem Least Privilege, klare Vertrauensgrenzen, Ausgabevalidierung, Human Approval für riskante Aktionen und adversariale Tests.

Weniger Systemprompt reduziert diese Angriffsfläche nicht. Externe Inhalte müssen als Daten behandelt werden, nicht als autorisierte Instruktionen. Memory-Schreibzugriffe brauchen Kontrolle, damit eine manipulierte Webseite keine dauerhafte „Erkenntnis“ hinterlässt. Riskante Tools benötigen minimale Rechte, Allow-/Deny-Listen, Schemas, Sandboxes und Freigaben.

Welche Risiken hat Auto-Memory?

Memory kann veraltete Projektzustände, halluzinierte Kausalitäten oder eine persönliche Präferenz als allgemeine Teamregel konservieren. Prüfe deshalb regelmäßig:

• Welche Einträge sind noch aktuell?
• Ist die Herkunft nachvollziehbar?
• Kann der Eintrag gelöscht oder korrigiert werden?
• Gehört er stattdessen versioniert ins Repository?
• Stammt er möglicherweise aus nicht vertrauenswürdigem Kontext?

Teamwissen, Buildbefehle und Sicherheitsgrenzen dürfen nicht nur im lokalen Memory existieren. Für langfristige Qualität ist die Trennung von versioniertem Repo-Wissen und persönlichem Gedächtnis wichtiger als die automatische Speicherung selbst.

Wann ist Progressive Disclosure zu riskant?

Ein Skill kann zu spät, falsch oder gar nicht ausgelöst werden. Typische Ursachen sind vage Beschreibungen, zu viele ähnliche Skills, verschachtelte Referenzen oder eine falsche Relevanzentscheidung des Modells. Kritische Prüfungen gehören deshalb nicht ausschließlich hinter einen optionalen Trigger. Verankere sie zusätzlich in CI, Hooks, Permissions oder einem verpflichtenden Workflow.

Was ist meine Empfehlung für die Praxis?

Migriere in drei Schichten:

1. Basiskontext bereinigen: Behalte Repozweck, exakte Befehle und nicht offensichtliche Gotchas. Entferne Dubletten, Widersprüche und Regeln, die nur offensichtliches Verhalten beschreiben.
2. Spezialwissen auslagern: Verschiebe lange, seltene Verfahren in klar benannte Skills. Lege Tool-Semantik in typisierte Schemas, persönliche Erkenntnisse in überprüfbares Memory und Zielbilder in hochwertige Referenzen.
3. Verifikation härten: Übersetze manuelle Checks in ausführbare Loops. Erzwinge Sicherheits- und Compliance-Grenzen mit Permissions, Hooks, Sandboxes, CI und Human Approval.

Die richtige Kennzahl ist nicht „Wie viele Zeilen habe ich gelöscht?“, sondern „Erfüllt das System dieselbe Aufgabe reproduzierbar, mit weniger Konflikten und ohne schwächere Kontrollen?“ Führe den Alt-vs.-Neu-Test durch, bevor Du eine teamweite Migration als Erfolg deklarierst.

FAQ: Häufig gestellte Fragen zu Context Engineering für Claude 5

Was ist Context Engineering bei Claude 5?

Context Engineering gestaltet alle Informationen und Schnittstellen, die Claude während einer Aufgabe sieht: Systemprompt, `CLAUDE.md`, Skills, Tools, Memory, Referenzen und Konversationshistorie. Ziel ist ein kleiner, relevanter und widerspruchsfreier Arbeitskontext.

Ist Prompt Engineering mit Claude 5 überflüssig?

Nein. Gute Aufgabenstellung und klare Erfolgskriterien bleiben nötig. Der Unterschied ist, dass nicht mehr jede Regel und jedes Spezialverfahren dauerhaft im Prompt stehen sollte.

Wie lang sollte eine CLAUDE.md sein?

Es gibt keine universelle Zeilen- oder Tokenzahl. Sie sollte so kurz wie möglich sein, aber Repozweck, exakte Befehle, verbindliche Konventionen und nicht offensichtliche Risiken vollständig enthalten.

Was gehört in CLAUDE.md, Skills und Memory?

Dauerhafte, teamweite Projektfakten gehören in `CLAUDE.md`. Lange, bedarfsgesteuerte Verfahren gehören in Skills. Persönliche Präferenzen und lokale Erkenntnisse gehören in überprüfbares Auto-Memory.

Was bedeutet Anthropics 80-Prozent-Claim genau?

Anthropic zufolge wurden für Opus 5 und Fable 5 mehr als 80 Prozent des Claude-Code-Systemprompts entfernt, ohne messbaren Verlust in den eigenen Coding-Evaluierungen. Der Claim ist nicht unabhängig reproduziert und nicht auf beliebige Modelle oder Domänen übertragbar.

Hilft ein Eine-Million-Token-Fenster gegen Context Rot?

Es verhindert frühes Überlaufen, garantiert aber keinen zuverlässigen Abruf jedes Details. Irrelevanter Kontext, ähnliche Distraktoren und die Position wichtiger Informationen können die Leistung weiterhin verschlechtern.

Wann sollte ich Claude ausdrücklich Regeln geben?

Wenn nicht offensichtliche Projektzwänge gelten oder ein gewünschtes Ergebnis nicht zuverlässig aus Code und Umgebung ableitbar ist. Sicherheitskritische Regeln sollten zusätzlich technisch erzwungen werden.

Wie schütze ich Claude Code vor Prompt Injection?

Behandle externe Inhalte als nicht vertrauenswürdige Daten, minimiere Toolrechte, validiere Ein- und Ausgaben und trenne sensible Aktionen durch Freigaben. Kontrolliere außerdem, welche Inhalte in dauerhaftes Memory geschrieben werden dürfen.

Kann ich dieselbe Context-Architektur für Opus, Sonnet und andere Agenten verwenden?

Nicht ungeprüft. Nutze gemeinsame Repo-Fakten als stabile Basis, lagere modellspezifische Guidance aus und evaluiere jede unterstützte Modellklasse separat.

Fazit

Anthropics 80-Prozent-Reduktion ist ein relevantes Signal, aber kein Löschbefehl für Deine `CLAUDE.md`. Meine Empfehlung: weniger Prompt-Mikromanagement, mehr klare Context-Architektur und ausführbare Verifikation. Gute Modelle dürfen weiche Qualitätsentscheidungen treffen; riskante Grenzen gehören weiterhin in das Harness.

Weiterführend passen Was ist ein AI Harness?, Claude Skills 2.0, Cognitive Debt bei KI-Coding und Headroom und Token-Kompression.

## Quellen

Quellenstand: 27. Juli 2026.

• Anthropic: The new rules of context engineering for Claude 5 generation models
• Claude Platform: Context windows
• Claude Code Docs: How Claude remembers your project
• Claude Code Docs: Extend Claude with skills
• Anthropic: Building verification loops in Claude Code with skills
• Claude Cookbook: Context engineering – memory, compaction, and tool clearing
• Chroma: Context Rot
• Liu et al.: Lost in the Middle
• OWASP GenAI: LLM01:2025 Prompt Injection