Les limites d'usage de Claude Code, et comment cesser de les atteindre
La limite n'est ni un bug ni vraiment une question de quantité de travail. C'est une question de contexte transporté à chaque tour.
Les abonnements Claude sont mesurés à l'usage, pas au nombre de messages. Deux personnes peuvent envoyer autant de prompts dans la semaine et se retrouver dans des situations totalement différentes, parce que l'une envoie un dépôt entier à chaque question et l'autre non.
Ce que la limite compte
En gros, le compteur tourne sur les tokens traités, pondérés par modèle. Cela veut dire trois choses, et la troisième surprend.
- Une longue session coûte plus cher par tour qu'une courte, parce que tout le fil est renvoyé à chaque fois.
- Un plus gros modèle coûte plus par token qu'un plus petit à travail identique.
- Lire des fichiers n'est pas gratuit. Un agent qui en ouvre six pour répondre à une question d'une ligne a dépensé six fois la valeur d'une question d'une ligne.
C'est pourquoi la limite tombe plutôt l'après-midi d'une journée productive qu'à la fin d'une semaine calme. Productif veut dire ici longues sessions, et les longues sessions sont quadratiques : chaque tour paie pour tous les tours précédents.
Pourquoi elle tombe toujours en pleine tâche
Parce que les tours coûteux sont ceux du milieu. Le premier tour d'une session est bon marché. Le vingtième transporte dix-neuf tours de fil, plus chaque fichier lu en chemin, plus chaque sortie de test. On n'est jamais coupé pendant qu'on réfléchit ; on est coupé pendant qu'on termine.
Les quatre habitudes qui aident vraiment
Dans l'ordre de ce qu'elles valent sur une semaine :
- Une session neuve par tâche. C'est la grosse. Rien d'autre dans cette liste n'en approche.
- Nommer le fichier au lieu de le décrire. L'exploration est la chose la plus chère que fasse un agent.
- Utiliser le petit modèle pour le travail mécanique : renommages, mise en forme, édition d'un seul fichier.
- Tenir les sorties bruyantes à l'écart du fil. Filtrez avant qu'elles n'arrivent.
Le faire sans changer sa façon de travailler
Ces habitudes fonctionnent, mais elles demandent de la discipline à chaque tour, ce qui est exactement le genre de chose qu'on cesse de faire le mercredi. L'autre voie est de poser un plafond sur le contexte et de le laisser tenir tout seul.
npm i -g @penra/capsulcapsul ask 'répare le test d'authentification qui échoue' --budget 3000Pilote le CLI Claude auquel vous êtes déjà connecté. Pas de clé API, pas de seconde facture.
Quand elle est déjà atteinte
On ne peut pas acheter sa sortie d'une limite de session en cours de fenêtre, et aucune option ne la remet à zéro. Ce que l'on peut faire, c'est que la prochaine fenêtre dure plus longtemps que la précédente, ce qui est une question de contenu de chaque tour, pas de nombre de tours.
Questions
Pourquoi j'atteins la limite plus vite qu'un collègue sur le même abonnement ?
Presque toujours la longueur des sessions et l'exploration de fichiers. Une longue session qui a lu trente fichiers coûte bien plus par tour que dix courtes sessions qui en lisent deux chacune, même à nombre de prompts identique.
La limite hebdomadaire se remet-elle à zéro si je change de modèle ?
Non. Le compteur est partagé. Choisir un plus petit modèle réduit la vitesse à laquelle on le consomme, ce qui est autre chose, et plus utile.
capsul a-t-il besoin de ma clé API Anthropic ?
Non. Il pilote le CLI Claude auquel vous êtes déjà connecté : c'est votre abonnement Pro ou Max existant qui répond. Les clés API sont un choix facultatif par session, pas une obligation.
Envoyer moins de contexte donne-t-il de moins bonnes réponses ?
Pas automatiquement, et c'est mesuré plutôt que supposé. Le banc publie les vérifications de réponse à côté des comptages de tokens sur chaque ligne : une économie payée au prix de la justesse s'y voit au lieu de s'y cacher.
$ npm i -g @penra/capsul