Claude AI Anleitung: Tipps und Best Practices

Die Arbeit mit Claude bleibt stehen, Sie suchen genau die Meldung, die erschienen ist, und die Suche gibt fast nichts zurück. The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH und Connection to Claude's response was lost. Claude may still be working sind fünf Beispiele dafür. Ihnen ist gemeinsam, dass sie beim Arbeiten mit Claude erscheinen und sich in Claudes eigenem Material dennoch (scheinbar) nicht finden lassen, und der Grund ist einfach: Das Programm, das die Meldung auf Ihrem Bildschirm geschrieben hat, ist nicht zwangsläufig das, für das Sie es halten. Dieser Artikel erklärt nicht jede Ursache von Grund auf, sondern ist die Eingangshalle, die bestimmt, wer die Meldung geschrieben hat, und Sie zum richtigen Artikel weiterleitet. Zuerst werden die vier Ebenen getrennt, die eine Fehlerzeile schreiben können: das Backend, das das Modell bereitstellt, Claude Code selbst, das startende Programm als IDE-Erweiterung oder Wrapper und der Client eines Drittanbieters. Beim tatsächlichen Abgleich existierten zwei der fünf als Einträge in der offiziellen Fehlerreferenz von Claude Code. Die offizielle Definition von Streaming response ended… lautet, dass die Header zurückkamen, der Rumpf aber keine Nachricht der Claude API enthielt, es ist also kein Abbruch auf halbem Weg. Could not locate the Claude CLI on PATH steht in einem eigenen Kapitel, Wrapper and IDE errors, das die Dokumentation als Meldungen des startenden Programms beschreibt, und die tatsächliche Anzeige kann vier Sätze lang sein, wo die offizielle Überschrift ein Satz ist, weshalb die Suche nichts bringt. Die beiden Sätze zum content filter sind dagegen Wortschatz von Drittanbietern, und OpenCode Issue #35736 meldet, dass drei völlig getrennte Fehlschläge — ein 404 von Vertex, ein Socket-Abbruch und eine echte Ablehnung — alle als dasselbe blocked by content filter erscheinen. Nur bei einem der drei ist der Wortlaut richtig; wer ihm glaubt und seinen Prompt milder formuliert, repariert eine falsch konfigurierte Modell-ID nie. Auch GitHubs offizielle Dokumentation hält fest, dass Ein- und Ausgabe bei der Verwendung von Claude die Content-Filter von GitHub Copilot durchlaufen, Claude zu verwenden heißt also nicht, dass Anthropics Filter Sie gestoppt hat. Die letzte der fünf steht weder in der offiziellen Fehlerreferenz noch in der Dokumentation zu Remote Control, ihre Herkunft ließ sich nicht bestimmen, es wird kein Name genannt, und stattdessen stehen vier Schritte bereit, mit denen Leser sie in der eigenen Umgebung selbst bestimmen. Was feststeht und was nicht, ist durchgehend mit Labels getrennt.

Claude Code bleibt mitten in der Antwort mit „API Error: Connection lost mid-response. The response above may be incomplete.“ stehen, und die Suche nach genau dieser Zeichenfolge bringt fast nichts zurück, weil die Zeichenfolge selbst neu ist. Die offizielle Fehlerreferenz hält es klar fest: Vor v2.1.227 erschien Connection lost mid-response als Connection closed mid-response, im selben Zug wurde aus Response stalled mid-stream die Meldung The response stopped arriving und aus Connection closed while thinking, before producing a response die Meldung Connection lost before a response was produced. Das Ereignis ist nicht neu, geändert hat sich allein das Wort auf dem Bildschirm. Genau deshalb gilt Material unter dem alten Namen unverändert weiter, und genau deshalb muss eine Issue-Suche beide Zeichenfolgen verwenden. Ausgehend von dieser Umbenennung arbeitet dieser Artikel allein mit der offiziellen Dokumentation und öffentlichen Issues. Er behandelt die offiziellen Definitionen der vier Meldungen für einen Abbruch mitten in der Antwort (Server error, Connection lost, Your computer went to sleep und The response stopped arriving), warum die bereits auf dem Bildschirm stehende Ausgabe bewusst behalten wird — ein erneutes Senden könnte denselben Tool-Aufruf zweimal ausführen — und warum der Wiederherstellungsschritt darin besteht, continue zu antworten, statt von vorn zu beginnen. Danach erklärt er anhand des offiziellen Zweigs der Automatic retries, warum nichts automatisch wiederholt wird: Ein Abbruch, bevor irgendetwas abgeschlossen ist, wird mit exponentiellem Backoff bis zu zehnmal erneut gesendet; ein Abbruch nach dem Denken, aber vor jeder Ausgabe wird höchstens zweimal erneut gesendet und beendet den Turn dann mit Connection lost before a response was produced; ein Abbruch, nachdem ein Block abgeschlossen wurde, wird überhaupt nicht erneut gesendet. Von dort kartiert der Artikel die drei Ebenen, auf denen ein Stream abreißen kann — Ihr Rechner und Ihre Leitung, der Weg über Proxys und Gateways sowie die Serverseite mit der Wiederverwendung von Verbindungen —, ergänzt den leicht übersehenen vierten Fall der mTLS-Zertifikatsrotation samt dem Neuladen ab v2.1.232 und gibt eine neunstufige Checkliste zur Eingrenzung. Er listet die vier Stream-Watchdog-Timer mit ihren Standardwerten auf (erstes Byte 180 s, Event-Ebene 300 s, Byte-Ebene 180 s, Body idle fünf Minuten) sowie CLAUDE_CODE_MAX_RETRIES, CLAUDE_CODE_RETRY_WATCHDOG, API_TIMEOUT_MS und die beiden Stream-Timeout-Variablen und macht dabei deutlich, dass ein höherer Wiederholungszähler genau diese Meldung nicht verringert. Eine Vergleichstabelle trennt acht verwechselbare Meldungen, und zwei öffentliche Meldungen, #86473 und #85979, zeigen rohes HTTPS und curl, die durchlaufen, während allein die CLI mit ECONNRESET stirbt. Zum Schluss trennt der Artikel das offiziell Bestätigte von dem, was nur gemeldet ist, einschließlich der Tatsache, dass Builds vor v2.1.222 diesen Hinweis auch dann zeigen konnten, wenn die Antwort in Wahrheit vollständig war.

