Claude Code mit DeepSeek: Sitzung nach Input length exceeds maximum retten

Sie geben in Claude Code nur eine kurze Anweisung ein und erhalten status_code=400, Input length 1048609 exceeds the maximum length 1048566. Wiederholen Sie die Anfrage nicht und gehen Sie nicht davon aus, dass das Löschen von 43 Zeichen genügt. Der sichere Ablauf lautet: Code und Aufgabenstand außerhalb des Modells sichern, ein gezieltes /compact versuchen, bei erneutem Fehlschlag auf einen Checkpoint oder eine leere Sitzung ausweichen und erst danach klären, ob Modell, Claude Code oder ein zwischengeschaltetes Gateway abgelehnt hat.

Die Meldung belegt nur, dass eine Schicht den Input um 43 nicht näher bezeichnete Einheiten über ihrem Limit sieht. Ob damit Tokens, Zeichen oder Bytes gemeint sind, bleibt offen. Ebenso wenig beweist die Meldung, dass die Anfrage DeepSeek erreicht hat. Ohne tatsächliche model ID, Base URL, Claude-Code-Version, Proxy-Kette und unveränderte Antwort lässt sich der Fehler keinem bestimmten Modell zuordnen.

Sichern Sie die Arbeit vor dem nächsten Modellaufruf

Beenden Sie zuerst die Wiederholungsversuche in der überfüllten Sitzung. Änderungen am Code liegen meist bereits auf dem Datenträger. Gefährdet ist der Teil, der nur im Gespräch existiert: Was wurde geändert, was wurde geprüft und was sollte als Nächstes passieren?

Öffnen Sie ein zweites Terminal und erfassen Sie den Zustand, ohne das überlastete Modell um eine Zusammenfassung zu bitten:

claude --version
git status --short
git diff --stat
git diff > claude-context-recovery.patch
git diff --cached > claude-context-recovery-staged.patch

Falls das Projekt kein Git verwendet, kopieren Sie die geänderten Dateien oder erstellen Sie über die lokale Historie des Editors einen Snapshot. Schreiben Sie anschließend manuell eine kurze RECOVERY.md:

Ziel:
Geänderte Dateien:
Bereits geprüft:
Noch fehlerhaft:
Wichtige Entscheidungen:
Nächster einzelner Schritt:
Nicht erneut laden: vollständige Logs, gesamtes Repository, irrelevante Historie

Diese Übergabe muss nicht elegant sein. Sie soll einer neuen Sitzung ermöglichen, die Aufgabe aus wenigen Absätzen wiederaufzunehmen, statt Hunderttausende Tokens erneut zu laden.

Erfassen Sie für die Diagnose nur nicht geheime Daten: claude --version, model ID, Domain der Base URL, Namen der Proxies und den exakten Fehler. Geben Sie keine API Keys, Authorization-Header, vollständigen internen Prompts oder Umgebungsvariablen mit Zugangsdaten aus.

Unterscheiden Sie das Limit, bevor Sie etwas ändern

Ähnlich klingende Meldungen können verschiedene Grenzen meinen.

Fehlerform	Mögliche Bedeutung	Erste Maßnahme
Input length X exceeds the maximum length Y	Eine Schicht begrenzt Input oder Anfragegröße; die Einheit muss kein Token sein	Verlauf und tool output verkleinern, dann die ablehnende Schicht bestimmen
input length and max_tokens exceed context limit: A + B > C	Input plus reservierte Ausgabe überschreiten gemeinsam das Kontextbudget	Früher kompaktieren; Ausgabe nur bei bestätigter Ursache verkleinern
HTTP 413 oder request body too large	HTTP-Body- oder Reverse-Proxy-Limit	Uploads, Kodierung und body-size des Proxys prüfen
All target providers failed oder generischer Wrapper	Das Gateway kann den Upstream-Fehler verbergen	Ursprünglichen Versuch, Logs und request ID prüfen

In Claude Code #42 beschrieb ein Nutzer einen 400-Fehler, bei dem Input und max_tokens zusammen zu groß waren. In #8136 berichtete ein anderer Nutzer, dass /compact nahe der Grenze selbst scheitern könne, weil die Kompaktierungsanfrage Platz für ihre Ausgabe benötige. Das sind unabhängige Nutzerberichte, keine Belege für die Ursache in Ihrer Umgebung.

