Claude Code avec DeepSeek : récupérer une session après Input length exceeds maximum

Vous ajoutez une courte instruction dans Claude Code et obtenez status_code=400, Input length 1048609 exceeds the maximum length 1048566. Ne relancez pas la même requête et ne supposez pas qu’il suffit de retirer 43 caractères. La méthode la plus sûre consiste à sauvegarder le code et l’état de la tâche en dehors du modèle, tenter un /compact ciblé, revenir à un checkpoint ou à une session vierge si le compactage échoue aussi, puis déterminer si le rejet vient du modèle, de Claude Code ou d’une passerelle intermédiaire.

Le message prouve seulement qu’une couche considère l’entrée comme dépassant sa limite de 43 unités non précisées. Il ne dit pas s’il s’agit de tokens, de caractères ou d’octets, et ne prouve pas que la requête a atteint DeepSeek. Sans le model ID réel, le Base URL, la version de Claude Code, la chaîne de proxies et la réponse brute, on ne peut pas attribuer cette erreur à un modèle précis.

Sauvegardez le travail avant toute nouvelle requête au modèle

Arrêtez d’abord les tentatives depuis la conversation saturée. Le code est généralement déjà écrit sur le disque. Ce qui risque de disparaître, c’est l’état de travail présent uniquement dans le chat : changements effectués, vérifications terminées et prochaine action.

Dans un autre terminal, capturez cet état sans demander au modèle en échec de le résumer :

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

Si le projet n’utilise pas Git, copiez les fichiers modifiés ou créez un snapshot avec l’historique local de l’éditeur. Rédigez ensuite manuellement un court RECOVERY.md :

Objectif :
Fichiers modifiés :
Déjà vérifié :
Encore en échec :
Décisions importantes :
Prochaine action unique :
Ne pas recharger : logs complets, dépôt entier, historique sans rapport

Cette note n’a pas besoin d’être élégante. Elle doit permettre à une session neuve de reprendre la tâche avec quelques paragraphes au lieu de reconstruire des centaines de milliers de tokens.

Pour le diagnostic, ne conservez que les données non sensibles : claude --version, model ID, domaine du Base URL, nom des proxies et message exact. N’affichez jamais d’API Key, d’en-tête d’autorisation, de prompt métier complet ni de variable d’environnement contenant des identifiants.

Identifiez la limite avant de choisir le correctif

Des messages proches peuvent correspondre à des limites différentes.

Forme de l’erreur	Signification possible	Première action
Input length X exceeds the maximum length Y	Une couche plafonne l’entrée ou la taille de la requête ; l’unité n’est pas forcément le token	Réduire l’historique et le tool output, puis trouver la couche de rejet
input length and max_tokens exceed context limit: A + B > C	Entrée et sortie réservée dépassent ensemble le budget de contexte	Compacter plus tôt ; réduire la sortie seulement si cette cause est confirmée
HTTP 413 ou request body too large	Limite du corps HTTP ou d’un reverse proxy	Vérifier pièces jointes, encodage et body-size du proxy
All target providers failed ou autre erreur générique	La passerelle peut masquer l’erreur upstream	Examiner la tentative brute, les logs et le request ID

Dans Claude Code #42, un utilisateur a signalé un 400 où l’entrée et max_tokens dépassaient ensemble la fenêtre. Dans #8136, un autre utilisateur a indiqué que /compact pouvait échouer près de la limite parce que la requête de compactage devait elle-même réserver une sortie. Ce sont deux retours d’utilisateurs indépendants, pas une preuve de la cause dans votre configuration.

C’est pourquoi un dépassement de 43 ne justifie pas de supprimer exactement 43 caractères. Claude Code envoie aussi des instructions système, l’historique, les définitions d’outils, le contenu des fichiers et les résultats. Laissez une marge importante au lieu d’essayer de vous placer juste sous la frontière.

Branche A : /compact fonctionne encore

Si les slash commands répondent, mesurez l’occupation puis indiquez précisément ce que le résumé doit conserver.

/context

Lancez ensuite un compactage ciblé :

/compact Conserve l’objectif actuel, les fichiers modifiés, les résultats vérifiés, les décisions importantes, le problème restant et la prochaine action. Supprime les logs complets, les contenus de fichiers répétés, les pistes abandonnées et les discussions sans rapport.

Après un compactage réussi, ne rescanez pas immédiatement tout le dépôt. Testez la reprise avec une demande courte et observable :

Lis uniquement RECOVERY.md et src/auth/session.ts. Indique quelle fonction doit être modifiée ensuite. Ne parcours pas les autres répertoires et ne modifie aucun fichier.

La reprise est crédible lorsque quatre signaux sont réunis :

