Comment changer le modèle par défaut dans Claude Code (et les nouveaux hooks de changement de modèle dans 2.1.251)

Définir votre modèle par défaut de Claude Code avec /model

La distinction essentielle est celle entre l’enregistrement d’une préférence et un changement temporaire de modèle. Au 29 août 2026, /model prenait déjà en charge les deux méthodes.

La version 2.1.153 a modifié /model afin qu’une sélection soit enregistrée comme modèle par défaut pour les nouvelles sessions. Ce comportement est antérieur à 2.1.251 : la version d’août a introduit les hooks de changement de modèle, et non la possibilité de mémoriser une sélection interactive de modèle.

Le journal des modifications rattaché à une version précise constitue la référence historique pour cette distinction. Il consigne à la fois le comportement de sélection persistante et l’action du sélecteur permettant un changement temporaire.

Enregistrer une préférence pour les futures sessions

Utilisez le sélecteur de modèle :

/model

Sélectionnez le modèle que vous souhaitez utiliser par défaut. Le comportement de persistance introduit dans 2.1.153 signifie que cette sélection est enregistrée pour les nouvelles sessions.

C’est la réponse la plus claire étayée par l’historique à la question « Comment conserver mon modèle préféré ? ». Elle ne nécessite pas de présenter une fonctionnalité introduite dans une version antérieure comme une nouvelle capacité de 2.1.251.

Changer de modèle uniquement pour la session en cours

Appuyez sur s dans le sélecteur pour changer de modèle uniquement pour la session en cours. Utilisez cette action lorsque la sélection doit être temporaire.

Cette distinction est importante lorsque vous suivez d’anciennes instructions ou conservez des raccourcis clavier personnalisés. L’ancienne action du sélecteur d est devenue s, et le raccourci clavier personnalisé associé est passé de modelPicker:setAsDefault à modelPicker:thisSessionOnly.

Pour un contexte plus général sur la sélection des modèles, consultez le guide des modèles Claude Code. Le point propre à cette version est simple : une sélection ordinaire enregistre un modèle par défaut, tandis que l’action limitée à la session permet un changement temporaire.

Fichiers de configuration, ANTHROPIC_MODEL et options de remplacement au démarrage

La configuration du modèle peut également passer par un fichier de paramètres, une variable d’environnement ou une option de démarrage. Toutefois, les recherches fournies établissent une limite historique : leur documentation exacte et leur ordre de priorité n’ont pas été vérifiés indépendamment dans une version archivée disponible au 29 août 2026.

Le documentation sur la configuration des modèles et documentation sur les paramètres décrivent ces méthodes, mais ces pages contiennent des mises à jour ultérieures. Elles ne permettent pas d’établir tous les détails du comportement à la date limite retenue pour cet article.

Le tableau suivant distingue les options documentées de ce que les éléments datés permettent d’établir.

Quel paramètre est prioritaire ?

Les recherches fournies font état d’une documentation plaçant l’option de démarrage au-dessus de ANTHROPIC_MODEL, et la variable d’environnement au-dessus de la valeur du fichier de paramètres model . Elles indiquent aussi explicitement que cet ordre n’a pas été vérifié pour la date limite de publication.

Par conséquent, cet article ne présente pas cet ordre de priorité comme un fait établi en août 29. Le changement de /model persistance s’appuie sur une entrée datée du journal des modifications ; la hiérarchie précise de configuration ne dispose pas d’un tel repère.

Qu’en est-il d’un modèle par défaut pour un seul projet ?

Les recherches recensent dans la documentation des fichiers de paramètres utilisateur, de projet et de projet personnels. Elles ne permettent pas d’établir leur formulation historique exacte ni le comportement du paramètre de modèle à partir d’une version archivée antérieure à la date limite.

La réponse est donc plus limitée qu’un tutoriel de configuration de projet : /model la persistance est confirmée, tandis que les instructions concernant les fichiers propres à un projet nécessitent une vérification historique. La référence de la CLI constitue un complément utile pour la configuration en ligne de commande, mais elle ne lève pas les limites des éléments probants de cet article.

Ce qu’apportent les hooks de changement de modèle dans 2.1.251

Claude Code 2.1.251 est sorti le 28 août 2026. Ses notes de version officielles présentent deux hooks portant les noms exacts suivants :