Darum rechtfertigt die Differenz von 43 nicht, genau 43 sichtbare Zeichen zu löschen. Claude Code sendet zusätzlich Systemanweisungen, Gesprächsverlauf, Tool-Definitionen, Dateiinhalte und Tool-Ergebnisse. Schaffen Sie deutlichen Abstand zur Grenze, statt exakt eine Einheit darunter landen zu wollen.

Zweig A: /compact funktioniert noch

Wenn Slash Commands noch ausgeführt werden, prüfen Sie zunächst die Belegung und geben Sie dem Compact-Vorgang ein klares Ziel.

/context

Danach:

/compact Behalte das aktuelle Ziel, geänderte Dateien, geprüfte Ergebnisse, wichtige Entscheidungen, das offene Problem und den nächsten Schritt. Entferne vollständige Logs, wiederholte Dateiinhalte, verworfene Wege und irrelevante Diskussionen.

Scannen Sie nach erfolgreicher Kompaktierung nicht sofort wieder das gesamte Repository. Testen Sie mit einer kleinen, beobachtbaren Aufgabe:

Lies nur RECOVERY.md und src/auth/session.ts. Nenne die Funktion, die als Nächstes geändert werden sollte. Durchsuche keine anderen Verzeichnisse und ändere keine Dateien.

Eine Wiederherstellung ist erst dann überzeugend, wenn vier Signale zusammenkommen:

1. /context zeigt eine deutlich niedrigere Belegung;
2. eine kleine Anfrage liefert keinen 400 mehr;
3. das Modell kann Ziel, geänderte Dateien und nächsten Schritt korrekt wiedergeben;
4. git diff und Testergebnisse stimmen weiterhin mit der Übergabe überein.

Beim Kompaktieren können Details verloren gehen. Dauerhafte Projektregeln gehören in die CLAUDE.md des Projekts; kritischer Aufgabenstand sollte in Dateien liegen und nicht nur in einem langen Gespräch.

Zweig B: /compact liefert ebenfalls Conversation too long oder denselben 400

Führen Sie /compact nicht wiederholt gegen denselben übergroßen Verlauf aus. In Claude Code #26317 meldete ein Nutzer, dass nach Erreichen des Limits auch die Kompaktierung mit Conversation too long scheiterte. Dass das Issue als not planned geschlossen wurde, bedeutet nicht, dass das Verhalten in jeder Version und bei jedem kompatiblen Endpoint ausgeschlossen ist.

Springen Sie vor den großen Log- oder Tool-Output zurück

Die offizielle Anleitung zum Checkpointing erlaubt /rewind oder zweimaliges Drücken von Esc, wenn das Eingabefeld leer ist. Zu den Optionen gehören:

• Restore conversation: Gespräch zurücksetzen, aktuellen Code behalten;
• Summarize from here: Nachrichten nach dem gewählten Checkpoint zusammenfassen;
• Summarize up to here: ältere Historie komprimieren und spätere Nachrichten behalten.

Wählen Sie einen Checkpoint vor dem Einfügen eines vollständigen Logs, dem Lesen einer großen Datei oder einem ungewöhnlich umfangreichen Tool-Ergebnis. Das Gespräch zurückzusetzen, den Code zu behalten und anschließend eine eng begrenzte Aufgabe zu senden, ist oft sicherer als die bereits überlaufende Spitze weiter zu komprimieren.

Auch eine Zusammenfassung kann einen Modellaufruf erfordern. Lehnt der Upstream diesen ebenfalls ab, wechseln Sie zu einer Wiederherstellung mit leerem Kontext.

Wenn Rewind nicht hilft, verwenden Sie /clear oder eine neue Sitzung

/clear

Laut offizieller Befehlsreferenz startet /clear eine neue Unterhaltung mit leerem Kontext; die vorherige Sitzung bleibt gespeichert. Dateien auf dem Datenträger und Git diff werden nicht zurückgesetzt.

Beginnen Sie die saubere Sitzung mit einer begrenzten Anweisung:

Lies RECOVERY.md, git diff --stat und die beiden dort genannten Dateien. Prüfe zuerst den aktuellen Stand. Scanne nicht das gesamte Repository. Schlage nur den nächsten Schritt vor und warte vor Änderungen auf eine Bestätigung.

Starten Sie nicht sofort claude --continue, claude --resume oder /resume. Die offizielle Sitzungsdokumentation erklärt, dass beim Fortsetzen der vollständige Verlauf und die Tool-Ergebnisse wiederhergestellt werden. War genau dieser Verlauf zu groß, kann die nächste Anfrage erneut scheitern.

