Denkprozess unsichtbar, Rechnung sichtbar
In Claude Code und der Anthropic-API häufen sich Fehlerberichte zu den sogenannten Denkblöcken. Damit sind die Zusammenfassungen gemeint, mit denen ein Modell offenlegt, wie es an eine Aufgabe herangegangen ist. Betroffen sind laut den Meldungen Claude Opus 4.8 und Sonnet 5. Statt einer Zusammenfassung kommt beim Client teilweise ein leeres Feld an.
Der Entwickler Michael Hood hat das Verhalten dokumentiert. Sinngemäß übersetzt schreibt er:
Seit dem 16.07.2026 gegen 15:00Z liefert die API leere Denkblöcke zurück, also thinking mit leerem Inhalt und nur der Signatur, für Claude Opus 4.8 und Sonnet 5. Und zwar auch dann, wenn display: 'summarized' explizit angefordert wird, selbst bei direkter Injektion in den Roh-Request-Body.
Vergleichbare Beobachtungen gibt es für die Claude-Code-Erweiterung in VS Code, wo Denkblöcke ebenfalls fehlen. Andere Berichte beschreiben abgeschnittene Zusammenfassungen: Ein Teil des Streams erreicht den Client gar nicht. Ein anonymer Bug-Report formuliert das sinngemäß so, dass der Denkprozess vollständig erzeugt und abgerechnet werde, während ein Teil des Zusammenfassungs-Streams stillschweigend verworfen wird.
Woran das liegt, ist offen. Ob die leeren Blöcke etwa auf interne Änderungen an der Anzeige von Zusammenfassungen zurückgehen, ist nicht bestätigt.
Was Anthropic zur Abrechnung sagt
Die Dokumentation von Anthropic lässt in diesem Punkt wenig Raum für Interpretation. Sinngemäß heißt es dort: Berechnet werden alle erzeugten Denk-Tokens, auch wenn sie eingeklappt oder geschwärzt sind. Und weiter: Die Tokens, die Claude für das Nachdenken aufwendet, gelten als Output-Tokens, selbst wenn der Denktext nicht zurückgeliefert wird, und sie zählen zusammen mit der eigentlichen Antwort gegen das Limit aus max_tokens.
Für Kunden ergibt sich daraus eine unbequeme Logik. Ob eine Zusammenfassung vollständig, gekürzt oder gar nicht ankommt, ändert an der Rechnung nichts, solange die Tokens erzeugt wurden.
| Situation | Abrechnung laut Dokumentation |
|---|---|
| Denkblock wird vollständig ausgeliefert | alle Denk-Tokens als Output-Tokens |
| Denkblock eingeklappt oder geschwärzt | alle Denk-Tokens als Output-Tokens |
| Denkblock kommt leer oder gekürzt an | Tokens laut Bug-Reports voll erzeugt und berechnet |
| Anrechnung auf max_tokens | zusammen mit dem Antworttext |
Ob Anthropic Tokens erstattet oder gutschreibt, die wegen dieser Fehler unvollständig oder leer ausgeliefert wurden, ist nicht bekannt. Das Unternehmen nennt dazu keine Details. Der offizielle Ratschlag zur Kostensenkung ist bislang schlicht: das Budget für die Denkfunktion reduzieren oder die Funktion abschalten.
Abgebrochene Streams als zweite Baustelle
Unabhängig davon bricht die API bei langen Denk-Sitzungen offenbar Datenströme ab. Dazu liegen mindestens sieben verwandte Fehlerberichte vor. Wann die Anpassungen am Netzwerkverhalten abgeschlossen sind, ist nicht bekannt.
Ein Anthropic-Sprecher verweist auf den Entwicklungsrhythmus. Sinngemäß: Claude Code liefere fast täglich Updates aus, und Rückmeldungen aus der Community wie diese GitHub-Issues seien ein wichtiger Weg, Probleme schnell zu erkennen. Man sei den Entwicklern dankbar und werde Fehler weiter beheben, sobald sie auftreten.
Nebenbei zeigt der Fall, wie schnell sich diese Funktionen bewegen. Die Betriebsart "Extended Thinking", also besonders langes Nachdenken vor der Antwort, gilt inzwischen als veraltet. Wer Prozesse darauf aufgebaut hat, plant ohnehin schon um. Auch beim Auto-Modus in Claude Code hat Anthropik das Standardverhalten kürzlich verändert.
Warum das mehr als ein Anzeigefehler ist
Denkblöcke sind nicht bloß Dekoration. Sie sind das einzige Fenster in die Arbeitsweise des Modells, das Kunden bei einem geschlossenen Anbieter überhaupt haben. Fehlt dieses Fenster, bleibt eine Rechnung über Rechenleistung, deren Ergebnis niemand nachvollziehen kann. In regulierten Umgebungen im DACH-Raum, in denen Nachvollziehbarkeit von KI-Entscheidungen dokumentiert werden muss, ist das mehr als ein Komfortproblem.
Dazu kommt die Kostenseite. Reasoning-Tokens sind der teuerste Teil vieler Anfragen, weil sie als Output abgerechnet werden. Wer nicht weiß, wie viele Tokens für unsichtbare Zwischenschritte verbrannt werden, kann sein Budget nur schätzen. Dass Token-Kosten inzwischen einen erheblichen Teil des Entwicklungsbudgets ausmachen, ist kein Einzelfall mehr.
Genau hier liegt die strukturelle Schwäche von Pay-per-Token-Modellen: Das finanzielle Risiko für Übertragungs- und Darstellungsfehler auf Anbieterseite trägt der Kunde. Bei selbst betriebenen Modellen fällt diese Abrechnungslogik für unsichtbare Zwischenergebnisse weg, weil die Rechenleistung ohnehin bezahlt ist und Denkprozesse im eigenen Log landen. Dass eigene Coding-Agenten allein nicht reichen und die Abhängigkeit oft beim Modellanbieter bleibt, gehört zur gleichen Rechnung. Wer Kosten und Transparenz ernsthaft kontrollieren will, kommt an offenen Gewichten oder mindestens an einem eigenen Gateway mit hartem Token-Limit kaum vorbei.