Neues Modell, alte Anwei­sungen

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, mit sechs Abschnitten und einer Checkliste am Ende. 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 (externe Seite, claude.dev) beginnt mit einer Beruhigung: Opus 5.5 komme mit der Art zurecht, wie man Claude ohnehin schon benutzt. Der technische Leitfaden (externe Seite, platform.claude.com) sagt dasselbe genauer: Bestehende Prompts für Claude Opus 5 sollten ohne Änderung gut funktionieren, und die Muster aus dem Leitfaden zu Opus 5 bleiben ein vernünftiger Ausgangspunkt.

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. Nach dem Leitfaden (externe Seite, platform.claude.com) steht derselbe Name einer Effort-Stufe nicht bei jedem Modell für denselben Denkaufwand; die mittlere Stufe von Opus 5.5 erreicht in Anthropics Messung die hohe von Opus 5. Wer seine alte Einstellung mitnimmt, bekommt längere Durchgänge und mehr Ausgabetoken, vor allem auf den beiden höchsten Stufen. 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.
• Über mehrere angebundene Anwendungen sucht es zu wenig. Opus 5.5 legt nach dem Leitfaden (externe Seite, platform.claude.com) schnell los, und bei lose beschriebenen Aufgaben hilft ein Satz im Systemprompt, der es vor dem Handeln in den Quellen suchen lässt, die zur Aufgabe gehören könnten, auch in solchen, die sie nicht nennt: ein Regelwerk in einem alten Mailverlauf, eine Vorgabe auf einem anderen Tabellenblatt. In Anthropics Messung lösten damit deutlich mehr Aufgaben richtig, bei etwas mehr Werkzeugaufrufen und Token. Weil dieser Satz das Modell auf das Gefundene hin handeln lässt, gehört kein unver­trau­ens­wür­diger Inhalt in die durchsuchten Datensätze.

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 Ände­rungs­vor­schlag, und sie ändert von sich aus keine Datei.

Gesucht wird in vier Gruppen. Die erste ist veralteter Prompttext in sechs Mustern. Vier davon sind 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. Dazu kommen Häufungen unbedingter Verbote, die der Audit nach ihrer Herkunft beurteilt, und feste Vorgaben zur Ausgabeform wie Wortgrenzen oder Zwischenmeldungen im Takt. Die zweite sind brüchige Skill- und Kon­fi­gu­ra­ti­ons­da­teien, die dritte Werk­zeug­be­schrei­bungen, die vierte die Konfiguration der Anfrage. Die Prüffrage der Anleitung (externe Seite, github.com) je Zeile lautet, ob das Modell das nicht ohnehin schon wüsste.

Ebenso ausführlich wie die Fundmuster ist eine Liste dessen, was stehen bleiben muss. Ihr erster Satz stellt klar, dass Kontext nie Ballast ist: Zielgruppe, Umgebung, Qualitätsmaßstab und die Gründe hinter einer Regel weiß nur, wer den Aufbau kennt. Und die Anleitung (externe Seite, github.com) schließt mit einem Vorbehalt gegen sich selbst: Eine Streichung ist eine Annahme und noch kein Ergebnis. Wer streicht, misst danach.

Zum Zeitpunkt des Laufs war die öffentliche Fassung älter als die ausgelieferte. Auf GitHub stammte der letzte Stand vom 01.09.2026 und nannte Opus 5.5 nirgends; die Fassung, die Claude Code 2.1.280 mitbringt, nannte es in zehn Zeilen, mit eigenen Zeilen zu abgeschaltetem Denken und zu Hilfsschritten beim Lesen von Bildern. Seit dem 29.09.2026 ist die öffentliche Anleitung nachgezogen, nennt Opus 5.5 in zehn Zeilen und wurde zuletzt am 09.10.2026 geändert. Ob sie der in Claude Code ausgelieferten Fassung heute gleicht, habe ich nicht verglichen; wer sie nachliest, prüft deshalb zuerst, welche Fassung sein Lauf benutzt.

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 69 Prompt-Dateien per Suchmuster erfasst und 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 Ände­rungs­vor­schlag, 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, Selbst­ver­bes­se­rung, 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.

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 Kon­troll­durch­gä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 (externe Seite, github.com) warnt davor, Länge zum Maß zu machen, denn Ballast und Länge sind bei ihr zweierlei. 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ä­ti­gungs­pflicht für jede Kon­fi­gu­ra­ti­ons­än­de­rung 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 Anleitung (externe Seite, github.com) führt solche Widersprüche zwischen Kon­fi­gu­ra­ti­ons­da­teien inzwischen als eigenen Befund in der zweiten Gruppe. Welche Datei neuer ist, entscheidet git blame, der Zeitstempel zählt dafür nicht. Lässt sich die Reihenfolge nicht klären oder ist die ältere Stelle ein Verbot oder eine Sicherheitsregel, meldet der Audit den Widerspruch und überlässt die Wahl dem Nutzer. Dasselbe gilt, wenn die neuere Stelle einen Befehl oder einen Netzabruf hinzufügt oder ein Verbot lockert. Genau das trifft hier zu: Die neuere Projektdatei lockerte „immer nach Abstimmung“ zu „selbstständig mit Meldung“, und die Wahl lag bei mir.

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 Kom­mu­ni­ka­ti­ons­regel neben dem alten Widerspruch, D die alte Kom­mu­ni­ka­ti­ons­regel 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.

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 Kom­mu­ni­ka­ti­ons­regel. 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:

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 Kom­mu­ni­ka­ti­ons­regel, 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 (externe Seite, github.com) führt genau das als Befund, Vorgeschichte in der Ver­gan­gen­heits­form mit Vorfallsnummern, PR-Nummern und fest genannten Modellnamen, 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. Einer davon vermerkte, an seiner Stelle habe bis zum 08.09.2026 die Regel gestanden, für jede nicht triviale Aufgabe ab drei Schritten in den Planmodus zu wechseln, und begann dann zu erklären, warum sie nie gegriffen hat.

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 Wie­der­ho­lungs­schleife 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 Pro­gram­mier­auf­gaben 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.

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 Selbst­prüf­for­mu­lie­rungen 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 die Sitzungen danach zeigen

Von vier benannten Proben brauchten zwei echte Arbeit statt eines Messaufbaus: wie viele Subagenten in den Sitzungen danach entstehen, und wie lang die Antworten dort werden. Gezählt sind die Sitzungen am Terminal mit Opus 5.5 und mindestens fünf Antworten, vom 01.09. bis zum 07.10.2026. Automatische Läufe ohne Terminal zählen nicht mit. Sie delegieren nie und kamen fast alle erst nach dem Audit dazu. Eine Sitzung, die über den Audit hinweg lief, zählt nur bis zu seinem Commit.

Delegiert wird danach etwas seltener, und die Antworten sind um ein Siebtel länger, obwohl die Effort-Stufe von xhigh auf high sank. Beides ist an echter Arbeit beobachtet. Die Aufgaben waren andere, und vorher liegen nur 14 Sitzungen vor. Woran die längeren Antworten liegen, zeigt diese Zählung nicht. Die erste Messung hat eine der Annahmen schon 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, acht 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, und zu jedem Punkt kurz den Grund. Ausführlich begründet und gemessen ist es 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 (externe Seite, github.com) endet mit dem Rat, ihn bei jedem neuen Modell erneut zu fahren, und das nächste Modell bringt eine eigene Zeile in der Tabelle mit.