Modèles, utilisation et limites dans Claude Code

Ce guide explique quel modèle vous utilisez, comment l'utilisation est mesurée et comment maintenir les sessions longues dans leurs limites de contexte et d'utilisation.

La façon dont vous vous êtes connecté détermine comment l'utilisation est mesurée. Tout le reste du fonctionnement de Claude Code se comporte de la même manière, indépendamment de cela.

Si vous vous êtes connecté avec un siège Enterprise, vous n'avez généralement pas besoin de penser aux jetons jusqu'à atteindre une limite. Si vous utilisez une clé API, la commande /cost affiche vos dépenses en cours pour la session actuelle.

Exécutez /model à tout moment pour voir quels modèles sont disponibles pour votre compte et pour basculer entre eux. À titre indicatif :

Vous pouvez changer de modèle en cours de session sans perdre votre conversation. Un modèle courant est de planifier avec Opus et d'exécuter avec Sonnet.

Chaque tour envoie trois choses au modèle :

Parmi ceux-ci, le premier élément croît le plus rapidement. Une longue session de débogage au cours de laquelle Claude a lu vingt fichiers et produit quinze diffs porte tout cela sur chaque message ultérieur. C'est là que proviennent à la fois le coût et les limites de contexte.

La fenêtre de contexte est la quantité maximale de texte que le modèle peut considérer à la fois. Claude Code affiche un indicateur en direct de son remplissage. Quand elle se remplit, Claude ne peut plus voir clairement les parties les plus anciennes de la conversation et la qualité diminue.

Deux commandes la maintiennent sous contrôle :

Règle générale : utilisez /clear au démarrage d'une nouvelle tâche, et /compact lors de la continuation d'une tâche longue.

Presque tous les rapports « J'ai épuisé ma limite avant midi » remontent à l'un de ces cinq.

Chaque message précédent est renvoyé à chaque tour, donc une session qui a traversé trois problèmes non liés paie pour les trois à chaque nouveau message. En pratique : vous venez de terminer le débogage d'une redirection de connexion et vous voulez maintenant écrire une migration de base de données. Exécutez d'abord /clear. Un test simple : si votre prochain message aurait un sens parfait dans un terminal tout neuf, effacez avant de l'envoyer. Votre CLAUDE.md et les fichiers du projet restent en place ; seul l'historique de chat disparaît. Un avertissement : /clear ne peut pas être annulé. Si vous pourriez encore avoir besoin de quelque chose de l'historique, copiez-le d'abord ou exécutez /compact à la place, qui préserve un résumé plutôt que d'effacer tout.

Opus coûte plusieurs fois plus par tour que Sonnet, et Sonnet plus que Haiku. Dépenser Opus sur du travail de routine est le moyen le plus rapide d'épuiser une limite quotidienne. Valeurs par défaut raisonnables : Sonnet pour la plupart des codages (fonctionnalités, tests, bogues connus, refactorisations) ; Opus quand vous êtes vraiment bloqué ou que le changement est large (débogage difficile, refactorisations transversales, appels architecturaux) ; Haiku pour le travail mécanique rapide (renommages, lignes de journal, explications regex, code passe-partout).

Tout ce que vous collez reste en contexte, en intégralité, pour le reste de la session. Référencer un fichier par chemin permet à Claude de lire sélectivement et de se concentrer sur la partie qui vous intéresse. En pratique : au lieu de coller auth.ts, écrivez look at the validateToken function in @src/auth.ts. Pour les journaux et les traces de pile, réduisez aux 20 ou 30 lignes pertinentes avant de coller. Pour tout ce qui est volumineux (fichiers de verrouillage, journaux de compilation, vidages de données), mettez-le sur disque et référencez le chemin.

Ce fichier est ajouté au début de chaque tour, donc son coût est multiplié par le nombre de messages que vous envoyez. Un CLAUDE.md de 300 lignes sur une session de 40 tours représente 12 000 lignes d'entrée que vous avez payées avant de faire du travail. La règle : deux grèves, un écran. N'ajoutez une note que la deuxième fois que vous devez corriger Claude sur la même chose (les problèmes de première fois sont généralement des cas isolés). Et ne laissez jamais le fichier dépasser un seul écran d'environ 80 à 100 lignes ; si quelque chose de nouveau doit y entrer et qu'il n'y a pas de place, quelque chose d'ancien doit sortir. Quand le mettre à jour : juste après une session où vous avez dû corriger Claude deux fois sur la même chose. C'est quand la correction est fraîche et prend une minute à noter. Tous les quelques semaines, lisez le fichier entier et supprimez tout ce qui n'est plus vrai ou dont vous ne vous souvenez pas du but. Les notes obsolètes sont pires que les notes manquantes car elles égarent activement Claude.

Un plan coûte quelques centaines de jetons. Un mauvais diff de 400 lignes que vous annulez et régénérez coûte des milliers, deux fois, plus les tours passés à expliquer ce qui s'est mal passé. En pratique : pour tout ce qui touche plus de deux ou trois fichiers, basculez en Mode Plan ou demandez simplement : « Avant de changer quoi que ce soit, listez les fichiers que vous allez toucher et ce que vous allez faire dans chacun. » Lisez la liste, corrigez-la en langage clair (« ignorez legacy/, et ne touchez pas encore aux tests »), puis laissez-la s'exécuter.

Conseil de pro : planifiez avec Opus, exécutez avec Sonnet. L'utilisation de plus grande valeur d'Opus est l'écriture du plan lui-même, où le raisonnement plus approfondi paie réellement. Une fois qu'un bon plan existe, l'exécution est surtout mécanique et Sonnet la gère à une fraction du coût. Flux de travail : /model opus, demandez le plan, examinez et corrigez-le, puis /model sonnet et « exécutez le plan ci-dessus ». Le changement de modèle n'efface pas la conversation, donc Sonnet voit toujours tout ce qu'Opus a produit.