Die Migration auf Claude Fable 5.1 ist mit dem Austausch der Modell-ID nicht erledigt. Anthropic hält ausdrücklich fest, dass drei Änderungen Breaking Changes sind, und bei zweien davon liegen der Ort des Fehlers und seine Ursache weit auseinander. 1. Erzwungene Tool-Aufrufe enden mit 400: die Werte any und tool von tool_choice liefern invalid_request_error zurück. Bei einem Modell mit dauerhaft aktivem Denken überspringt ein erzwungener Aufruf genau dieses Denken, und die Qualität der Argumente sinkt. 2. Thinking-Blöcke werden an ein Modell gebunden: Ein Gespräch, das von der Vorgängergeneration zu Fable 5.1 wechselt, behält sein Reasoning, in der Gegenrichtung geht es verloren. Standardmäßig werden unlesbare Blöcke verworfen, bevor sie das Modell erreichen, sie zählen nicht zu input_tokens und erscheinen nicht in der Abrechnung. Wer Modelle über Router oder Fallbacks umschaltet, sieht ein System, das zu funktionieren scheint, während allein das Reasoning fehlt. Damit es auffällt, braucht es den Beta-Header thinking-binding-controls-2026-08-01. 3. Wer frühere Turns bearbeitet, macht alle folgenden Thinking-Blöcke ungültig. Betroffen sind der Neuaufbau des system-Prompts oder von tools sowie die Schreibweise, einen Reminder einzufügen und wieder zu entfernen. Diese Prüfung wird für Konten erzwungen, die ab dem 31. August 2026 angelegt wurden, weshalb eine neue Testumgebung scheitern kann, während die Produktion durchläuft. Auch die Einordnung sollte nicht verwechselt werden: Fable 5.1 ist kein Wechsel des Flaggschiffs, und Anthropic hält fest, dass die meisten Anwendungen mit Opus 5 beginnen sollten. Es gibt keine Preiserhöhung, geändert hat sich allein das Cache-Lesen, das vom 0,1-Fachen auf das 0,025-Fache der Basiseingabe gefallen ist. Wie stark es wirkt, entscheidet sich daran, wie oft dasselbe Präfix erneut gelesen wird, und Anthropic beziffert die Ersparnis auf rund 25 % bei typischer Last und bis zu rund 45 % bei stark agentisch geprägter Arbeit. Dazu ändern sich sieben Verhaltensweisen ganz ohne Codeänderung (weniger parallele Tool-Aufrufe, weniger Meldungen zum Fortschritt, bei low effort eher aus dem Gedächtnis, dichtere Prosa, weniger Formatierung, ungekennzeichnete Zitate in Zusammenfassungen, komplettes Neuschreiben auch bei kleinen Korrekturen). Bis hin zu fünf neuen Funktionen und fünf Prüfpunkten für die Migration ist alles auf Grundlage der offiziellen Dokumentation von Anthropic geordnet.

