Classificateur côté serveur en mode Auto de Claude Code : facturation, passerelles et logique de repli

Si votre terminal s’interrompt pendant l’exécution d’une commande en mode Auto après avoir mis à jour Claude Code et affiche l’avertissement suivant :

We're changing auto mode to no longer charge for classifier requests in Claude Code. However, this session isn't eligible.

cela signifie que le client a tenté d’activer la nouvelle validation de sécurité côté serveur sans surcoût, mais que des contraintes d’infrastructure ont empêché son application à votre session active.

En mode Auto, un classificateur examine les actions potentiellement sensibles — telles que les exécutions Bash, les commandes système et les appels réseau sortants — avant leur exécution effective. Avant la version v2.1.278, ces vérifications étaient effectuées par le biais de requêtes distinctes côté client, qui consommaient des jetons facturables. À partir de la version v2.1.278, la validation est déléguée par défaut aux serveurs d’Anthropic et des plateformes cloud : les vérifications s’exécutent désormais directement au sein des requêtes principales du modèle, sans frais supplémentaires.

Lorsque la validation côté serveur est indisponible, Claude Code continue de vérifier les actions par des requêtes de classification côté client. Ces requêtes de repli (fallback) sont facturées au tarif standard des jetons, comme auparavant ; l’avertissement indique simplement que la validation s’effectue par des requêtes de classification côté client facturables, et non que les contrôles de sécurité sont désactivés.

---

Répondre à l’avertissement : Entrée vs Échap / Ctrl+C

Lorsque les vérifications côté serveur sont indisponibles, Claude Code suspend l’exécution avant d’exécuter la première commande nécessitant une validation et attend votre réponse :

• Appuyer sur Entrée : approuve la commande en attente. La session se poursuit en mode Auto en utilisant les vérifications du classificateur côté client, facturées au tarif standard des jetons. Si une passerelle intermédiaire ou un proxy a été explicitement identifié dans l’invite, cette confirmation est mise en cache sur la machine locale pendant 24 heures. Si aucun nom de passerelle n’a été identifié, l’invite réapparaîtra lors du prochain repli de session.
• Appuyer sur Échap ou Ctrl+C : interrompt immédiatement l’action en attente et termine le tour actif (turn). La session reste en mode Auto, aucune confirmation n’est enregistrée et l’invite réapparaîtra lors de la prochaine commande nécessitant une validation.
• Changer de mode : appuyez sur Shift+Tab pour quitter totalement le mode Auto. Désactiver les politiques de sécurité ou les protections du bac à sable (sandbox) pour éviter des frais de jetons est fortement déconseillé.

Dans les environnements non interactifs, Claude Code adapte son comportement à l’automatisation :

• En mode headless (-p), la notification est redirigée vers stderr tandis que l’exécution se poursuit.
• En mode stream-json, le client émet un événement d’avertissement system dans le flux de messages (exploitable via l’Agent SDK).
• Dans l’extension VS Code, la notification s’affiche sous la forme d’une bannière informative dans l’interface de discussion et ne nécessite aucune confirmation au clavier.

---

Diagnostic de session : la commande /status et la logique de repli

Pour vérifier la manière dont le mode Auto gère actuellement les contrôles de sécurité, exécutez la commande d’état intégrée :

/status

Recherchez la ligne Auto mode server dans la sortie :

• Enabled : la validation de sécurité s’exécute sur le serveur. Aucun frais de jeton supplémentaire lié au classificateur ne s’applique.
• Disabled : la session a basculé vers le classificateur côté client. Les requêtes de sécurité sont envoyées par le client et facturées comme une consommation normale de jetons.

Pannes isolées vs repli au niveau de la session

Il convient de distinguer un simple incident réseau ponctuel d’un repli persistant au niveau de la session :

1. Action ponctuelle : si le serveur ne parvient pas à valider une opération isolée, Claude Code effectue une unique vérification côté client et tente à nouveau la validation côté serveur lors de la requête suivante. Aucun avertissement de session n’est affiché dans ce cas.
2. Repli de session : l’invite à l’écran n’apparaît que lorsque les vérifications côté serveur échouent pour l’ensemble de la session (ce qui peut survenir dès la première commande validée).

---

Disponibilité des plateformes, déploiement régional et exceptions

La validation côté serveur est activée par défaut dans Claude Code v2.1.278 et versions ultérieures pour :

