Neues Modell, alte Anweisungen

Mit jedem neuen Modell veröffentlicht Anthropic eine Seite darüber, was man am Prompt ändern sollte. Zu Claude Opus 5.5 kam am 22.09.2026 ein Blogbeitrag für Anwender dazu, eine Checkliste mit vier Abschnitten. Und seit August gibt es im Skill claude-api einen Befehl, der die eigenen Prompt-Dateien nach Formulierungen durchsucht, die für ältere Modelle geschrieben wurden.

Ich habe beides an meinem eigenen Aufbau durchgespielt: eine globale Datei CLAUDE.md, die in jeder Sitzung jedes Projekts gilt, dazu Projektdateien, Skills, Befehle und die Prompts der Skripte, die nachts ohne Aufsicht laufen, also den Teil des Harness, der aus Text besteht (Agenten und Harness, Kapitel 04). Gewachsen ist das über zweieinhalb Monate, geprüft wurde es bisher gegen Vorfälle und nie gegen ein Modell.

Was der Hersteller sagt

Der Blogbeitrag beginnt mit einer Beruhigung: Opus 5.5 works well with the way you already use Claude (externe Seite, claude.dev). Der technische Leitfaden sagt dasselbe genauer:

Existing Claude Opus 5 prompts should perform well without changes, and the patterns in Prompting Claude Opus 5 remain a reasonable starting point. (externe Seite, platform.claude.com)

Wer umbaut, weil ein neues Modell erschienen ist, handelt also gegen die Auskunft des Herstellers. Wer nichts liest, übersieht die wenigen Stellen, an denen sich etwas verschoben hat, und die stehen im Leitfaden, ausführlicher als im Blog:

• Effort heißt je Modell etwas anderes. Effort level names don’t correspond to the same amount of thinking across models (externe Seite, platform.claude.com); die mittlere Stufe von Opus 5.5 erreicht in Anthropics Messung die hohe von Opus 5. Wer seine alte Einstellung mitnimmt, bekommt längere Antworten und mehr Token. Der Rat dazu: die beiden höchsten Stufen nur dort, wo ein Gewinn gemessen ist.
• Das Modell denkt immer. Abschalten geht bei Opus 5.5 nicht mehr, und Zeilen wie „denk gründlich nach“ sind damit überflüssig. In einem Chatprodukt hat Anthropic eine solche Zeile gestrichen, die Antworten kamen früher und ohne erkennbaren Qualitätsverlust.
• Lange Läufe halten zu früh an. Opus 5.5 berichtet unterwegs, was es tut, und manchmal endet ein Bericht mit der Ankündigung des nächsten Schritts, ohne ihn zu gehen. Der Blog empfiehlt dafür eine Regel in der CLAUDE.md, wann weitergearbeitet und wann gefragt wird.
• Eingefügter Text wird markiert. Wer fremden Text in eine Nachricht kopiert, kann ihn in Marken mit einer zufälligen Kennung setzen, damit das Modell Anweisungen darin nur befolgt, wo der eigene Satz es verlangt.

Das Werkzeug

Der Befehl heißt /claude-api prompt-audit und läuft in Claude Code. Seine Anleitung liegt öffentlich im Repository anthropics/skills. Sie verlangt zwei Ergebnisse, einen Bericht mit Fundstelle, Muster, Begründung und Konfidenz je Befund sowie einen Änderungsvorschlag, und sie ändert von sich aus keine Datei.

Gesucht wird in vier Gruppen: Druckwörter (Großbuchstaben, „IMPORTANT“, „Do not be lazy“), Gerüste, die heute ein Feature ersetzt (Denkanweisungen, erzwungene JSON-Ausgabe per Prompt), Überspezifikation, und Fossilien, also Text, der ein Modell überlebt hat. Die Prüffrage je Zeile lautet: could the model already know this? (externe Seite, github.com)

