Abonné à Claude à $200, un développeur revient au contexte de 200K pour tenir les limites

Au printemps, l'abonnement Claude à $100 couvrait toutes les tâches du projet personnel de l'auteur de ce texte publié sur Habr. Au début de l'été, il consommait déjà régulièrement en entier la limite de tokens sur cinq heures. En août, le quota ne suffisait plus que pour la conception technique, et il fallait attendre la semaine suivante pour démarrer l'implémentation. Une fois lancée, une tâche engloutissait la limite hebdomadaire en trois jours environ. En septembre, il est passé à l'abonnement à $200, mais là non plus, les limites ne paraissaient pas hors d'atteinte.

Du palier à $100 à celui à $200, et l'impasse

L'auteur note que ses amis et collègues sont depuis longtemps sur les formules maximales de Claude et de GPT en même temps, et que certains envisagent un troisième abonnement. Il juge cette voie sans issue : les dépenses croissent avec l'appétit, sans jamais créer de marge de sécurité. Il s'est donc attaqué à l'optimisation de sa consommation de tokens.

La conclusion principale, d'après le fragment accessible, surprend. La cause n'est ni la complexité des tâches ni le volume de code relu. L'auteur l'attribue à un « banal confort quotidien ». Le texte sur Habr s'interrompt à cet endroit ; la suite est masquée derrière le lien « Читать далее ». Mais le titre (« Pourquoi je suis revenu à la fenêtre de contexte de 200K ») indique la décision à laquelle il est arrivé.

Pourquoi la taille de la fenêtre pèse sur les limites

Ce qui suit relève de la mécanique générale des LLM, et non d'un résumé de l'article. Dans un dialogue avec un modèle, et plus encore en codage agentique, chaque nouvelle requête embarque tout l'historique accumulé : échanges, fichiers lus, résultats de commandes. Plus la fenêtre est grande et plus on la nettoie rarement, plus chaque étape consomme de tokens. Le cache de prompt amortit le choc, sans l'annuler. La longue « traîne » du contexte continue de compter dans le calcul du quota.

Le confort est ici évident. Une large fenêtre dispense de penser aux limites : pas de nouvelle session à ouvrir, pas de contexte à reconstruire, pas d'historique à compresser. L'habitude de tout accumuler dans une seule session fonctionne tant que les limites ne deviennent pas la contrainte principale. À grande échelle, cette insouciance devient le poste de dépense le plus coûteux.

Les chiffres clés de l'histoire

• Printemps : l'abonnement à $100 couvrait toutes les tâches du projet.
• Début de l'été : la limite de tokens sur cinq heures est consommée en entier.
• Août : les limites suffisent pour la conception technique, l'implémentation est repoussée à la semaine suivante.
• Lancement d'une tâche : le quota hebdomadaire part en 3 jours environ.
• Septembre : abonnement à $200, les limites restent sensibles.
• Décision : retour à la fenêtre de contexte de 200K.

Enseignements pratiques

Cette histoire intéresse ceux qui butent sur les limites des abonnements Claude, GPT ou d'autres outils agentiques. Avant de payer la formule supérieure, mieux vaut vérifier ses propres habitudes de gestion du contexte :

• Répartissez les tâches en sessions distinctes plutôt que de tout mener dans un dialogue sans fin.
• Ne gardez pas dans le contexte les fichiers et les logs qui ne servent plus à l'étape suivante.
• Séparez la phase de conception de celle d'implémentation : elles n'exigent pas les mêmes données.
• Comparez la consommation de tokens avec une fenêtre de 200K et avec une fenêtre étendue, sur les mêmes tâches.

L'auteur en conclut que le problème ne vient pas de la formule tarifaire, mais de la manière de s'en servir. Pour le secteur, c'est un signal : l'agrandissement des fenêtres de contexte et la hausse des prix des abonnements lèvent les contraintes techniques, mais l'économie des tokens demeure. Un utilisateur qui paie $200 compte malgré tout chaque token, et les outils de gestion du contexte deviennent une composante du flux de travail au même titre que le choix du modèle.