Remote Control verbindet die mobile Claude-App oder claude.ai/code mit einer Claude-Code-Session, die bereits auf Ihrem eigenen Rechner läuft, und der Punkt, den die meisten Erklärungen verfehlen, ist: Nichts wandert in die Cloud. Codeausführung und Dateizugriff bleiben durchgehend lokal, und das Handy ist nur ein Fenster in diese Session. Dieser Artikel arbeitet heraus, was dieser Entwurf einbringt und was er kostet. Lokales Dateisystem, MCP-Server, Werkzeuge und Projektkonfiguration bleiben verfügbar, das Tippen von @ vervollständigt Pfade aus dem lokalen Projekt, Gespräch und Subagent-Fortschritt bleiben zwischen Terminal, Browser und Handy synchron, und ein einschlafender Laptop oder eine abgerissene Leitung sind verkraftbar, weil Claude Code sich neu verbindet und gepufferte Updates nachliefert. Die Voraussetzungen sind strenger, als sie aussehen: Pro, Max, Team oder Enterprise, denn API-Schlüssel werden nicht unterstützt, eine Anmeldung bei claude.ai statt eines setup-token, eine direkte Verbindung zu api.anthropic.com und keine der vier Variablen, die Telemetrie abschalten, weshalb datenschutzbewusste Nutzerinnen und Nutzer mit DO_NOT_TRACK zu hören bekommen, die Funktion sei für ihr Konto nicht aktiviert. Behandelt werden die drei Einstiege, das Mitnehmen des laufenden Gesprächs, der Start mit aktivierter Fernsteuerung und der Servermodus mit seinen Flags für worktree, 32 Sessions und das Zurückholen, dazu die Trennung zwischen Slash-Befehlen, die aus der Ferne gehen, und den rein lokalen wie resume, die Fünf-Minuten-Frist für Dialoge, die nicht für Berechtigungsabfragen gilt, und die zwei Push-Schalter. Bei der Sicherheit ist der Artikel bewusst deutlich: Es wird nie ein eingehender Port geöffnet, die netzseitige Angriffsfläche verschwindet damit fast vollständig und das Risiko wandert zum Konto, der QR-Code ist eine Abkürzung und keine Authentifizierung, und das Standardtor ist genau ein angemeldetes Konto, was einen Passkey zum wirksamsten Schritt macht. Aufbewahrung des Transkripts von 5 Jahren oder 30 Tagen, das Vorgehen bei einem verlorenen Handy, Trusted Devices mit dem 18-Stunden-Fenster, der Zehn-Minuten-Abbruch im Servermodus, das Vier-Stunden-Fenster zum Zurückholen, die tmux-Pflicht auf entfernten Maschinen, eine Fehlertabelle entlang der echten Meldungen und ein Vergleich mit Dispatch runden das Bild ab.

Die Art, wie Claude denkt, hat einen Generationswechsel durchlaufen. Beim alten Extended Thinking gaben Sie bei jedem Request ein Token-Budget an — thinking: {"type": "enabled", "budget_tokens": N} — doch das richtige Budget ist je nach Aufgabe ein anderes, lässt sich vorab nicht erraten, und jede Änderung invalidiert den Prompt-Cache. Das aktuelle adaptive Denken ist eine einzige Zeile, type: "adaptive": Ob und wie tief gedacht wird, entscheidet das Modell selbst — abhängig davon, wie schwierig die Anfrage aussieht. Die Migration verlief in Stufen: budget_tokens wurde auf Opus 4.6 / Sonnet 4.6 als veraltet markiert und wird ab Opus 4.7 mit einem 400-Fehler abgelehnt. Dieser Artikel verdichtet die Regeln pro Modell zu einer Tabelle — Fable 5 denkt immer (nicht abschaltbar), Opus 5 und Sonnet 5 haben das Denken standardmäßig an (auf Opus 5 ist das Abschalten nur bei effort high oder darunter erlaubt), Opus 4.8 / 4.7 verlangen ein explizites adaptive, und Legacy-Modelle wie Sonnet 4.5 / Haiku 4.5 kennen weiterhin nur budget_tokens. Die Tiefensteuerung ist zu output_config: {"effort": ...} gewandert — fünf Stufen, Standard high — und eine effort-Änderung zerstört den Cache genauso, wie es früher die Budget-Änderung tat. Die Sichtbarkeit regelt display: Der Standard der neuen Generation ist "omitted" (leere Thinking-Blöcke), abgerechnet werden die Denk-Tokens trotzdem in voller Höhe — messen lässt sich das mit usage.output_tokens_details.thinking_tokens; die rohe Gedankenkette gibt keine Einstellung je zurück. Das Abschalten des Denkens hat auf Opus 5 dokumentierte Nebenwirkungen (Tool-Aufrufe als Fließtext, durchsickernde interne Tags), weshalb effort zu senken der sicherere Kostenhebel ist. Interleaved Thinking — Reasoning zwischen Tool-Aufrufen — läuft unter adaptivem Denken automatisch, der alte Beta-Header ist überflüssig. Und wenn Geschwindigkeit zählt, liefert Fast Mode dasselbe Opus etwa 2,5x schneller zum doppelten Preis (nur Opus 5/4.8, in Claude Code per /fast umschaltbar). Alles belegt mit Anthropics offizieller Dokumentation zu Thinking, Extended Thinking und Fast Mode.