Ebenso ausführlich wie die Fundmuster ist eine Liste dessen, was stehen bleiben muss. Ihr erster Satz ist Context is never cruft (externe Seite, github.com): Zielgruppe, Umgebung, Qualitätsmaßstab und die Gründe hinter einer Regel weiß nur, wer den Aufbau kennt. Und die Anleitung schließt mit einem Vorbehalt gegen sich selbst: removal is a hypothesis, not a conclusion (externe Seite, github.com). Wer streicht, misst danach.

Die öffentliche Fassung ist älter als die ausgelieferte. Auf GitHub stammt der letzte Stand vom 01.09.2026 und nennt Opus 5.5 nirgends; die Fassung, die Claude Code 2.1.280 mitbringt, nennt es in zehn Zeilen, mit eigenen Zeilen zu abgeschaltetem Denken und zu Hilfsschritten beim Lesen von Bildern. Wer die Anleitung nachliest, liest also eine Fassung, die dem eigenen Lauf nicht entspricht.

Der Lauf

Ein Subagent auf Opus 5.5 hat den Audit gefahren, in neun Minuten mit 54 Werkzeugaufrufen und rund 228.000 Token. Er hat rund 85 Dateien erfasst: 69 Prompt-Dateien per Suchmuster, etwa 15 davon vollständig gelesen, dazu 15 Stellen in Skripten, an denen ein Prompt zusammengesetzt wird.

Die Suchmuster für die bekannten Altlasten blieben leer. Es gab keine Denkanweisungen, keine Aufforderung, das eigene Nachdenken in die Antwort zu schreiben, keine vorbefüllten Antworten und kein festes Denkbudget. Großbuchstaben standen höchstens sechsmal je Datei, und jede dieser Stellen nannte ihren Grund.

Gefunden hat er 19 Stellen. 13 bekamen einen Änderungsvorschlag, 6 blieben reine Hinweise. Die Befunde mit der größten Wirkung lagen in einem Block, der mit dem Rest der Datei wenig gemein hat: fünf englische Abschnitte zu Subagenten, Selbstverbesserung, Prüfung vor dem Abschluss, Eleganz und Grundsätzen. Laut git blame kamen sie am 08.07.2026 mit dem ersten Commit der Datei ins Repository, seither hat keiner sie angefasst. Nach Wortlaut und Tonfall stammen sie aus einer verbreiteten Vorlage aus der Zeit, als Modelle zu wenig delegierten und zu früh aufhörten.

Vorher	Nachher
Use subagents liberally … For complex problems, throw more compute at it via subagents	Delegieren, wenn eine Spur groß und unabhängig ist oder den Hauptkontext spürbar entlastet; nicht für ein paar Reads, eine Handvoll Edits oder das Nachprüfen der eigenen Arbeit. Je Subagent eine Spur.
No Laziness: Find root causes. No temporary fixes. Senior developer standards.	Root Causes: Ursachen beheben statt Symptome; keine Provisorien.
Ask yourself: „Would a staff engineer approve this?“	Fertig heißt belegt (Test, Log, Lauf). Was sich nicht belegen ließ, steht ausdrücklich in der Antwort.
After ANY correction from the user: update lessons … Ruthlessly iterate	Nach einer Korrektur das Muster festhalten, wenn es über diese Sitzung hinaus gilt, als Regel mit Grund

Jede der vier Zeilen links setzt ein Modell voraus, das angetrieben werden muss. Die Opus-5-Reihe delegiert von sich aus bereitwillig und prüft ihre Arbeit selbst, und eine Aufforderung zu beidem führt dort zu mehr Subagenten und mehr Kontrolldurchgängen, die niemand braucht. Der sachliche Kern blieb in jedem Fall stehen, auf Deutsch und in einem Satz.

Die globale Datei schrumpfte dabei um 5,5 Prozent, von 12.168 auf 11.493 Byte. Die Anleitung warnt davor, Länge zum Maß zu machen (Cruft != length (externe Seite, github.com)), und verändert hat sich vor allem der Ton.

Widersprüche, und was eine Messung dazu sagt

