Introduction
Le débat utile du moment n’est plus seulement “quel modèle est le meilleur”, mais “pourquoi ma session coupe au pire moment”. La vidéo YouTube “Your Claude Limit Burns In 90 Minutes Because Of One ChatGPT Habit.” avance qu’une habitude héritée de ChatGPT accélère l’atteinte des limites sur Claude. Point clé: le “90 minutes” vient du titre de la vidéo, pas d’une règle universelle. En pratique, cela dépend du plan, des tâches, du trafic et de votre intensité d’usage.
Côté terrain, la discussion GitHub Community #152913 rapporte des messages du type “you have exhausted this model’s rate limit”, parfois après un usage jugé modéré. Avec les sources listées ici, on ne dispose pas d’un document produit détaillant précisément quotas et calcul. La posture raisonnable reste donc: signal crédible, ampleur exacte variable selon le contexte.
Pour une équipe dev, ce n’est pas un détail de confort. Une limite qui tombe sans visibilité claire casse le rythme de livraison, rallonge la reprise de contexte, et incite à recoller trop d’historique dans le prompt suivant. Ce dernier réflexe augmente aussi le risque d’exposer des infos sensibles.
Décryptage
L’idée centrale de la vidéo est simple: beaucoup de devs gardent un seul chat très long pour tout faire (debug, refacto, tests, doc, planification). Selon l’auteur, cette logique de “chat infini” gonfle progressivement la charge contextuelle et la friction liée aux limites. Les chiffres précis ne sont pas publiés dans les sources fournies, mais le mécanisme est cohérent avec ce qu’on observe dans les usages LLM.
Plus l’historique grossit, plus chaque nouveau tour coûte cher en attention. Vous devez relire, recadrer, corriger les dérives, répéter des contraintes. Puis, si la session coupe, la perte n’est pas seulement la coupure: c’est le coût de reconstruction. Il faut reconstituer les décisions, les hypothèses, les fichiers impactés, et relancer proprement.
Le fil GitHub souligne aussi un problème critique en production: l’imprévisibilité. Si vous ne savez pas si la session tiendra 20 minutes ou 2 heures, vous surcompensez. Résultat: prompts trop longs, contexte redondant, et bascules d’outil plus fréquentes que nécessaire.
Le signal utile est donc méthodologique: traiter le LLM comme un worker spécialisé, pas comme un journal global du projet. Le dépôt awesome-ChatGPT-repositories illustre d’ailleurs cette tendance de fond: segmentation des tâches, prompts structurés, orchestration, et mémoire externalisée.
Mini-protocole anti “chat infini”:
- Ouvrir une session par tâche (
bug-login,refacto-cache,tests-api). - Injecter un contexte borné: objectif, contraintes, fichiers clés, définition de done.
- Terminer chaque session par un résumé exportable (8 à 10 lignes).
- Démarrer la session suivante avec ce résumé, pas avec tout l’historique.
Checklist de prompt court:
- Objectif exact en une phrase.
- Entrées autorisées (fichiers/fonctions).
- Sortie attendue (diff, tests, explication).
- Limites explicites (ex: pas de migration DB, pas de dépendance nouvelle).
- Critères de validation.
Ce que ça change pour les devs
- Découpez les échanges IA par ticket: une conversation = un livrable.
- Fixez un budget de contexte par session (ex: brief < 300 mots + 3 extraits max).
- Exigez un résumé final standardisé pour réduire le coût de reprise.
- Externalisez la mémoire projet dans des fichiers (
DECISIONS.md,TASK_CONTEXT.md) plutôt que dans un seul chat. - Évitez d’injecter secrets, dumps complets ou logs sensibles.
- Mesurez pendant 1 semaine: interruptions, temps de reprise, qualité de sortie.
- Ajustez vos règles ensuite (taille du brief, format de sortie, seuil de redémarrage).
Conclusion
Le sujet n’est pas “Claude vs ChatGPT”, mais l’écart entre nos habitudes conversationnelles et la mécanique de limites. D’après la vidéo citée et les retours GitHub, conserver un fil unique et interminable augmente le risque de coupure, la variabilité de livraison et la charge mentale.
La correction est surtout organisationnelle: sessions plus courtes, contexte explicite, sorties normalisées, mémoire hors chat. C’est simple à tester, rapide à déployer, et cela améliore la fiabilité sans changer d’outil.
Sources: https://www.youtube.com/watch?v=5ztI_dbj6ek, https://github.com/orgs/community/discussions/152913, https://github.com/taishi-i/awesome-ChatGPT-repositories/blob/main/docs/README.en.md