Finden Sie die ablehnende Schicht mit vier günstigen Tests

Nachdem die Arbeit gesichert ist, ändern Sie pro Test nur eine Variable und verwenden Sie dieselbe kleine Read-only-Aufgabe.

Test	Ergebnis	Sinnvollste Deutung
Gleicher Endpoint und Modell, leere Sitzung, kleine Aufgabe	Erfolgreich	Alter Verlauf oder großer tool output sind wahrscheinlicher
Dieselbe kleine Aufgabe scheitert in leerer Sitzung	Fehler	model mapping, Anfrageformat, Client-Version oder Server-cap prüfen
Wenn zulässig, offiziellen Endpoint mit Gateway vergleichen	Direkt erfolgreich, Gateway nicht	Limits, Konvertierung und Fehleraggregation des Gateways prüfen
/compact scheitert, kleine Aufgabe nach /clear klappt	Erfolgreich	Kompaktierungsanfrage passte nicht in das echte Fenster oder der Client nahm ein falsches Fenster an

Erfassen Sie Routing-Werte ohne Secrets:

printf 'BASE_URL=%s\nMODEL=%s\nOPUS=%s\nSONNET=%s\nHAIKU=%s\nSUBAGENT=%s\n' \
  "${ANTHROPIC_BASE_URL:-<unset>}" \
  "${ANTHROPIC_MODEL:-<unset>}" \
  "${ANTHROPIC_DEFAULT_OPUS_MODEL:-<unset>}" \
  "${ANTHROPIC_DEFAULT_SONNET_MODEL:-<unset>}" \
  "${ANTHROPIC_DEFAULT_HAIKU_MODEL:-<unset>}" \
  "${CLAUDE_CODE_SUBAGENT_MODEL:-<unset>}"

Der Befehl zeigt absichtlich kein ANTHROPIC_AUTH_TOKEN. Dokumentieren Sie zusätzlich, ob Claude Code Router, ein Switcher, ein Unternehmens-Gateway, Reverse Proxy oder Multi-Provider-Fallback beteiligt ist.

In Claude Code Router #1799 berichtete ein Nutzer, dass ein Gateway einen konkreten Upstream-Kontextfehler durch All target providers failed ersetzte. Der lokale Patch des Autors ist keine allgemeine Produktionslösung; der Fall zeigt aber, warum Support-Logs Upstream-status, body und request ID bewahren sollten.

Prüfen Sie die echte DeepSeek-Route statt nur das Label [1m]

Mit Stand 30. September 2026 setzt das clientseitige Umgebungsvariablen-Beispiel auf der offiziellen Seite zur DeepSeek-Integration in Claude Code:

• ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL und ANTHROPIC_DEFAULT_SONNET_MODEL auf deepseek-flash[1m];
• ANTHROPIC_DEFAULT_HAIKU_MODEL und CLAUDE_CODE_SUBAGENT_MODEL auf deepseek-flash;
• CLAUDE_CODE_AUTO_COMPACT_WINDOW=786432.

Dieselbe Seite dokumentiert getrennt ein serverseitiges Mapping für Modellnamen im Claude-Format: Namen mit claude-opus am Anfang werden deepseek-v4-pro zugeordnet, Namen mit claude-haiku oder claude-sonnet am Anfang dagegen deepseek-flash. Diese Service-Regel und die expliziten Werte im Client-Beispiel sind zwei verschiedene Fakten; sie dürfen nicht zu einer einzigen Aussage über die tatsächliche Route verschmolzen werden.

Keine der beiden Passagen belegt, welches Modell oder Kontextfenster diese konkrete Anfrage verarbeitet hat. Prüfen Sie verfügbare Request- oder Usage-Daten, das ursprüngliche Feld model, den ausgewählten Provider beziehungsweise die Route und die Upstream-request ID, statt dies aus der Oberfläche oder einem älteren Tutorial abzuleiten.

Auch ein [1m]-Label garantiert nicht, dass jede Schicht eine Million Tokens akzeptiert. Client, Compatibility API, Gateway, Fallback-Anbieter und endgültiges Modell können unterschiedliche Limits haben. Reservierte Ausgabe belegt ebenfalls Kontext.

Kompaktieren Sie früher, statt das Fenster künstlich zu vergrößern

Das aktuelle DeepSeek-Beispiel enthält:

export CLAUDE_CODE_AUTO_COMPACT_WINDOW="786432"