Claude Desktop friert mitten in der Arbeit ein, und jede offene Claude-Code-Sitzung bleibt im selben Moment stehen; Sie erzwingen das Beenden, und manchmal weigert sich die App danach überhaupt zu starten. Die letzte Zeile in %APPDATA%\Claude\logs\main.log lautet fast immer gleich: GPU process gone, mit exitCode 101457950 (0x060C201E). Dieser Artikel legt dar, was dieser Code ist, warum Sitzungen mit untergehen, die miteinander nichts zu tun haben, und welche Gegenmittel real sind. Der erste Schritt ist eine Trennung: Abgestürzt ist nicht Claude Code (die CLI), sondern der GPU-Prozess der Electron-Desktop-App, in der es läuft. Der zweite ist die Frage, warum der Schaden so weit reicht. Chromium bündelt die Darstellung in einem einzigen GPU-Prozess, und davon gibt es genau einen pro Anwendung, geteilt von jedem Fenster, jedem Tab und jeder Sitzung; eine schwere Seite im In-App-Browser kann deshalb acht unbeteiligte Sitzungen im selben Augenblick mitreißen, und keine Einstellung auf Anwenderseite trennt sie. Dann folgen die Auslöser. In den öffentlichen Issues überwiegt der In-App-Browser — #80444 hält fest, wie der Prozess 15 bis 36 Sekunden nach der WebGL/WebGPU-Funktionserkennung einer Seite starb, viermal mit demselben Exit-Code; #82967 macht als Auslöser die Aufnahme des Vorschau-Screenshots durch das Browser-Werkzeug aus; #83478 reproduziert es mit einer dauerhaft offenen, sich fortlaufend aktualisierenden Vorschau. Der Browser ist aber nicht der einzige Auslöser: #68049 meldet denselben Code beim Start auf ARM64, ganz ohne Zutun des Browsers, und #83028 reproduziert ihn auf einer integrierten Intel-GPU. Die Diagnose wird anschließend an drei Dateien konkret gemacht — main.log, unknown-window.log (ein CONTEXT_LOST_WEBGL zum selben Zeitstempel) und der Crashpad-Ordner —, dazu eine Tabelle, die 101457950 von den Exit-Codes eines sauberen Herunterfahrens trennt, und die Warnung, dass die requestAdapter-Zeile zu powerPreference im selben Protokoll eine ganz normale Chromium-Meldung ist und kein Anzeichen für einen Absturz. Die Wiederherstellung behandelt Reparieren für den Fall, dass Windows das Paket als Modified kennzeichnet und den Start verweigert, daneben den Bericht, in dem der Zustand Modified, NeedsRemediation erreichte und nur eine vollständige Entfernung samt Neuinstallation die App zurückbrachte; gespeicherte Transkripte überleben, laufende Arbeit nicht (#81698 verlor die Ergebnisse parallel laufender Subagenten). Zum Schluss steht, was hilft und was nicht — --disable-gpu wird von der MSIX-Variante abgewiesen, ein Update der App hat es hier nicht gestoppt, den GPU-Prozess zu isolieren ist strukturell unmöglich —, dazu der Hinweis zur Festlegung auf eine GPU bei Hybrid-Gespannen samt der Feststellung, dass kein Bericht gefunden wurde, wonach das bei diesem Symptom geholfen hätte, und schließlich, wie Sie das erzwungene Beenden durch ein Store-Update von einem echten Absturz unterscheiden.