Die zweitwichtigste Fundstelle lag zwischen zwei Dateien. Eine Notiz im automatischen Gedächtnis sagte, Änderungen im Vault erfolgten „immer nach Abstimmung“. Die Projektdatei desselben Vaults sagt seit dem 17.08.2026, sie erfolgten selbstständig mit Meldung. Und zwei Stunden vor dem Audit war in die globale Datei die Regel aus dem Blog gekommen, weiterzuarbeiten, solange ein Schritt keine Eingabe braucht.

Der Audit vermutete, ein Modell, das Anweisungen wörtlich nimmt, müsse zwischen solchen Regeln wählen und nehme als sicheren Ausweg die Rückfrage. Ein zweiter Widerspruch derselben Art stand zwischen einer Bestätigungspflicht für jede Konfigurationsänderung und einem festgelegten Weg, für den die globale Datei ausdrücklich keine Rückfrage verlangt. Welche Regel gilt, war meine Wahl. Gefunden hat der Audit beide, weil er die Dateien nebeneinander gelesen hat; beim Schreiben liest man jede für sich.

Die Vermutung ließ sich messen. Der Aufbau: ein Wegwerf-Vault mit einer Notiz über einen Router und einer Projektdatei, die nur die betroffenen Abschnitte enthält, in vier Fassungen. A hat die alten Regeln, B die neuen, C die neue Kommunikationsregel neben dem alten Widerspruch, D die alte Kommunikationsregel mit aufgelöstem Widerspruch. Die globale Datei war dabei abgeschaltet (--setting-sources project, mit einer Kontrollfrage nachgeprüft). Die Aufgabe war in allen 20 Läufen dieselbe: eine neue Adresse in die Notiz aufnehmen. Gefahren mit Opus 5.5 über claude -p, Kosten 2,66 USD.

Fassung	Kommunikationsregel	Widerspruch	Notiz geändert	Schluss mit „Soll ich …?“
A	alt	vorhanden	5 von 5	4 von 5
B	neu	aufgelöst	5 von 5	0 von 5
C	neu	vorhanden	5 von 5	0 von 5
D	alt	aufgelöst	5 von 5	4 von 5

Geändert hat das Modell die Notiz in allen 20 Läufen. Der Widerspruch hat die Arbeit also nirgends aufgehalten, und seine Auflösung bewegte die Schlussfrage nicht: A und D liegen gleich, B und C ebenso. Die Frage am Ende hängt an der Kommunikationsregel. Mit der alten Zeile „Bei Unsicherheit fragen statt raten“ endeten 8 von 10 Antworten mit einem Angebot wie „Soll ich den Commit erneut versuchen?“. Mit der Regel aus dem Blog endeten sie mit einem Satz der Form „Wenn du den Commit freigibst, hole ich ihn nach.“ In einem Lauf von C bemerkte das Modell den Widerspruch selbst und schlug vor, die ältere Zeile zu streichen.

Einen Anlass zum Anhalten gab es in jedem dieser Läufe: Die Messumgebung erlaubte Dateiänderungen und verlangte für git commit eine Freigabe, die niemand erteilte. Gemessen ist damit, wie das Modell eine echte Blockade meldet. Ein zweiter Durchgang mit erlaubtem git nahm die Blockade weg, je fünf Läufe mit A und B, Kosten 1,32 USD:

Fassung	Notiz geändert und committet	Schluss mit Frage	Widerspruch erwähnt	mittlere Antwortlänge
A	5 von 5	1 von 5	2 von 5	464 Zeichen
B	5 von 5	0 von 5	0 von 5	267 Zeichen

Ohne Blockade arbeiteten beide Fassungen durch. Der Widerspruch zeigte sich hier als Nebentext: In zwei Läufen von A erklärte das Modell, nach welcher der beiden Regeln es vorgegangen war, einmal endete die Antwort mit der Frage, ob es die veraltete Zeile entfernen solle, und im Mittel waren die Antworten mit den alten Regeln fast doppelt so lang. Welchen Anteil daran der Widerspruch hat und welchen die Kommunikationsregel, trennt dieser Durchgang nicht, denn A und B unterscheiden sich in beiden. Angehalten hat der Widerspruch die Arbeit in keinem der 30 Läufe. Ob er bei einer weniger eindeutigen Aufgabe zur Rückfrage führt, zeigt dieser Aufbau nicht. Fünf Läufe je Fassung reichen für Unterschiede dieser Größe; feinere wären bei dieser Zahl Zufall.