• Les comptes Claude API et Enterprise ;
• Claude Platform on AWS, Amazon Bedrock, Google Cloud Agent Platform (Vertex) et Microsoft Foundry ;
• Les proxys et passerelles compatibles.

Règles de disponibilité et contraintes clés :

• Forfaits Pro, Max et Team : les abonnés à ces offres individuelles et d’équipe ne voient jamais cet avertissement.
• Restrictions des modèles cloud : sur Amazon Bedrock, Google Cloud Vertex et Microsoft Foundry, le mode Auto dans son ensemble n’est pris en charge que pour Claude Sonnet 5, Opus 4.7 et versions plus récentes, ainsi que pour les modèles de la famille Fable.
• Déploiement progressif : la disponibilité de la validation côté serveur dépend de la plateforme, de la région et des identifiants. Si votre réseau ne passe par aucun proxy ni aucune passerelle d’entreprise et que /status indique pourtant Disabled, l’une des causes possibles est que la validation ne soit pas encore disponible pour cette configuration. Renseignez-vous auprès de votre administrateur ou signalez-le via /feedback.

---

Le défi des passerelles : transmission transparente et variable CLAUDE_CODE_AUTO_MODE_SERVER

Le déclencheur le plus fréquent de cet avertissement est une passerelle LLM d’entreprise ou un proxy (tel qu’un routeur de modèles ou un équilibreur de charge) qui supprime ou modifie le trafic entre le client et l’API en amont.

Exigences pour les passerelles

La validation sur serveur nécessite un transfert transparent des métadonnées de bout en bout. Pour permettre des vérifications gratuites sur le serveur à travers une passerelle, les administrateurs doivent configurer des règles de transmission transparente (pass-through) :

• Transmettre l’ensemble des en-têtes et des paramètres du corps de requête sans modification, y compris les champs de sécurité (en particulier le champ safeguards) ;
• Renvoyer les réponses et les événements de streaming sans supprimer les clés non reconnues (en particulier la charge utile safeguard_results) ;
• Préserver les identifiants d’exécution d’outils d’origine (tool_use_id) sans les altérer au niveau du proxy.

Variable de désactivation temporaire et compromis

Si votre passerelle d’entreprise ne peut pas transmettre ces champs de métadonnées et ne peut pas être mise à jour immédiatement, vous pouvez masquer l’invite bloquante :

export CLAUDE_CODE_AUTO_MODE_SERVER=0

Points clés à comprendre concernant cette variable d’environnement :

• Le compromis : définir cette variable indique à Claude Code de ne pas solliciter de vérifications côté serveur sur les routes Bedrock, Vertex, Foundry ou via des passerelles. L’invite d’avertissement est supprimée, mais les vérifications du classificateur s’exécutent alors sous forme de requêtes côté client facturables.
• Ignorée sur les connexions directes : cette variable n’est pas lue et est totalement ignorée lors d’une connexion directe à l’API officielle d’Anthropic.
• Définir CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 produit le même effet lorsque CLAUDE_CODE_AUTO_MODE_SERVER n’est pas défini.
• Ce paramètre est temporaire et pourrait être déprécié ou supprimé dans les prochaines versions de Claude Code.

---

Diagnostic des coûts : chronologie des événements et véritables facteurs de dépenses

De nombreuses hypothèses ont circulé au sujet de la consommation de jetons en mode Auto et des erreurs HTTP 429. Une évaluation précise des coûts nécessite de croiser la chronologie des versions officielles et les journaux bruts, plutôt que de se fier à des suppositions.

Pour obtenir les détails officiels sur les invites, le repli de facturation et la configuration des passerelles, consultez la documentation officielle de Claude Code.

Chronologie des événements

timeline
    title Évolution du mécanisme de vérifications du mode Auto
    2026-09-08 : Incident historique #93558 : Échec 429 spécifique sur les versions 2.1.263–2.1.267 en raison de l'en-tête d'attribution
    2026-09-19 : Publication officielle v2.1.278 : Classificateur côté serveur par défaut, indicateur dans /status, avertissement de repli
    2026-09 : Discussion sur Reddit : Signalement d'une dépense de $50/hour dans des cycles GitOps sans isolation des causes