Dispatch ist die Funktion, bei der Sie vom Handy aus eine Anweisung schicken und Claude die Arbeit auf Ihrem eigenen Rechner ausführt (Beta, Pro und Max). Sie läuft nicht in der Cloud, sondern Ihre reale Maschine bewegt sich, und aus dieser einen Tatsache entspringen zugleich der Nutzen und die Gefahr. Die offizielle Hilfe schreibt, dass Sie Claude von Ihrem Telefon aus eine Nachricht schicken und es auf Ihrem Desktop-Computer arbeiten lassen können, wobei es dieselben Connectors, Plugins und Dateizugriffe nutzt, die Sie in Cowork bereits eingerichtet haben, und zwar innerhalb dessen, was Anthropic als ein einziges fortlaufendes Gespräch rahmt, das von beiden Geräten aus erreichbar ist. Für den Betrieb muss der PC wach und die Desktop-App geöffnet sein, und Computer Use wird nur unter macOS und Windows unterstützt, unter Linux gibt es kein Computer Use. Mechanisch arbeitet die Funktion drei Stufen der Priorität ab: einen Connector, falls einer verfügbar ist, sonst die Navigation im Browser und als letztes Mittel die direkte Bildschirminteraktion, wobei unterwegs Screenshots aufgenommen werden, um die Anzeige zu verstehen. Danach beginnt die Bewertung. Die Stellen, an denen es anhält, sind eingebaut: Computer Use ist standardmäßig aus und wird unter Einstellungen und Allgemein aktiviert; um Erlaubnis wird für jede neue Anwendung einzeln gebeten; das endgültige Löschen einer Datei erfordert ausdrückliche Erlaubnis; und Investment- und Trading-Plattformen sowie Krypto-Apps sind standardmäßig tabu. Aber es gibt Stellen, an denen es nicht anhält. Einzelne Aktionen innerhalb einer bereits freigegebenen App werden nicht mit Ihnen abgestimmt, und die offizielle Formulierung lautet, dass Claude direkt auf Ihrem Bildschirm klickt, tippt und navigiert, ohne die Berechtigungsprüfungen, die andere Cowork-Werkzeuge absichern. Die Doku ergänzt, dass zwischen Claude und dem, was auf Ihrem Bildschirm ist, keine Sandbox liegt und dass Aktionen in einer App sich auf andere Apps auswirken können. Das größte Risiko ist Prompt Injection, die Anthropic mit eigenen Worten beschreibt: Web-Inhalte sind ein primärer Vektor für Prompt-Injection-Angriffe, und eine manipulierte Anweisung, ein unerwarteter Befehl oder ein Phishing-Link, der im Browser geöffnet wird, könnte sich zu Aktionen auswachsen, die sich nur schwer oder gar nicht rückgängig machen lassen. Anthropic gibt an, die Aktivierungen des Modells zu durchsuchen, um solches Verhalten zu erkennen, doch das senkt die Wahrscheinlichkeit, statt Ihnen das Ziehen einer eigenen Grenze abzunehmen, und die Hinweise sagen weiterhin, dass man auf manuelle Bestätigung umstellen soll, sobald eine Aufgabe sensible Dateien, Konten oder Websites berührt. Anthropic benennt die Grenze ausdrücklich: Erteilen Sie Computer Use keine Zugriffsberechtigung auf sensible Apps wie Banking, Gesundheitswesen und Behörden, und vermeiden Sie Finanzkonten, Rechtsdokumente, medizinische Informationen und personenbezogene Daten. Der Artikel behandelt auch die Handyseite. Was bei Verlust des Geräts nach außen dringt, sind nicht die darauf gespeicherten Daten, sondern die Befugnis, Ihrem PC Anweisungen zu geben, plus die Inhalte des fortlaufenden Gesprächs — und die offizielle Hilfe zu Dispatch dokumentiert weder das Entkoppeln noch das Vorgehen bei Verlust, weshalb die Gegenmittel von der Kontoseite kommen: die einzelne Sitzung unter Einstellungen, Konto und Aktive Sitzungen beenden, sich über claude.ai von allen Sitzungen abmelden (was in den Mobil-Apps nicht verfügbar ist und daher einen Webbrowser erfordert) oder schlicht die PC-Seite kappen, indem Sie die Desktop-App schließen oder die Maschine schlafen legen, was tatsächlich am schnellsten wirkt, weil Dispatch einen wachen PC mit geöffneter App verlangt. Zum Schluss trennt der Artikel Dispatch und Computer Use als zwei getrennte Schalter, grenzt beide von der agent view in Claude Code ab (die die offizielle Doku ebenfalls dispatch nennt) und zieht eine praktische Grenze: Fangen Sie mit Arbeit an, die Sie zurücknehmen können.