1. /context affiche une occupation nettement plus basse ;
2. une petite requête ne renvoie plus 400 ;
3. le modèle restitue correctement l’objectif, les fichiers modifiés et l’étape suivante ;
4. git diff et les tests restent cohérents avec la note de reprise.

Le compactage peut perdre des détails. Placez les règles durables dans le CLAUDE.md du projet et l’état critique dans des fichiers plutôt que de tout confier à une très longue conversation.

Branche B : /compact renvoie aussi Conversation too long ou le même 400

Ne relancez pas /compact en boucle sur le même historique déjà trop grand. Dans Claude Code #26317, un utilisateur rapporte qu’après avoir atteint la limite, la commande de compactage répond elle-même Conversation too long. La fermeture de l’issue avec le statut not planned ne signifie pas que toutes les versions et tous les endpoints compatibles ont éliminé ce comportement.

Revenez avant le gros log ou le tool output volumineux

La documentation officielle sur le checkpointing permet d’utiliser /rewind, ou d’appuyer deux fois sur Esc lorsque le champ de saisie est vide. Les choix comprennent notamment :

• Restore conversation : revenir en arrière dans le dialogue en gardant le code actuel ;
• Summarize from here : résumer les messages postérieurs au checkpoint ;
• Summarize up to here : résumer l’historique antérieur tout en conservant la fin.

Choisissez un checkpoint situé avant la lecture d’un fichier massif, le collage d’un log complet ou un résultat d’outil anormalement grand. Revenir dans le dialogue tout en gardant le code, puis envoyer une tâche beaucoup plus étroite, est souvent plus sûr que de résumer la fin déjà saturée.

Une opération de résumé peut encore appeler le modèle. Si l’upstream refuse également cette requête, passez à une reprise avec contexte vide.

Si le retour arrière échoue, utilisez /clear ou une nouvelle session

/clear

La référence officielle des commandes précise que /clear démarre une conversation vide tout en conservant la session précédente. La commande n’annule pas les fichiers écrits et ne supprime pas le Git diff.

Commencez la session neuve avec une instruction strictement bornée :

Lis RECOVERY.md, git diff --stat et les deux fichiers qui y sont indiqués. Vérifie d’abord l’état actuel. Ne parcours pas tout le dépôt. Propose uniquement l’étape suivante et attends une validation avant toute modification.

N’exécutez pas immédiatement claude --continue, claude --resume ou /resume. Selon la documentation officielle des sessions, une reprise restaure tout l’historique et les résultats d’outils. Si cet historique provoquait le dépassement, l’appel suivant peut échouer à nouveau.

Localisez la couche de rejet avec quatre tests simples

Une fois le travail sécurisé, modifiez une seule variable à la fois et réutilisez la même petite tâche en lecture seule.

Test	Résultat	Interprétation la plus utile
Même endpoint et même modèle, session neuve, petite tâche	Réussite	L’historique accumulé ou un tool output volumineux est probable
La même petite tâche échoue dans une session neuve	Échec	Vérifiez model mapping, enveloppe de requête, version du client ou cap serveur
Si autorisé, comparez l’endpoint officiel et la passerelle	Direct réussi, gateway en échec	Inspectez limites, conversion et agrégation des erreurs de la passerelle
/compact échoue mais une petite tâche après /clear réussit	Réussite	La requête de compactage dépassait la vraie fenêtre ou le client estimait mal celle-ci

Enregistrez les valeurs de routage sans exposer de secret :

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>}"

La commande n’affiche volontairement pas ANTHROPIC_AUTH_TOKEN. Notez aussi le passage éventuel par Claude Code Router, un switcher, une passerelle d’entreprise, un reverse proxy ou un fallback multi-fournisseurs.

Dans Claude Code Router #1799, un utilisateur rapporte qu’une passerelle remplaçait une erreur de contexte upstream par All target providers failed. Son patch local n’est pas une correction universelle, mais le cas montre pourquoi les logs de support doivent conserver le status, le body et le request ID de l’upstream.

Vérifiez la route DeepSeek réelle, pas seulement l’étiquette [1m]

Au 30 septembre 2026, l’exemple de variables d’environnement côté client de la page officielle d’intégration de DeepSeek avec Claude Code configure :

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

La même page documente séparément un mappage côté service pour les noms de modèles au format Claude : ceux qui commencent par claude-opus sont associés à deepseek-v4-pro, tandis que ceux qui commencent par claude-haiku ou claude-sonnet sont associés à deepseek-flash. Cette règle côté service et les valeurs explicites de l’exemple client sont deux faits distincts ; il ne faut pas les fusionner en une seule conclusion sur la route réelle.