1. 8–9 septembre 2026 (incident historique sur les anciennes versions) : le rapport d’anomalie #93558 a documenté des défaillances sur les versions clientes 2.1.263–2.1.267. En combinant une passerelle personnalisée avec CLAUDE_CODE_ATTRIBUTION_HEADER=0, le client recevait une suite de 15 réponses HTTP 429 vides lors des vérifications du classificateur, bloquant ainsi les commandes Bash. La suppression de la variable a résolu le problème. L’ancien client ne rétablissait les en-têtes d’attribution que pour l’hôte par défaut api.anthropic.com, en les omettant sur les points de terminaison personnalisés.
   • Remarque : ce problème était propre aux anciennes versions du client. Le rapport ne contient aucun élément indiquant qu’il se reproduit dans la v2.1.278, et tous les codes d’état 429 ne sont pas dus au comportement de l’en-tête d’attribution.
2. 19 septembre 2026 (version v2.1.278) : publication officielle établissant la classification côté serveur par défaut sur les plateformes prises en charge, ajoutant le champ Auto mode server à /status et introduisant la boîte de dialogue d’avertissement de repli facturé.
3. Discussion sur Reddit concernant une dépense de 50 $/heure : un utilisateur a signalé une dépense d’environ 50 $ par heure lors d’exécutions prolongées d’automatisation GitOps (Ansible, OpenTofu) sur Opus 5-high. L’utilisateur a supposé que le classificateur du mode Auto transmettait l’intégralité de l’historique de conversation à chaque commande. Le fil de discussion n’apportait aucun décompte corroborant de jetons.

Pourquoi les coûts du classificateur doivent être audités via les journaux

Attribuer directement une facture de 50 $/heure au surcoût du classificateur sans données de journalisation ne repose sur aucune preuve :

• Bien que l’auteur du message sur Reddit ait collecté les fichiers de session au format JSONL, il n’a pas procédé à une ventilation détaillée des coûts par composant pour isoler les jetons du classificateur de l’inférence du modèle principal. Les véritables facteurs de dépenses au cours de cette session restent non vérifiés.
• Les affirmations sur les forums évoquant des modifications tarifaires non annoncées de la mise en cache par Anthropic relèvent de la spéculation des utilisateurs et non d’un changement de politique avéré.
• La documentation confirme que les vérifications serveur n’engendrent aucune facturation supplémentaire, tandis que les requêtes de repli côté client sont facturées au tarif standard des jetons, comme par le passé. Le signalement isolé d’un utilisateur ne suffit pas à quantifier le surcoût du classificateur.
• Dans les flux de travail GitOps, les inventaires/listes OpenTofu et les sorties volumineuses d’Ansible peuvent contribuer au contexte du modèle principal. Ce point doit être audité directement dans les journaux de session avant d’en imputer la cause au classificateur.

---

Procédure pratique de dépannage pour les ingénieurs

Si vous constatez une consommation inattendue de jetons ou si l’avertissement de repli apparaît, suivez cette liste de contrôle diagnostique :

1. Vérifiez votre version : assurez-vous d’utiliser Claude Code en version 2.1.278 ou ultérieure (claude --version).
2. Vérifiez l’état de votre session : exécutez /status et repérez la ligne Auto mode server.
   • Si Enabled : le classificateur fonctionne côté serveur sans frais supplémentaires de jetons.
   • Si Disabled : la session a basculé vers des vérifications facturables côté client.
3. Isolez la cause première du repli :
   • Derrière une passerelle intermédiaire : examinez les journaux du proxy pour déterminer si les champs safeguards ou safeguard_results sont supprimés, ou si les valeurs tool_use_id sont modifiées. Si la passerelle ne peut pas être mise à jour immédiatement, utilisez export CLAUDE_CODE_AUTO_MODE_SERVER=0 comme solution de contournement temporaire.
   • Connexion directe à l’API : le déploiement de la validation serveur est peut-être encore en cours pour votre région ou votre niveau de compte. Vérifiez auprès de votre administrateur ou envoyez vos commentaires via /feedback.
4. Auditez les dépenses à l’aide des journaux JSONL :
   • Ouvrez le fichier de transcription de session (.jsonl) ;
   • Décomposez le décompte des jetons (input_tokens, cache_read_input_tokens, output_tokens) par type de requête ;
   • Séparez les appels du classificateur de sécurité des requêtes du modèle principal (Opus/Sonnet) ;
   • Évaluez l’impact d’une sortie de terminal verbeuse sur la fenêtre de contexte cumulative.
5. Maintenez les exigences de sécurité : ne désactivez jamais les garde-fous de sécurité ni les limites d’autorisations pour tenter de réduire les coûts de jetons.