Die agent view von Claude Code, geöffnet mit claude agents, ist die Funktion, mit der Sie eine unabhängige Hintergrund-Session nach der anderen starten und alle von einem einzigen Bildschirm aus verwalten. Die offizielle Dokumentation nennt die Operation, die Sie dort ausführen, dispatch, was mit der gleichnamigen, aber völlig anderen Funktion der Desktop-App kollidiert, weshalb die erste Aufgabe darin besteht, beide auseinanderzuhalten. Die Doku beschreibt agent view als die Funktion, mit der sich viele Claude-Code-Sessions von einem Bildschirm aus dispatchen und verwalten lassen, und sie ist eine Research Preview, die v2.1.139 oder neuer voraussetzt. Dieser Artikel bleibt bei der Mechanik und dem Sicherheitsmodell. Die erste Überraschung ist, dass jeder Prompt, der in das Eingabefeld getippt wird, seine eigene neue Session startet: Tippen Sie einen zweiten, bekommen Sie eine zweite Session neben der ersten und keine zusätzliche Anweisung an die erste. Weitere Anweisungen laufen über das Peek-Panel, das mit Space geöffnet wird und die letzte Ausgabe oder die Frage zeigt, auf die die Session wartet, statt des gesamten Protokolls. Das Herz des Sicherheitsmodells ist die Isolation über worktrees. Bevor eine Hintergrund-Session irgendeine Datei bearbeitet, zieht sie in ein isoliertes git worktree unterhalb von .claude/worktrees/ um, sodass parallele Sessions denselben Checkout lesen, aber jeweils in ihren eigenen schreiben, also gemeinsam lesen und getrennt schreiben. Alles, was den Haupt-Checkout erreichen würde, wird von drei Prüfungen abgeschnitten: Dateibearbeitungen über Edit, Write und NotebookEdit; Arbeitsverzeichnisse von Befehlen, die auf den Haupt-Checkout zeigen oder bei denen sich nicht überprüfen lässt, dass sie draußen bleiben; und Versuche, git über git -C, --git-dir, GIT_DIR, GIT_WORK_TREE oder ein cd vor dem git-Aufruf umzulenken. Die Entscheidung fällt bewusst auf der sicheren Seite und verweigert, was sich nicht überprüfen lässt, und derselbe Schutz wird an jeden Subagent vererbt, den die Session erzeugt. Eine Mauer auf Betriebssystemebene ist es allerdings nicht: Dateien außerhalb des Repositorys und das Netzwerk fallen nicht in den Geltungsbereich, und PowerShell-Befehle bekommen nur die Prüfung des Arbeitsverzeichnisses. Auch die Berechtigungen werden nicht beim Dispatch gewählt, sondern aus dem defaultMode des jeweiligen Verzeichnisses geerbt oder aus dem permissionMode im Frontmatter eines dispatchten Subagents, was bedeutet: Je lockerer Ihre übliche Konfiguration ist, desto mehr unbeaufsichtigte Sessions mit lockeren Rechten entstehen auf einen Schlag. Drei Dinge dringen dann aus der Isolation nach außen. Die Wahl von „Ja, nicht mehr fragen“ speichert die Regel in der .claude/settings.local.json des Haupt-Checkouts, sie gilt also im Haupt-Checkout und in jedem anderen worktree und überlebt das Löschen genau des worktree, in dem sie entstanden ist. Eine Session in der agent view zu löschen, löscht das von Claude erzeugte worktree gleich mit, sodass nicht committete Arbeit verschwindet — und Ctrl+X stoppt beim ersten Druck und löscht beim zweiten. Und .worktreeinclude kopiert per gitignore ausgeschlossene Dateien wie .env in jedes neue worktree und vervielfacht Ihre Zugangsdaten mit der Zahl der dispatchten Sessions. Hinzu kommt, dass das Kontingent proportional zur Parallelität schmilzt (zehn Agenten verbrauchen es etwa zehnmal so schnell) und dass Sessions lokal laufen, den Ruhezustand überstehen, aber beim Herunterfahren der Maschine enden. Zum Abschluss ordnet der Artikel agent view in die vier offiziellen Wege zur Parallelisierung neben Subagents, Agent Teams und dynamischen Workflows ein und gibt einen konkreten Ablauf für die Zeit vor, während und nach einem Dispatch.

Viele drücken das /compact von Claude Code nach einer Regel wie „alle 30 Minuten“ oder „sobald der Kontext 70 Prozent überschreitet“, doch was die offizielle Dokumentation empfiehlt, ist weder eine Uhr noch ein Prozentsatz, sondern eine Zäsur in der Arbeit: /compact an einem natürlichen Einschnitt ausführen, etwa zwischen zwei Aufgaben, statt darauf zu warten, dass die automatische Komprimierung mitten in einer Aufgabe anspringt. Dieser Artikel nimmt die Claude-Code-Dokumentation mit Stand vom 8. August 2026 (aktuelles Release v2.1.226) als Primärquelle und arbeitet die Frage nach der manuellen Komprimierung aus der Spezifikation heraus. Er beginnt mit der Mechanik: Die Komprimierung läuft in drei Stufen, nämlich dem Verwerfen alter Tool-Ausgaben, der automatischen Komprimierung und dem manuellen /compact, das Sie selbst drücken. Die zweite und die dritte Stufe sind dieselbe Verarbeitung, selbst zu drücken bringt also genau zwei Dinge, nämlich den Zeitpunkt zu wählen und anzugeben, was erhalten bleiben soll. Häufiger zu drücken spart keinen zusätzlichen Kontext. Danach folgt eine Tabelle dessen, was überlebt. Die CLAUDE.md im Projekt-Wurzelverzeichnis und Ihr automatisches Gedächtnis werden von der Festplatte neu geladen, während Regeln mit paths: und verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen verloren gehen, bis wieder eine passende Datei gelesen wird, und die Inhalte aufgerufener Skills werden mit einer Obergrenze von 5.000 Tokens pro Skill und 25.000 insgesamt neu geladen, wobei die ältesten zuerst wegfallen. Bei den Kosten gilt: Der Preis einer Komprimierung bestimmt sich nicht über die Größe des Kontexts, sondern darüber, ob der Prompt-Cache warm ist. Mitten in der Sitzung gedrückt, wird das Präfix aus dem Cache gelesen, was billig ist; nach einer Pause, die länger als die Cache-Lebensdauer ist (eine Stunde im Abonnement, standardmäßig fünf Minuten über einen API-Schlüssel), wird der gesamte Verlauf ungecacht neu verarbeitet, und teurer wird dieser Befehl nie. Von dort behandelt der Artikel die Wahl zwischen /compact, /clear, /rewind, /recap und /context, wie /autocompact ab v2.1.221 den automatischen Auslösepunkt zwischen 100K und 1M Tokens verschiebt und in welcher Rangfolge die vier möglichen Quellen der Einstellung greifen, die Falle, dass nur die Umgebungsvariable eine schlichte Ganzzahl akzeptiert, sowie Bedeutung und Behebung der beiden Meldungen „Not enough messages to compact.“ und „Autocompact is thrashing: the context refilled to the limit...“.