Aucune de ces deux sections n’établit quel modèle ou quelle fenêtre a traité cette requête précise. Vérifiez les journaux de request/usage disponibles, le champ model d’origine, le provider ou la route sélectionnés et le request ID upstream, plutôt que de l’inférer depuis l’interface ou un ancien tutoriel.

L’étiquette [1m] ne garantit pas non plus que toutes les couches acceptent un million de tokens. Claude Code, l’API compatible, la passerelle, le fournisseur de fallback et le modèle final peuvent appliquer des limites distinctes. La sortie réservée utilise aussi une partie de la fenêtre.

Compactez plus tôt au lieu de gonfler la fenêtre

L’exemple DeepSeek actuel contient :

export CLAUDE_CODE_AUTO_COMPACT_WINDOW="786432"

Il s’agit d’un seuil de compactage côté client, pas d’un moyen d’agrandir la limite dure du fournisseur. La référence des variables d’environnement de Claude Code précise que la valeur est un entier, qu’elle reste plafonnée par la fenêtre du modèle et qu’elle prend le pas sur /autocompact, les flags de lancement et les settings.

Si le modèle ou la passerelle accepte moins, utilisez une valeur plus basse que vous avez vérifiée. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE permet de déclencher le compactage plus tôt, pas d’augmenter la limite.

Ne traitez pas CLAUDE_CODE_MAX_CONTEXT_TOKENS comme un bouton pour « débloquer » du contexte. Cette variable indique à Claude Code la taille réelle et vérifiée d’une route personnalisée ou non reconnue. Une valeur supérieure au cap serveur repousse le compactage et augmente le risque d’un nouveau 400.

Quelques habitudes sont souvent plus efficaces :

• filtrez les gros logs avec grep, rg, tail ou un script ;
• lisez les gros fichiers par fonction ou plage de lignes ;
• utilisez /clear entre deux tâches sans rapport ;
• confiez les explorations larges à un subagent et ne remontez qu’un résumé ;
• lancez un /compact ciblé avant une nouvelle phase, pas aux derniers tokens ;
• évitez de répéter schemas, build logs complets et diffs entiers.

Retestez avec une petite tâche réelle

Après la reprise ou une modification de configuration :

1. ouvrez une session neuve ;
2. lisez seulement RECOVERY.md et un petit fichier ;
3. demandez une réponse courte et bornée ;
4. confirmez que le 400 a disparu ;
5. ajoutez progressivement fichiers et tool calls.

Si même la tâche minimale échoue, arrêtez de réduire l’ancienne conversation et examinez l’endpoint, le model mapping, le proxy et le format de requête. Si seule la longue session échoue, concentrez-vous sur le moment du compactage, le volume des résultats et la séparation des tâches.

Questions fréquentes

Pourquoi le redémarrage de Claude Code n’a-t-il rien changé ?

Redémarrer ne signifie pas forcément repartir sans historique. --continue, --resume et le sélecteur de sessions restaurent l’ancienne conversation. Pour isoler la cause, créez une session réellement neuve et utilisez une petite requête témoin.

Réduire les output tokens suffit-il ?

Seulement si l’erreur indique explicitement que l’entrée et max_tokens dépassent ensemble le budget. Si l’entrée possède sa propre limite, réduire la sortie ne garantit rien.

Changer de gateway résout-il toujours le problème ?

Non. Cela peut aider si la passerelle actuelle impose un body limit plus faible ou masque les erreurs upstream. Aucune passerelle ne peut dépasser la limite dure du modèle final.

/clear supprime-t-il le code ?

Non. Il vide le contexte de conversation, pas les fichiers déjà écrits. Vérifiez tout de même git status et sauvegardez un patch, un commit ou un snapshot avant de l’utiliser.

Pourquoi ne pas retirer exactement 43 caractères ?

Parce que l’unité n’est pas indiquée et que la requête contient des données invisibles : instructions système, tools et historique. Une marge suffisante est plus fiable qu’un ajustement à la frontière exacte.

La séquence de reprise à retenir

Pour Input length exceeds maximum, suivez cet ordre : sauvegardez le diff et une note manuelle dans un autre terminal → exécutez /context → tentez un /compact ciblé → s’il échoue, utilisez /rewind avant le gros output → si cela échoue aussi, faites /clear ou ouvrez une nouvelle session → utilisez une petite tâche pour localiser la limite → placez le compactage sous la fenêtre serveur vérifiée.

Cette méthode n’a pas besoin de deviner ce que représente le nombre 43 et ne promet pas qu’un proxy dépassera la limite dure du modèle. Elle protège d’abord le travail existant, puis transforme un 400 vague en diagnostic reproductible, couche par couche.