• PreModelSwitch
• PostModelSwitch

La version décrit leurs capacités comme permettant de bloquer, de confirmer ou d’annoter un changement de modèle. Ces hooks enrichissent le processus de sélection du modèle avec des contrôles autour du changement.

C’est cette nouvelle fonctionnalité qu’il faut distinguer de la persistance du modèle par défaut. L’enregistrement d’une préférence de modèle était déjà disponible ; les nouveaux événements de hook ajoutent des moyens d’intervenir dans un changement de modèle.

Un hook peut-il bloquer un changement ou demander une confirmation ?

Oui, le blocage et la confirmation sont des capacités explicitement mentionnées dans l’annonce de la version. L’annotation y figure également.

L’annonce ne fournit pas les schémas complets d’entrée et de sortie, les règles de correspondance ni les JSON de décision. Elle permet donc de décrire ces capacités, mais pas de publier une configuration exécutable sur la seule base de cette annonce.

La même limite s’applique à des détails tels que les champs de la charge utile qui identifient l’ancien et le nouveau modèle, ou la structure requise pour une réponse de confirmation. Ces détails sont absents des éléments fournis antérieurs à la date limite.

Que faut-il avant d’en implémenter un ?

Une implémentation fonctionnelle nécessite plus que les noms des événements : elle exige le format de configuration applicable et le contrat de réponse pris en charge. Les notes de version ne fournissent pas ces éléments.

Consultez le guide des hooks Claude Code pour un contexte plus général sur les hooks. Pour cette version, décrivez précisément ce qui est confirmé : PreModelSwitch et PostModelSwitch existent, et l’annonce décrit des capacités de blocage, de confirmation et d’annotation.

Examiner le comportement du cache de prompts et les coûts de reprise

La version 2.1.251 ajoute également des diagnostics qui aident à expliquer le comportement du cache de prompts. Ces ajouts rendent visibles l’activité du cache et le coût estimé de sa reconstruction ; la version n’annonce ni nouveaux tarifs de tokens ni limites chiffrées du cache.

Lire la nouvelle ligne du cache dans /cost

La commande existante gagne une ligne consacrée au cache de prompts pour chaque session :

/cost

Cette ligne indique quatre éléments :

• Taux de succès
• Échecs
• Tokens remis en cache
• État chaud ou froid

Ensemble, ces éléments offrent une vue du cache plus détaillée qu’un simple montant de coût. Ils distinguent les accès réussis des échecs du cache et indiquent combien de tokens ont été remis en cache.

Les scripts de la ligne d’état disposent également d’un objet correspondant prompt_cache . Les diagnostics du cache sont ainsi disponibles dans l’interface de la ligne d’état, ainsi que via /cost.

L’annonce ne fournit pas de schéma complet pour cet objet. Considérez prompt_cache comme un nom d’objet confirmé, sans supposer l’existence de champs supplémentaires au-delà des diagnostics décrits dans cette version.

Examiner les informations de reprise via SessionStart

Lors de la reprise, SessionStart les hooks reçoivent désormais l’ancienneté de la session et le coût estimé de reconstruction du cache de prompts.

Cela se distingue de l’affichage /cost : l’ajout lié à la reprise fournit des informations aux hooks, tandis que la commande présente des diagnostics du cache par session. Les deux ajouts concernent la visibilité du cache, mais exposent ces informations via des interfaces différentes.

Les notes de version ne donnent pas les noms exacts des clés de la charge utile pour l’ancienneté de la session ou le coût estimé de reconstruction. Un exemple de hook qui présumerait ces noms irait au-delà des éléments disponibles.

D’autres valeurs de modèle par défaut et diagnostics ont changé

Plusieurs changements connexes dans 2.1.251 sont importants pour interpréter la notion de « modèle par défaut ». Ils concernent les sous-agents, les valeurs par défaut du compte, les préférences d’effort et la visibilité des dépenses de la passerelle.

Priorité des modèles de sous-agents

CLAUDE_CODE_SUBAGENT_MODEL fournit désormais une valeur par défaut. La valeur model: dans la définition d’un agent et un modèle explicitement sélectionné lors du lancement d’un agent ont priorité sur cette variable.

Il s’agit d’un changement de priorité confirmé dans le journal des modifications de la version étiquetée. Il faut le distinguer de l’ordre de priorité historique non vérifié entre l’option de démarrage du modèle principal, la variable d’environnement et la valeur du fichier de paramètres.