Sie wollen Claude Desktop unter Windows öffnen, und stattdessen erscheint ein Dialog mit der Überschrift „Diese App kann nicht geöffnet werden“, der Sie auffordert, in die erweiterten Optionen von Claude zu gehen und dort Reparieren auszuwählen — und genau das zu tun, funktioniert. Kein Deinstallieren, und kein Zurücksetzen, das Ihre Daten wegwirft. Es gibt allerdings einen Schritt dazwischen, an dem die Leute wirklich hängen bleiben, und der steht im Mittelpunkt dieses Artikels. Ein Klick auf Reparieren kann mit der Meldung zurückkommen, die App laufe noch, obwohl nirgendwo ein Claude-Fenster offen ist. Die Ursache: Claude Desktop läuft nach dem Schließen des Fensters im Infobereich der Taskleiste weiter, und solange dieser Hintergrundprozess die Paketdateien offen hält, kann die Reparatur nicht durchlaufen. Die Lösung ist einfach: die Prozesse ausdrücklich beenden und dann auf Reparieren klicken. Und genau diese Tatsache weist auf die Ursache des Fehlers selbst hin — derselbe Prozess hat das Update kaputt gemacht und anschließend die Reparatur blockiert. Der Artikel beantwortet außerdem die Frage, die fast alle zuerst stellen: Gehen die Sitzungen verloren? Die Antwort teilt sich in drei. Der Unterhaltungsverlauf von claude.ai liegt auf den Servern von Anthropic und bleibt unangetastet. Claude-Code-Sitzungen liegen unter %USERPROFILE%\.claude\projects\, also außerhalb des App-Pakets, und überstehen deshalb eine Reparatur, ein Zurücksetzen und sogar eine Deinstallation (auf einem echten Rechner waren es 2.977 Dateien mit rund 3,0 GB in 52 Projekten). Gefährdet sind allein die App-eigenen Einstellungen in %APPDATA%\Claude, und selbst die behält Reparieren — Windows schreibt den Unterschied direkt auf den Bildschirm: neben Reparieren steht, dass die Daten der App nicht betroffen sind, neben Zurücksetzen, dass sie gelöscht werden. Danach folgen die nur lesende Zustandsprüfung in PowerShell, eine Sicherungsroutine, eine gestufte Eskalation für den Fall, dass sich die App weiterhin nicht öffnet (prüfen, ob vmcompute und hns laufen, Neuinstallation mit -PreserveApplicationData), die abgeleitete Ursache eines halb registrierten MSIX samt der GitHub-Issues (#55465, wo die Installation gelang, aber kein Einstiegspunkt entstand, dazu #50285 und #48437 — alle als closed as not planned beendet, ohne offizielle Korrektur), wie Sie die Wahrscheinlichkeit einer Wiederholung senken, und ein Vergleich mit der alten Installer-Variante, bei der die neueste MSIX-Auslieferung und ein Rechner mit altem Format beide 1.24012.9 zeigten.

Claude Code bleibt mitten in einer Antwort mit „API Error: Connection closed mid-response. The response above may be incomplete.“ stehen. Das ist kein Prompt-Problem: Die Verbindung, die die gestreamte Antwort transportierte, wurde geschlossen, während die Antwort noch ankam. Dieser Artikel stützt sich ausschließlich auf die offizielle Fehlerreferenz, das offizielle Changelog und Issues mit Paketmitschnitten. Er beginnt mit den offiziellen Definitionen: Connection closed heißt, die Leitung wurde gekappt, Response stalled heißt, sie ist verstummt, Server error heißt, mitten im Stream kam ein 5xx; er erklärt, warum die Teilausgabe bewusst erhalten bleibt (ein erneutes Senden könnte dieselben Tool-Aufrufe zweimal ausführen) und dass der dokumentierte Wiederaufnahmeschritt die Antwort continue ist. Anschließend trennt er die drei Ebenen, von denen das Schließen ausgehen kann (Ihr Rechner und der Ruhezustand, ein Leerlauf-Timeout in Proxy oder VPN, oder ein Schließen vom Server aus) und zeigt die vom Melder des Issues #67766 veröffentlichten Messwerte: alle zehn Vorfälle waren saubere serverseitige Schließungen, der Fehler erschien 3 bis 105 ms nach dem FIN, 7 bis 20 KB der Antwort waren bereits eingetroffen, der Anfragerumpf lag bei 1 bis 2,5 MB, eine neue Verbindung gelang in etwa 20 ms, und in 23 Tagen Aufzeichnungen fanden sich 200 Fehler in 171 Vorfällen, davon 87 weniger als fünf Sekunden nach dem vorherigen Aufruf. Der praktische Kern ist eine Chronologie echter Changelog-Einträge — 2.1.179 bewahrt die Teilantwort, 2.1.185 verschiebt den Stockungshinweis von 10 auf 20 Sekunden, 2.1.198 wiederholt vorübergehende Abbrüche mit Backoff, 2.1.199 bewahrt die Teilantwort auch bei Serverfehlern im Stream, 2.1.214 deaktiviert den Keep-Alive-Pool nach einem Fehler durch eine veraltete Verbindung — gegengehalten mit den Versionen der Meldungen (2.1.173, 2.1.181, 2.1.183), die alle vor 2.1.198 liegen. Zum Schluss folgen die begünstigenden Bedingungen, eine Checkliste in acht Schritten, sechs Leitlinien für Entwickler, die Abgrenzung zu Unable to connect und Prompt is too long sowie eine klare Trennung zwischen offiziell Bestätigtem und Unbestätigtem.

Anthropic hat Claude Opus 5 am 24. Juli 2026 veröffentlicht und beschreibt das Modell in der eigenen Dokumentation als Sprung statt schrittweise Verbesserung gegenüber Opus 4.8 — und trotzdem bewegt sich der Preis nicht: $5 Input / $25 Output pro Million Tokens, exakt die Hälfte des Flaggschiffs Fable 5 ($10 / $50). Dieser Artikel gleicht die offizielle Ankündigung und die Dokumentation mit mehreren Berichten ab und ordnet die Eckdaten ein (claude-opus-5, 1M Kontext als Standard und Maximum zugleich, 128K maximaler Output, Wissensstand Mai 2026), die Preise inklusive Cache-Raten und Fast Mode (rund 2,5-fache Geschwindigkeit zum doppelten Preis, nur über die Claude API), die Benchmarks (Anthropic schreibt selbst, dass Frontier-Bench mehr als das Doppelte von Opus 4.8 erreicht, CursorBench 3.2 innerhalb von 0,5 % von Fable 5 landet, ARC-AGI 3 das Dreifache des Zweitplatzierten erzielt und OSWorld 2.0 Fable 5 zu rund einem Drittel der Kosten schlägt; aus Diagrammen abgelesene Pressewerte nennen Frontier-Bench 43,3 %, ARC-AGI-3 30,2 %, GDPval-AA 1.861 und OSWorld 70,6 %) sowie die Stellen, an denen Opus 5 weiterhin unterliegt (68,8 % gegenüber 72,7 % von GPT-5.6 Sol in DeepSWE v1.1, offensive Sicherheit und langfristige Biologieforschung, wo Mythos 5 führt, und Konstellationen, in denen Effort max schlechter abschneidet als niedrigere Stufen). Danach folgen die beiden Breaking Changes der API (Thinking ist standardmäßig aktiv, weshalb knapp bemessene max_tokens-Budgets zu abgeschnittenen Antworten führen; Thinking lässt sich nur bei Effort high oder darunter abschalten, xhigh oder max liefert einen 400-Fehler), die Wahl unter den fünf Effort-Stufen, neue Funktionen wie Tool-Änderungen mitten im Gespräch, eine auf 512 Tokens halbierte Cache-Mindestlänge und der Fallback-Modus default, das veränderte Verhalten mit längeren Antworten, mehr Kommentierung, bereitwilligerer Delegation und unaufgeforderter Selbstprüfung — mit der Migrationsregel, dass man Prompt-Text entfernt statt ergänzt — und schließlich, wer jetzt migrieren sollte, samt einer Checkliste in sechs Schritten.