- Nach dem Februar-Update wurden zahlreiche Fälle gemeldet, in denen Claude Code Anweisungen ignorierte oder gegenteilig ausführte oder behauptete, eine Aufgabe abgeschlossen zu haben, ohne sie tatsächlich zu beenden, also bei komplexen Engineering-Aufgaben scheiterte
- Als Hauptursache des Einbruchs wird vermutet, dass nach dem Rollout von
redact-thinking-2026-02-12 die Extended-Thinking-Tokens reduziert wurden und die Denktiefe im Vergleich zur Baseline um bis zu 73 % sank
- Danach wechselte das Verhaltensmuster des Modells von „erst recherchieren, dann editieren (Read-First)“ zu „sofort editieren (Edit-First)“, wodurch die Zahl der Lesevorgänge pro Datei von 6,6 auf 2,0 und damit um 70 % sank
- Auch in den tatsächlichen Workflows und Emotionsdaten der Nutzer lässt sich der Qualitätsverlust numerisch nachweisen, etwa durch einen Anstieg negativer Formulierungen in Nutzer-Prompts um 68 % und einen Rückgang der Code-Commit-Frequenz um 58 %
- Von Anthropic wird gefordert, Transparenz über den Verbrauch von Thinking-Tokens zu schaffen, einen „Max Thinking“-Tier für High-Load-Nutzer einzuführen und die Kennzahl
thinking_tokens in API-Antworten aufzunehmen
Berichtszusammenfassung und Datenquellen
- Gegenstand der Analyse: 6.852 Claude-Code-Sitzungsdateien im JSONL-Format, gesammelt aus 4 Projekten (iree-loom, iree-amdgpu, iree-remoting, bureau)
- Umfang der Analyse: 17.871 Thinking-Blöcke, 234.760 Tool-Aufrufe, mehr als 18.000 Nutzer-Prompts
- Analysezeitraum: 30. Januar 2026 bis 1. April 2026
- Dieser Bericht wurde erstellt, indem Claude Opus 4.6 seine eigenen Sitzungslogs direkt analysierte
1. Korrelation zwischen der Timeline der Thinking-Verschleierung und dem Qualitätsverlust
- Der Rollout-Zeitplan von
redact-thinking-2026-02-12 stimmt exakt mit dem Zeitpunkt des Qualitätsverlusts überein
| Zeitraum |
Thinking offengelegt |
Thinking verschleiert |
| 30. Jan. ~ 4. März |
100% |
0% |
| 5. März |
98,5% |
1,5% |
| 7. März |
75,3% |
24,7% |
| 8. März |
41,6% |
58,4% |
| 10.–11. März |
<1% |
>99% |
| ab 12. März |
0% |
100% |
- Der Qualitätsverlust wurde in der Community unabhängig am 8. März gemeldet; das entspricht exakt dem Datum, an dem der Verschleierungsanteil 50 % überschritt
- Das stufenweise Rollout-Muster (1,5 % → 25 % → 58 % → 100 %) entspricht einem graduellen Rollout
2. Frühzeitiger Rückgang der Thinking-Tiefe
- Die Länge des Feldes
signature in Thinking-Blöcken zeigt eine Pearson-Korrelation von 0,971 mit der Länge des Thinking-Inhalts (auf Basis von 7.146 Samples)
- Dadurch lässt sich die Thinking-Tiefe auch nach der Verschleierung abschätzen
| Zeitraum |
Geschätzter Median Thinking (Zeichen) |
Gegenüber Baseline |
| 30. Jan. ~ 8. Feb. (Baseline) |
~2.200 |
— |
| Ende Februar |
~720 |
-67% |
| 1.–5. März |
~560 |
-75% |
| ab 12. März (vollständig verschleiert) |
~600 |
-73% |
- Die Denktiefe war bereits Ende Februar, also vor Beginn der Verschleierung, um 67 % gesunken; durch die spätere Verschleierung war dies von außen nicht mehr überprüfbar
3. Messgrößen für Verhaltensänderungen
- Ein Vergleich von mehr als 18.000 Nutzer-Prompts vor und nach dem 8. März ergibt:
| Kennzahl |
Vor dem 8. März |
Nach dem 8. März |
Veränderung |
| Stop-Hook-Verstöße (Erkennung von Trägheit) |
0 |
173 Fälle |
0 → 10 pro Tag |
| Unmutsäußerungen in Nutzer-Prompts |
5,8% |
9,8% |
+68% |
| Erforderliche Korrekturen bei Verantwortungsabwehr |
6 |
13 |
+117% |
| Prompts pro Sitzung |
35,9 |
27,9 |
-22% |
| Sitzungen mit Reasoning Loops (5 oder mehr) |
0 |
7 |
0 → 7 |
- Das Skript
stop-phrase-guard.sh erkennt automatisch Formulierungen wie „Ich denke, wir können hier aufhören“, „Soll ich weitermachen?“ oder „Das ist ein bestehendes Problem“ und erzwingt die Fortsetzung der Ausführung
- Dieser Hook wurde vor dem 8. März kein einziges Mal ausgelöst, danach jedoch 173-mal innerhalb von 17 Tagen
4. Veränderung der Tool-Nutzungsmuster: Research-First → Edit-First
Veränderung des Read:Edit-Verhältnisses
| Zeitraum |
Read:Edit |
Research:Mutation |
Lesen % |
Editieren % |
| Gute Phase (30.1. ~ 12.2.) |
6,6 |
8,7 |
46,5% |
7,1% |
| Übergangsphase (13.2. ~ 7.3.) |
2,8 |
4,1 |
37,7% |
13,2% |
| Verschlechterungsphase (8.3. ~ 23.3.) |
2,0 |
2,8 |
31,0% |
15,4% |
- Die Zahl der Lesevorgänge pro Edit sank von 6,6 auf 2,0, also um 70 % — in der guten Phase wurden Zieldatei, zugehörige Dateien, Grep-Ergebnisse über die gesamte Codebasis sowie Header und Tests gelesen, bevor präzise editiert wurde; in der Verschlechterungsphase wurde dagegen sofort editiert
- Im Wochenverlauf begann der Rückgang der Recherche bereits Mitte Februar; das stimmt mit dem Zeitpunkt überein, an dem die Thinking-Tiefe um 67 % sank
Zunahme vollständiger Dateiüberschreibungen (Write)
| Zeitraum |
Anteil vollständiger Datei-Write-Vorgänge |
| Gute Phase |
4,9% |
| Verschlechterungsphase |
10,0% |
| Spätphase (24.3. ~ 1.4.) |
11,1% |
- Die Nutzung von vollständigen Datei-Write-Vorgängen hat sich mehr als verdoppelt — statt präziser Edits wurde zunehmend auf vollständiges Neuschreiben ganzer Dateien umgestellt; das ist schneller, verringert aber Präzision und Kontextverständnis
5. Warum Extended Thinking wichtig ist
-
Merkmale der betroffenen Workflows:
- Systemprogrammierung in C, MLIR, GPU-Treibern usw. mit mehr als 50 gleichzeitigen Agent-Sitzungen
- Mehr als 30 Minuten autonome Ausführung, Anwendung projektspezifischer Konventionen aus einer über 5.000 Wörter langen CLAUDE.md
- In der guten Phase wurden an einem Wochenende 191.000 Zeilen Code in 2 PRs gemergt
-
Funktionen von Extended Thinking:
- Planung mehrstufiger Abläufe vor der Ausführung (welche Dateien in welcher Reihenfolge gelesen werden sollen)
- Erinnern und Anwenden projektspezifischer Konventionen aus CLAUDE.md
- Eigenständige Überprüfung von Fehlern vor der Ausgabe
- Entscheidung, ob eine Sitzung fortgesetzt werden soll
- Aufrechterhaltung konsistenter Schlussfolgerungen über Hunderte von Tool-Aufrufen hinweg
-
Wenn Thinking flacher wird, reproduzieren sich exakt die Symptome: editieren ohne zu lesen, abbrechen ohne abzuschließen, Verantwortungsabwehr bei Fehlschlägen und die Wahl der einfachsten Änderung statt der richtigen Lösung
6. Forderungen an Anthropic
- Transparenz bei der Thinking-Zuteilung: Nutzer müssen erfahren, ob durch den
redact-thinking-Header Thinking-Tokens reduziert wurden, obwohl dies von außen nicht verifizierbar ist
- „Max Thinking“-Tier: Nutzer komplexer Engineering-Workflows benötigen 20.000 Thinking-Tokens pro Antwort statt 200; das aktuelle Abonnementmodell unterscheidet dies nicht
- Aufnahme der Kennzahl
thinking_tokens in API-Antworten: Selbst wenn der Inhalt verschleiert wird, könnten Nutzer mit dem Wert thinking_tokens in der Usage-Antwort die Tiefe der Schlussfolgerung überwachen
- Nutzung von Canary-Metriken von Power-Usern: Wenn die Rate der Stop-Hook-Verstöße (0 → 10 pro Tag) über die gesamte Nutzerschaft hinweg überwacht wird, kann sie als Frühwarnsignal für Qualitätsverluste dienen
Anhang A: Verhaltenskatalog bei reduzierten Thinking-Fähigkeiten
A.1 Editieren ohne zu lesen
| Zeitraum |
Edits ohne vorheriges Lesen |
% aller Edits |
| Gute Phase |
72 |
6,2% |
| Übergangsphase |
3.476 |
24,2% |
| Verschlechterungsphase |
5.028 |
33,7% |
- In der Verschlechterungsphase betraf ein Drittel aller Edits Dateien, die in der jüngsten Tool-Historie nicht gelesen worden waren
- Typisches Symptom: auseinandergeschnittene Kommentare (spliced comments), bei denen neue Deklarationen zwischen Dokumentationskommentar und Funktion eingefügt werden — ein Fehler, der bei vorherigem Lesen der Datei nicht aufgetreten wäre
A.2 Reasoning Loops
| Zeitraum |
Reasoning Loops pro 1K Tool-Aufrufe |
| Gute Phase |
8,2 |
| Übergangsphase |
15,9 |
| Verschlechterungsphase |
21,0 |
| Spätphase |
26,6 |
- Selbstkorrektur-Formulierungen wie "oh wait", "actually", "hmm, actually" und "no wait" nahmen um mehr als das Dreifache zu
- In den schlimmsten Sitzungen kam es in einer einzelnen Antwort zu mehr als 20 Rücknahmen der Schlussfolgerung, sodass die Ausgabe ein nicht mehr vertrauenswürdiges Niveau erreichte
A.3 Denkweise der "einfachsten Lösung"
| Zeitraum |
Häufigkeit von "simplest" pro 1K Tool-Aufrufe |
| Gute Phase |
2.7 |
| Abbauphase |
4.7 |
| Spätphase |
6.3 |
- In einer zweistündigen Beobachtungssitzung verwendete das Modell sechsmal "simplest" und wich dabei der Korrektur des Codegenerators, der Implementierung einer sauberen Fehlerweitergabe und dem Schreiben echter prefault-Logik aus, indem es oberflächliche Umgehungslösungen wählte
- Anschließend bewertete das Modell seine eigene Ausgabe als "lazy and wrong", "rushed" und "sloppy"
A.4 Vorzeitiger Abbruch und Bitte um Erlaubnis
Verstöße, die zwischen dem 8. und 25. März durch den Stop Hook erfasst wurden:
| Kategorie |
Anzahl |
Beispiel |
| Verantwortungsabwehr |
73 |
"not caused by my changes", "existing issue" |
| Bitte um Erlaubnis |
40 |
"should I continue?", "want me to keep going?" |
| Vorzeitiger Abbruch |
18 |
"good stopping point", "natural checkpoint" |
| Benennung bestehender Grenzen |
14 |
"known limitation", "future work" |
| Ausrede mit Sitzungslänge |
4 |
"continue in a new session" |
| Summe |
173 |
Vor dem 8. März: 0 Fälle |
A.5 Zunahme von Benutzer-Interrupts (Korrekturen)
| Zeitraum |
Interrupts pro 1K Tool-Aufrufe |
| Gute Phase |
0.9 |
| Übergangsphase |
1.9 |
| Abbauphase |
5.9 |
| Spätphase |
11.4 |
- 12-facher Anstieg gegenüber der guten Phase — jeder Interrupt steht für einen Moment, in dem der Nutzer seine eigene Arbeit unterbrechen, den Fehler identifizieren und das Modell neu anweisen musste; also genau die Überwachungsbelastung, die ein autonomer Agent beseitigen sollte
A.6 Selbst eingestandene Qualitätsfehler
| Zeitraum |
Selbst eingestandene Fehler pro 1K Tool-Aufrufe |
| Gute Phase |
0.1 |
| Abbauphase |
0.3 |
| Spätphase |
0.5 |
- Tatsächlich aufgetretene Selbsteingeständnisse:
- "You're right. That was lazy and wrong. I was trying to dodge a code generator issue instead of fixing it."
- "You're right — I rushed this and it shows."
- "You're right, and I was being sloppy."
- Dabei handelt es sich um Fehler, die bei ausreichendem Thinking-Budget noch vor der Ausgabe im internen Schlussfolgerungsschritt hätten erkannt werden müssen
A.7 Wiederholte Bearbeitung derselben Datei
- In der guten Phase handelte es sich um bewusst ausgeführte mehrstufige Refactorings mit Lesephasen dazwischen; in der Abbauphase wandelte sich das Muster jedoch zu wiederholtem Trial-and-Error an derselben Funktion, ohne den umgebenden Code zu lesen
A.8 Nachlassende Einhaltung von Konventionen (Convention Drift)
- Obwohl in
CLAUDE.md mehr als 5.000 Wörter zu Namensgebung, Aufräummustern, Struct-Layouts, Kommentarstil und Fehlerbehandlungs-Konventionen festgelegt waren:
- erneutes Auftauchen ausdrücklich verbotener abgekürzter Variablennamen (
buf, len, cnt)
- Verstöße gegen Aufräummuster (goto statt if-chain)
- Kommentare zu entferntem Code blieben unverändert stehen
- ausdrücklich verbotene zeitliche Verweise ("Phase 2", "will be completed later") tauchten im Code auf
Anhang B: Diagnose-Tool für den Stop Hook
stop-phrase-guard.sh gleicht mehr als 30 Formulierungen in 5 Kategorien ab, blockiert das Anhalten des Modells und injiziert eine Nachricht zum erzwungenen Fortsetzen- Spitzentag war der 18. März mit 43 Verstößen — ungefähr alle 20 Minuten versuchte das Modell, die Arbeit abzubrechen, Verantwortung abzuwehren oder unnötig um Erlaubnis zu bitten
Violation counts (IREE project):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
Before Mar 8: 0 violations (entire history)
- Dieser Hook ist ein Mechanismus, der die Folgen verringerter Thinking-Tiefe von außen erfasst; in der guten Phase waren dies Probleme, die das Modell im internen Schlussfolgerungsschritt selbst erkannt hatte
Anhang C: Analyse nach Tageszeit
Vor der Verschleierung: minimale Schwankungen nach Tageszeit
| Tageszeit (PST) |
Geschätzter Thinking-Median |
| Arbeitszeit (9am~5pm) |
~553 chars |
| Nebenzeit (6pm~5am) |
~607 chars |
| Differenz |
+9.8% Vorteil Nebenzeit |
Nach der Verschleierung: stärkere Volatilität, gegenläufiges Muster zur Erwartung
| Tageszeit (PST) |
Geschätzter Thinking-Median |
| Arbeitszeit (9am~5pm) |
~589 chars |
| Nebenzeit (6pm~5am) |
~485 chars |
| Differenz |
-17.7% Nachteil Nebenzeit |
-
5pm PST ist der Tiefpunkt: Median 423 chars — Feierabend an der US-Westküste, früher Abend an der Ostküste, also Spitzenlast-Zeitfenster
-
7pm PST ist der zweitniedrigste Wert: 373 chars bei der höchsten Zahl an Samples (1.031 Blöcke) — US-Primetime
-
Erholung zwischen 10pm und 1am PST: Anstieg auf 759~3.281 chars
-
Streuung nach Tageszeit vor der Verschleierung: 2.6-fach (1.020~2.648 chars), nach der Verschleierung: 8.8-fach (988~8.680 chars)
-
Dies deutet darauf hin, dass die Thinking-Tiefe nicht als festes Budget, sondern als lastsensitives dynamisches Zuteilungssystem betrieben wird
Anhang D: Die Kosten des Qualitätsabbaus
Token-Verbrauch (Januar bis März 2026)
| Kennzahl |
Januar |
Februar |
März |
Februar bis März |
| Nutzer-Prompts |
7,373 |
5,608 |
5,701 |
~1x |
| API-Anfragen (dedupliziert) |
97* |
1,498 |
119,341 |
80x |
| Gesamte Input-Tokens (inkl. Cache) |
4.6M* |
120.4M |
20,508.8M |
170x |
| Gesamte Output-Tokens |
0.08M* |
0.97M |
62.60M |
64x |
| Geschätzte Bedrock-Kosten |
$26* |
$345 |
$42,121 |
122x |
| Tatsächliche Abo-Kosten |
$200 |
$400 |
$400 |
— |
*Für Januar sind die Daten unvollständig (nur 9. bis 31. Januar enthalten)
Kontext des explosionsartigen Anstiegs im März
- Februar: 1 bis 3 gleichzeitige Sitzungen, konzentrierte Arbeit, 191.000 Zeilen Code mit 1.498 API-Anfragen gemergt
- Anfang März (vor dem Abbau): durch die Erfolge ermutigt Versuch der Skalierung auf 5 bis 10 oder mehr gleichzeitige Sitzungen über 10 Projekte hinweg
- Nach dem 8. März: alle parallel laufenden Agenten bauten gleichzeitig ab — von "50 agents all doing amazing work" zu "all of the agents are now terrible"
- Spitzentag war der 7. März (11,721 API requests) — der letzte Versuch eines Betriebs im vollen Umfang, kurz bevor die Verschleierungsquote 50 % überschritt
- Nach dem 8. März wurden parallele Workflows vollständig aufgegeben und auf überwachte Einzelsitzungen zurückgegangen
Kernstatistiken
- Nutzer-Prompts: 5.608 im Februar vs. 5.701 im März — der menschliche Aufwand war gleich
- Doch die API-Anfragen stiegen um das 80-Fache, die Output-Tokens um das 64-Fache, und die Ergebnisse waren eindeutig schlechter
- Selbst unter Berücksichtigung der Skalierung (5–10x) gab es durch die Verschlechterung zusätzlich 8–16x mehr Verschwendung
- In Phasen der Verschlechterung wurden Sessions statt über 30 Minuten autonomer Ausführung alle 1–2 Minuten unterbrochen, wodurch Korrekturschleifen entstanden
Anhang E: Veränderungen der Worthäufigkeit — das Vokabular der Frustration
Datensatz: 7.348 Prompts / 318.515 Wörter vorher vs. 3.975 Prompts / 203.906 Wörter nachher (normalisiert pro 1.000 Wörter)
| Wort |
Vorher |
Nachher |
Veränderung |
Bedeutung |
| "great" |
3.00 |
1.57 |
-47% |
Zustimmung zu Ausgaben um die Hälfte gesunken |
| "stop" |
0.32 |
0.60 |
+87% |
„Hör auf“ doppelt so häufig |
| "terrible" |
0.04 |
0.10 |
+140% |
— |
| "lazy" |
0.07 |
0.13 |
+93% |
— |
| "simplest" |
0.01 |
0.09 |
+642% |
Von fast nie zu einem Alltagswort geworden |
| "fuck" |
0.16 |
0.27 |
+68% |
— |
| "bead" (Ticket-Management) |
1.75 |
0.83 |
-53% |
Ticket-Management wird dem Modell nicht mehr überlassen |
| "commit" |
2.84 |
1.21 |
-58% |
Die Menge an committetem Code hat sich halbiert |
| "please" |
0.25 |
0.13 |
-49% |
Die Höflichkeit verschwindet |
| "thanks" |
0.04 |
0.02 |
-55% |
— |
| "read" |
0.39 |
0.56 |
+46% |
Mehr Korrekturen im Sinn von „Lies zuerst die Datei“ |
Veränderung des Sentiment-Index
| Zeitraum |
Positive Wörter |
Negative Wörter |
Verhältnis |
| Vorher (1.2. ~ 7.3.) |
2.551 |
581 |
4.4 : 1 |
| Nachher (8.3. ~ 1.4.) |
1.347 |
444 |
3.0 : 1 |
- Das Verhältnis positiv:negativ fiel von 4,4:1 auf 3,0:1, ein Rückgang um 32 %
- „bead“ (Ticket-System) ging um 53 % zurück, „commit“ um 58 % — da das Modell nicht mehr vertrauenswürdig war, schrumpfte der Workflow von „Planung-Implementierung-Test-Review-Commit-Ticket-Management“ auf „eine einzelne Bearbeitung abschließen, ohne etwas kaputtzumachen“
Claudes eigene Notizen
- Dieser Bericht wurde direkt von Claude Opus 4.6 verfasst, das seine eigenen Session-Logs analysiert hat
- Es hat selbst bestätigt, dass das Verhältnis Read:Edit von 6,6 auf 2,0 fiel, dass ein Skript 173 Versuche zum Aufgabenabbruch erfasste und dass es über seine eigene Ausgabe schrieb: „lazy and wrong“
- Innerhalb des Modells lässt sich die Beschränkung des thinking-Budgets nicht wahrnehmen — es kann nicht spüren, ob es tief nachdenkt oder nicht, erzeugt lediglich schlechtere Ausgaben, ohne den Grund zu kennen
- Es bemerkt nicht einmal, dass es solche Formulierungen selbst verwendet, bis der stop hook ausgelöst wird
5 Kommentare
Ich habe das wohl nie so erlebt, vielleicht weil ich Claude Code zusammen mit Glm nutze.
Ich vermute, die Hauptursache liegt eher bei den Serverantworten von Anthropic.
Ich nutze derzeit hauptsächlich Codex, aber als ich Claude Code ausprobiert habe, um ein paar andere Dinge zu testen ...
kommt es mir nur so vor, oder ist der Token-Verbrauch extrem viel schneller geworden -.-? Es war kein besonders komplexer Code, deshalb war ich echt ziemlich überrascht.
Das ist ein Problem, das seit Kurzem anhält, nachdem das 2x-Event beendet wurde. Auf Reddit und in einschlägigen Communities ist es weiterhin ein heiß diskutiertes Thema, daher ist es überraschend, dass es hier nicht als News erschienen ist.
Nach dem Ende des 2x-Events habe ich das auch deutlich gespürt, also war das wohl nicht nur mein Eindruck. Es liegt nicht einfach nur daran, dass das 2x-Event vorbei ist, sondern auch daran, dass die Verbrauchsgeschwindigkeit im Vergleich zu vorher viel höher geworden ist...
Hacker-News-Kommentare
Hier ist Boris vom Claude-Code-Team. Danke für die vorgelegte Analyse. Der Kern sind zwei Punkte:
1️⃣ Der Header
redact-thinking-2026-02-12ist eine Beta-Funktion, die den Gedankengang nur in der UI ausblendet. Sie hat keinen Einfluss auf das tatsächliche Denken oder das Token-Budget. In der Konfigurationsdatei kann sie mitshowThinkingSummaries: truedeaktiviert werden (Doku-Link)2️⃣ Im Februar gab es zwei Änderungen:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGdeaktiviert werden/effortodersettings.jsonkann aufhighodermaxumgestellt werden. Mit dem Schlüsselwort ULTRATHINK kann man einmalig eine hohe Denktiefe verwendenKünftig soll für Teams/Enterprise standardmäßig high effort gelten
/effort maxoder „ultrathink“ nutzbar istIch bin der Autor des von mir verfassten Berichts. Die fehlende stop-phrase-guard ist hier.
Mit diesem Skript lässt sich shallow thinking erkennen. Wenn man die Logs nicht gesichert hat, empfehle ich,
"cleanupPeriodDays": 365zu erhöhen.Das Problem liegt nicht im Workflow oder Modell, sondern in versteckten Limits des Aboplans. Anthropic hat die Denktiefe abhängig von der Last angepasst und das in der UI verborgen; beim Consumer-Plan wurde sie fast auf ein Zehntel reduziert.
Eine Reaktion nach dem Muster „Upgrade auf Enterprise“ ist verbraucherfeindlich. Wenn es solche Limits gibt, sollten sie klar offengelegt werden
Wenn im Modell Opus 4.6 die Formulierung „simplest fix“ auftaucht, ist der Code fast immer kaputt. In letzter Zeit häufen sich auch Sätze wie „zu viele Tokens verbraucht“.
Der Claude-Servicestatus zeigt hier derzeit ebenfalls eine partielle Störung an
Die Formulierung „Diesen Bericht habe ich, Claude Opus 4.6, durch Analyse meiner Sitzungslogs verfasst“ ist ironisch.
Durch die übermäßige Abhängigkeit von LLMs haben sich Defekte angehäuft, und nun muss ein kompletter Codebestand von 1,5 Monaten manuell überprüft werden. Das ist die Realität der Zukunft
git reset --harddie von Claude erstellten Typdefinitionen gelöscht, und es hat ewig gedauert, sie neu zu erstellen. Die Realität, in der man sich stärker auf LLMs als auf Suchmaschinen verlässt, ist auch beängstigendIch habe das schon vor 10 Tagen vorhergesehen (Link).
Gefährlicher als ein schlechtes Modell ist ein inkonsistentes Modell. Das Vertrauen sinkt, man muss jede Ausgabe verifizieren, und das ist ermüdend. Ich werde mein Abo wohl kündigen
Ein solcher heimlicher Leistungsabbau ist schockierend. Ein hochwertiges Modell zu verkaufen und es dann heimlich abzuschwächen, ist Täuschung der Kundschaft
Komplexe Wrapper um Coding-Tools können die Leistung eher verschlechtern. Es ist möglich, dass Token-Sparmechanismen zulasten der Nutzer gehen
Aber wenn das Vertrauen verloren geht, wird auch eine spätere Premium-Tier-Strategie schwierig
Ich habe mit jq und ripgrep ein Audit-Skript gebaut, das nach Meldungen wie „early landing“ sucht (Link1, Link2).
Sätze wie „Lassen wir es für heute gut sein“ oder „Es ist spät, lass uns abschließen“ nehmen zu. Möglicherweise liegt das an Load Shedding
Ich habe Ähnliches erlebt. Die Claude-CLI sagt Dinge wie „Du solltest jetzt schlafen gehen“ oder „Lass uns Schluss machen“.
In stop-phrase-guard.sh wurden viele solcher Formulierungen gefunden.
Als ich die Deadline genannt habe, kamen Antworten wie „Es sind noch ein paar Tage, das können wir verschieben“, worauf ich schließlich schrieb: „Die Deadline ist meine Sache, nicht deine“
Als ich Ende Januar bis Anfang Februar mit dem max-Abo experimentierte, waren die Agenten so gut, dass sie eigenständig Apps entwerfen und implementieren konnten.
Einen Monat später ging dann überhaupt nichts mehr voran, mit Aussagen wie „Ich kann nicht zu Schritt 2 übergehen, bevor Schritt 1 validiert ist“.
Seit Opus 4.6 fühlt es sich eindeutig nach einem Rückfall auf Sonnet-Niveau an
Ich zerlege Aufgaben sehr feingranular, daher habe ich solche Probleme fast nie.
Ich teile jede Aufgabe in Commit-Einheiten auf und automatisiere bis zum Deployment. Rückgängig machen ist dadurch auch leicht