Abonné à Claude à 200 $, l'auteur revient à un contexte de 200K pour ménager ses limites

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

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

L'auteur note que ses amis et collègues sont depuis longtemps abonnés en même temps aux offres maximales de Claude et de GPT, 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 principale conclusion tirée du fragment accessible est inattendue. La cause n'est ni la complexité des tâches ni le volume de code lu. L'auteur l'attribue à un « banal confort au quotidien ». Le texte sur Habr s'interrompt à cet endroit ; la suite est masquée derrière le lien « Lire la suite ». Mais le titre (« Pourquoi je suis revenu à une 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 du fonctionnement général 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 l'historique accumulé : échanges, fichiers lus, résultats de commandes. Plus la fenêtre est grande et plus rarement on la nettoie, plus chaque étape consomme de tokens. Le cache de prompt amortit le choc, sans l'annuler. La longue « traîne » du contexte reste comptée dans le quota.

Le confort est ici évident. Une fenêtre large dispense de penser aux limites : pas besoin d'ouvrir une nouvelle session, de reconstruire le contexte ni de compresser l'historique. 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 entièrement consommée.
• 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 perceptibles.
• Décision : retour à une fenêtre de contexte de 200K.

Conclusions pratiques

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

• Répartissez les tâches en sessions distinctes plutôt que dans un dialogue interminable.
• 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 exigent des données différentes.
• 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 tient pas à l'offre tarifaire, mais à la manière de l'utiliser. Pour l'industrie, c'est un signal : l'agrandissement des fenêtres de contexte et le prix des abonnements lèvent les limites 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.