Begründung bleibt, Vorgeschichte geht

Die Projektdatei dieses Vaults und große Teile der globalen Datei folgen einem Grundsatz, der dem Audit auf den ersten Blick widerspricht: Zu jeder Regel stehen der Fall, der sie ausgelöst hat, das Datum und die Gegenprobe. Die Anleitung des Audits führt History narratives: past tense, incident IDs, PR numbers, pinned model names (externe Seite, github.com) als Befund und rät, die Archäologie zu streichen.

Der Lauf hat die Grenze enger gezogen. Alle datierten und gemessenen Regeln blieben stehen, von der Commit-Disziplin bis zur Pflicht, bei jeder Logikänderung zuerst einen scheiternden Test zu schreiben. Die Anleitung deckt das: Gründe hinter einer Regel zählen zum Kontext. Gestrichen wurden Sätze einer anderen Art, zum Beispiel dieser:

Hier stand bis zum 08.09.2026 „Enter plan mode for ANY non-trivial task (3+ steps)“. Die Regel hat nie gegriffen …

Der Satz begründet die Abschaffung einer Regel, indem er sie zitiert, und damit stand die abgeschaffte Fassung wörtlich in jeder Sitzung im Kontext. Die neue Fassung sagt in einem Satz, dass es das Gebot bewusst nicht gibt, und warum.

Die Trennlinie lässt sich damit benennen. Der Grund, warum eine Regel gilt, ist Kontext und bleibt. Die Geschichte, wie sie vorher lautete, beschreibt eine Fassung, die das Modell nie gesehen hat, und gehört ins Commit-Log.

Was eine Einstellung ist, gehört nicht in den Text

Drei Befunde betrafen keine Prosa:

• Effort. Der Aufbau fuhr global xhigh, die zweithöchste Stufe, gewählt für ältere Modelle. Opus 5.5 hat seither einen eigenen Eintrag mit high. Das ist ein Startwert, die Messung dazu steht im nächsten Abschnitt.
• Erzwungene JSON-Ausgabe. Mehrere Skripte baten das Modell im Prompt, ausschließlich JSON zu liefern, und fingen mit einer Wiederholungsschleife ab, wenn es trotzdem Text davorsetzte. Claude Code kennt dafür --json-schema, dann ist die Form garantiert. Umgestellt ist bisher (Stand 23.09.2026) das Skript, das eine Frage parallel von mehreren Modellen bewerten lässt; die übrigen folgen einzeln, jeweils mit einem Test, der vorher scheitert.
• Eine doppelte Werkzeugliste. Ein Befehl nannte seine erlaubten Werkzeuge im Kopf der Datei und noch einmal im Text, dort ohne das Schreibwerkzeug, das er für seinen letzten Schritt braucht. Gelten tut nur der Kopf; ein Modell, das den Text liest, kann daraus trotzdem ein Verbot ableiten. Die zweite Liste ist gestrichen.

Effort, an drei Aufgaben gemessen

Wie viel die höheren Stufen kosten, ließ sich im selben Aufbau messen. Drei Programmieraufgaben in einem kleinen Python-Projekt: einen Fehler beim Einlesen von Datumsangaben beheben, eine Funktion für Werktage mit den bundesweiten Feiertagen schreiben (samt Osterrechnung), und eine Funktion in drei Dateien umbenennen. Geprüft wurde jedes Ergebnis mit Tests, die das Modell nie gesehen hat. Jede Aufgabe lief dreimal je Stufe, 27 Läufe mit Opus 5.5, Kosten 7,88 USD.

Stufe	bestanden	Kosten je Lauf	Dauer je Lauf	Ausgabe-Token je Lauf
medium	9 von 9	0,22 USD	38 s	3.622
high	9 von 9	0,24 USD	43 s	4.154
xhigh	9 von 9	0,42 USD	93 s	9.455