Lorsque vous examinez la sélection du modèle d’un sous-agent, tenez compte de ces choix explicites avant de considérer la variable d’environnement comme déterminante. Le guide des sous-agents fournit un contexte plus large sur la configuration des agents.

Valeurs par défaut du compte et préférences d’effort

Les abonnements Enterprise facturés par utilisateur utilisent désormais Opus 5 par défaut, comme les autres offres premium.

Ce changement au niveau du compte est distinct d’une préférence de modèle enregistrée via /model. La version modifie également la persistance de /effort : un niveau d’effort par défaut distinct est désormais enregistré pour chaque modèle.

En pratique, la sélection du modèle et la persistance de l’effort sont des paramètres distincts. Le nouveau comportement mémorise un effort par défaut pour chaque modèle, au lieu de définir un effort par défaut commun.

Visibilité des dépenses de la passerelle

Le /usage La commande dispose désormais d’une barre Limite de dépenses pour les développeurs utilisant une passerelle d’applications Claude avec des limites de dépenses :

/usage

Les scripts de ligne d’état disposent du champ correspondant rate_limits.spend_limit . Il s’agit d’un ajout aux diagnostics pour ce contexte de passerelle.

Le journal des modifications n’annonce aucun plafond universel en dollars. La présence d’un affichage de limite de dépenses ne doit donc pas être interprétée comme une limite fixe applicable à tous les utilisateurs de Claude Code.

Points clés

• /model enregistrait déjà une valeur par défaut pour les nouvelles sessions avant 2.1.251 ; ce comportement remonte à 2.1.153.
• Appuyez sur s dans le sélecteur de modèles pour un changement limité à la session en cours. Les raccourcis clavier personnalisés utilisent modelPicker:thisSessionOnly.
• Claude Code 2.1.251 ajoute PreModelSwitch et PostModelSwitch, avec des fonctions de blocage, de confirmation et d’annotation décrites dans les notes de version.
• /cost, les données de cache de la ligne d’état et les informations de SessionStart lors de la reprise offrent une meilleure visibilité sur l’activité du cache de prompts et les coûts estimés de reconstruction.
• CLAUDE_CODE_SUBAGENT_MODEL fournit une valeur par défaut que des choix explicites de modèle d’agent peuvent remplacer. L’ordre de priorité historique exact de la configuration du modèle principal reste non vérifié dans les recherches fournies.

FAQ

/model enregistre-t-il le modèle par défaut dans Claude Code ?

Oui. La version 2.1.153 a modifié /model pour qu’une sélection soit enregistrée comme valeur par défaut pour les nouvelles sessions, et ce comportement existait déjà avant 2.1.251. Appuyez sur s dans le sélecteur lorsque vous souhaitez changer de modèle uniquement pour la session en cours.

Quel élément a priorité : settings.json, ANTHROPIC_MODEL ou --model ?

Les recherches fournies font état d’une documentation plaçant l’option de démarrage au-dessus de ANTHROPIC_MODEL, et cette variable au-dessus de la valeur du modèle dans le fichier de paramètres. Toutefois, l’ordre exact n’a pas été vérifié de manière indépendante dans un instantané antérieur à août 29, 2026 ; cet article ne l’établit donc pas comme un comportement propre à cette date de référence.

Un hook de changement de modèle de Claude Code peut-il bloquer un changement ?

La version 2.1.251 décrit PreModelSwitch et PostModelSwitch comme permettant le blocage, la confirmation et l’annotation des changements de modèle. Elle ne fournit pas de schémas complets ni de JSON de décision ; l’annonce seule ne suffit donc pas à créer une implémentation de hook exécutable.

Où puis-je consulter les défauts de cache et les coûts estimés de reconstruction ?

Dans 2.1.251, /cost indique, pour chaque session, le taux de succès du cache, les défauts de cache, les tokens remis en cache et l’état chaud ou froid ; les scripts de ligne d’état disposent d’un objet correspondant prompt_cache . Par ailleurs, les hooks SessionStart reçoivent, lors de la reprise, l’ancienneté de la session et le coût estimé de reconstruction du cache de prompts, bien que les notes de version ne précisent pas les noms de ces clés dans la charge utile.