Das ist eine clientseitige Schwelle für frühere Kompaktierung, kein Weg, das harte Provider-Limit zu erweitern. Laut offizieller Referenz der Umgebungsvariablen muss der Wert eine ganze Zahl sein, bleibt durch das Modellfenster begrenzt und überschreibt /autocompact, Start-Flags und settings.

Akzeptieren Modell oder Gateway weniger, verwenden Sie einen niedrigeren, bestätigten Wert. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE kann die Kompaktierung früher auslösen, aber nicht das Fenster vergrößern.

Behandeln Sie CLAUDE_CODE_MAX_CONTEXT_TOKENS nicht als Schalter zum Freischalten zusätzlicher Tokens. Die Variable teilt Claude Code die verifizierte echte Fenstergröße einer benutzerdefinierten oder unbekannten Modellroute mit. Ein zu hoher Wert verzögert Compact und macht einen Upstream-400 wahrscheinlicher.

Diese Gewohnheiten sind häufig wirkungsvoller:

• große Logs mit grep, rg, tail oder einem Skript filtern;
• große Dateien nach Funktion oder Zeilenbereich lesen;
• /clear zwischen unabhängigen Aufgaben verwenden;
• breite Recherchen an einen Subagent delegieren und nur die Zusammenfassung übernehmen;
• ein gezieltes /compact vor einer neuen Phase ausführen;
• identische Schemas, komplette build logs und vollständige diffs nicht wiederholen.

Testen Sie mit einer kleinen realen Aufgabe

Nach Wiederherstellung oder Konfigurationsänderung:

1. eine leere Sitzung starten;
2. nur RECOVERY.md und eine kleine Datei lesen;
3. eine kurze, klar begrenzte Antwort anfordern;
4. prüfen, ob der 400 verschwunden ist;
5. Dateien und Tool-Aufrufe schrittweise hinzufügen.

Scheitert bereits die minimale Anfrage, kürzen Sie nicht weiter am alten Gespräch. Prüfen Sie Endpoint, model mapping, Proxy-Verhalten und Anfrageformat. Scheitert nur die lange Sitzung, konzentrieren Sie sich auf Compact-Zeitpunkt, Ergebnisgrößen und Sitzungsgrenzen.

Häufige Fragen

Warum half ein Neustart von Claude Code nicht?

Ein Neustart bedeutet nicht zwingend einen leeren Verlauf. --continue, --resume und der Sitzungsauswahldialog stellen das alte Gespräch wieder her. Zur Isolierung brauchen Sie eine wirklich neue Sitzung und eine kleine Kontrollaufgabe.

Hilft eine kleinere Ausgabe?

Nur wenn die Meldung ausdrücklich sagt, dass Input plus max_tokens das gemeinsame Budget übersteigen. Hat der Input ein eigenes Limit, garantiert eine kleinere Ausgabe keine Lösung.

Löst ein anderes Gateway das Problem immer?

Nein. Es kann helfen, wenn das aktuelle Gateway einen kleineren body limit setzt oder Upstream-Fehler verbirgt. Kein Gateway kann das harte Limit des endgültigen Modells überschreiten.

Löscht /clear den Code?

Nein. Es leert den Gesprächskontext, nicht die bereits geschriebenen Dateien. Prüfen Sie trotzdem git status und sichern Sie Patch, Commit oder Editor-Snapshot.

Warum nicht genau 43 Zeichen entfernen?

Die Einheit ist unbekannt, und die Anfrage enthält unsichtbare Systeminhalte, Tools und Historie. Ausreichender Abstand ist zuverlässiger als ein Ziel exakt an der Grenze.

Die Wiederherstellungsreihenfolge zum Merken

Bei Input length exceeds maximum gilt: Diff und manuelle Übergabe in einem zweiten Terminal sichern → /context ausführen → gezieltes /compact versuchen → bei Fehlschlag mit /rewind vor den großen Output springen → wenn das nicht hilft, /clear oder neue Sitzung verwenden → mit einer kleinen Aufgabe die begrenzende Schicht finden → Auto-Compact unter das bestätigte Serverfenster setzen.

Dieser Ablauf muss nicht erraten, was die Zahl 43 bedeutet, und verspricht nicht, dass ein Proxy ein hartes Modelllimit umgehen kann. Er schützt zuerst die vorhandene Arbeit und macht anschließend aus einem unspezifischen 400 eine reproduzierbare Diagnose von Schicht zu Schicht.