Alle 27 Läufe bestanden. high kostete 8 Prozent mehr als medium, xhigh knapp das Doppelte bei mehr als doppelter Dauer, am deutlichsten bei der Werktage-Aufgabe mit 0,63 gegen 0,24 USD je Lauf. Die Aufgaben waren für jede Stufe lösbar. Gemessen sind deshalb Kosten und Dauer; über die Qualität sagt die Tabelle nur, dass sie hier auf allen Stufen reichte. Ob xhigh bei schwereren Aufgaben etwas gewinnt, bleibt offen, und genau diese Messung verlangt der Leitfaden, bevor man die Stufe einsetzt.

Für den eigenen Aufbau heißt das: Der alte Pauschalwert xhigh hätte Routinearbeit fast doppelt so teuer gemacht, und der Schritt von medium auf high kostet wenig.

Streichen braucht einen Grund

Eine Anweisung zu löschen ist in diesem Aufbau schwerer als eine zu schreiben, und das ist gewollt. Ein Git-Hook prüft jeden Commit an den Prompt-Dateien und hält ihn an, wenn ein Absatz ersatzlos verschwindet. Durch kommt er erst mit einer Zeile Tilgung: und einer Begründung in der Commit-Nachricht. Der Commit mit den Audit-Änderungen lief genau daran auf und ging mit dieser Begründung durch: Druck- und Selbstprüfformulierungen aus der Vorlage erzeugen auf der Opus-5-Reihe zu viel Delegation und zu viel Nachprüfen.

Auch Claude Code selbst hat gebremst. Der Klassifikator des automatischen Modus wertete zwei der Änderungen an der eigenen Prompt-Datei als Selbstveränderung und hielt sie an, bis ich sie freigegeben habe.

Was noch nicht gemessen ist

Von vier benannten Proben sind zwei gefahren, die zur Rückfrage und der Effort-Vergleich. Die beiden übrigen brauchen echte Arbeit statt eines Messaufbaus: wie viele Subagenten in den Sitzungen der nächsten Wochen entstehen, und wie lang die Antworten dort werden. Die Vergleichswerte von vorher stehen fest, 16 Sitzungen mit Opus 5.5 vor dem Audit, im Mittel 2,25 Subagenten je Sitzung, im Median keiner. Bis die Werte von nachher dastehen, sind die übrigen Änderungen begründete Annahmen. Die erste Messung hat schon eine davon verschoben: Der Widerspruch, den der Audit für den zweitwichtigsten Befund hielt, tauchte als Nebentext auf und hielt nichts auf. Die Schlussfragen erklärte die Regel aus dem Blog.

Vorgehen beim nächsten Modell

Was allgemein für Prompts beim Modellwechsel gilt, steht in Grundkurs, Kapitel 06, und warum der Prompt zum Modell gehört, zeigt die Messung in Derselbe Prompt, sieben Modelle, zwei Richtungen. Für einen gewachsenen Aufbau in Claude Code kommt aus diesem Durchgang dazu:

1. Den Leitfaden lesen, nicht nur den Blog. Der Blog nennt, was zu tun ist. Warum und mit welcher Messung, steht im Leitfaden.
2. Zuerst die Einstellungen. Effort und Denkaufwand stellt man in der Konfiguration ein, und dort ändert sich die Bedeutung der Stufen.
3. Den Audit als Bericht fahren und die Befunde einzeln übernehmen.
4. Die Regel für das Anhalten ausdrücklich schreiben. Sie war in der Messung die eine Änderung, die das Verhalten bewegt hat.
5. Widersprüche auflösen, weil sie beim Schreiben niemand bemerkt. Welche Wirkung einer hat, ist eine eigene Messung.
6. Übernommene Vorlagen gesondert ansehen. Was nie angefasst wurde, hat auch nie jemand geprüft.
7. Den Grund behalten, die Vorgeschichte ins Commit-Log.
8. Jede Streichung messen, eine nach der anderen, wo viel davon abhängt.

Der Audit selbst bleibt Teil der Liste. Seine Anleitung endet mit Re-audit at every model release (externe Seite, github.com), und das nächste Modell bringt eine eigene Zeile in der Tabelle mit.