Mise à jour — été 2026 : cela ne fonctionnait plus pour moi
À l’été 2026, ce workflow avait cessé d’être fiable dans mon cas. Le compteur d’utilisation sur 5 heures avait disparu de mon compte, tandis que la limite hebdomadaire restait visible. En pratique, je n’avais plus la fenêtre de réinitialisation courte autour de laquelle j’organisais auparavant cette méthode.
Le changement le plus important concernait les tâches longues. Lorsqu’une grosse tâche Codex atteignait la fin de mon quota hebdomadaire, j’ai vu le travail s’arrêter au lieu de continuer jusqu’à son terme. Mon ancienne règle — lancer la tâche la plus lourde dans les derniers 3 à 5 % — perdait donc l’essentiel de son intérêt : je ne pouvais plus compter sur le fait qu’une tâche déjà lancée survive à l’épuisement du quota hebdomadaire.
Je veux toutefois distinguer précisément mon observation d’une règle officielle. Je peux confirmer ce que j’ai vu sur mon compte et dans mon workflow, mais pas affirmer qu’OpenAI a supprimé définitivement la fenêtre de 5 heures pour tous les utilisateurs. La documentation actuelle de Codex mentionne encore des fenêtres de 5 heures et hebdomadaires et indique qu’un tour actif peut parfois continuer après l’atteinte d’une limite, sous réserve de règles de fair use. Je présente donc le changement observé à l’été 2026 comme une expérience réelle dans mon cas, et non comme une règle universelle documentée pour tous les comptes.
Le reste de l’article est conservé comme description du workflow qui fonctionnait pour moi avant ce changement. La présente mise à jour prévaut sur les recommandations formulées au présent dans le texte d’origine.
Quand le compteur d’usage Codex de mon abonnement ChatGPT Plus tombe à environ 3 à 5 %, je ne dépense plus le reliquat dans de petits prompts. Je fais l’inverse : je lance la plus grosse tâche d’ingénierie que j’ai déjà préparée.
Dans mon cas, il s’agit généralement d’une migration complète vers TypeScript, d’un nettoyage ESLint à l’échelle du dépôt, d’une revue de bugs approfondie sur une codebase ou d’un gros refactoring structurel. J’ai souvent plusieurs projets prêts à l’avance, afin que la dernière tranche d’usage puisse aller à la tâche lourde réellement prête à démarrer.
La raison vient d’une observation répétée. À plusieurs reprises, j’ai lancé un travail important près de la fin de la limite visible, puis vu Codex continuer à travailler alors que cette limite semblait déjà épuisée. Parfois, la tâche a continué suffisamment longtemps pour se terminer. Cela s’est produit assez souvent pour changer ma planification, mais pas pour en faire une garantie du produit.
L’observation qui a changé mon workflow
À l’approche d’une limite d’usage, le réflexe naturel est d’être conservateur : utiliser le dernier morceau pour de petites demandes, car une grosse tâche risque d’être interrompue. Je traite désormais les derniers 3 à 5 % différemment. Pour moi, c’est une fenêtre de lancement.
La question utile n’est plus « combien de petits prompts puis-je encore faire passer ? », mais « quelle est la tâche préparée la plus précieuse que je peux démarrer tant qu’il me reste de l’usage inclus ? ».
Cela ne fonctionne que parce que le projet est déjà prêt et la tâche clairement définie. Je n’utilise pas les derniers pourcents pour découvrir ce qu’il faudrait faire. Je les utilise pour commencer l’exécution.
Une précision importante sur le nom et les limites
J’avais initialement appelé cela “Codex Plus”, mais c’est un raccourci, pas le nom officiel du produit. OpenAI présente Codex comme inclus avec ChatGPT Plus. Cette correction évite de laisser croire que Codex Plus est un plan ou un produit distinct.
La documentation actuelle d’OpenAI sur l’usage de Codex précise aussi que la consommation dépend de la taille et de la complexité du travail, du modèle et de l’endroit où la tâche s’exécute. Elle documente des fenêtres d’usage comprenant une fenêtre de 5 heures et une fenêtre hebdomadaire. Ici, « 3 à 5 % » désigne donc le pourcentage restant affiché dans l’interface d’usage, pas 3 à 5 % du temps réel, des tokens ou d’une quantité garantie de travail d’ingénierie.
Les utilisateurs Plus éligibles peuvent aussi prolonger l’usage de Codex avec des crédits après avoir atteint l’allocation incluse. Cela ne rend pas mon workflow caduc ; cela en précise simplement la portée. Je parle de la façon dont j’alloue mon usage inclus, pas d’une méthode pour contourner un quota.
Ce que je lance dans les derniers 3 à 5 %
Les tâches que je réserve généralement à ce moment sont des opérations d’ingénierie larges :
- migrations complètes vers TypeScript
- nettoyage ESLint à l’échelle du dépôt
- revues de bugs approfondies sur de grandes codebases
- gros refactorings structurels
Je préfère démarrer l’une de ces tâches comme un bloc de travail substantiel plutôt que de répartir la marge restante sur une série de petites demandes de faible valeur. Pour ce type de travail, un dépôt préparé et un objectif clair comptent davantage qu’une formulation particulièrement astucieuse du prompt.
Avoir plusieurs projets prêts aide pour la même raison. Si un dépôt demande encore des décisions ou du setup, je ne gaspille pas la dernière fenêtre à le préparer ; je peux démarrer sur un autre projet déjà prêt.
La préparation est la vraie contrainte
Le truc n’est pas « attendre 3 % puis coller un prompt énorme ». Si la tâche est ambiguë, un budget limité peut disparaître dans l’exploration, les clarifications ou du travail dans la mauvaise direction. Mon approche n’est utile que lorsque le projet est prêt à être exécuté et la tâche correctement bornée.
Pour un workflow similaire, un bon préflight consiste à expliciter le périmètre : ce qui doit changer, ce qui ne doit pas changer, les contraintes, la façon de valider le résultat et la sortie attendue de l’agent. Ce sont des garde-fous d’ingénierie généraux, pas la preuve qu’un format de prompt particulier débloque plus d’usage.
Cette préparation facilite aussi la reprise si la limite interrompt réellement une grosse tâche. Une migration ou une revue partielle est bien plus simple à continuer lorsque le scope et les critères de validation étaient clairs dès le départ.
Ce que je peux confirmer — et ce que je ne peux pas
Ce que je peux confirmer de mon propre usage est très précis : à plusieurs reprises, une tâche déjà démarrée a continué à progresser alors que la limite visible semblait épuisée, et elle s’est parfois terminée.
En revanche, je ne peux pas confirmer le mécanisme. Je ne peux pas affirmer qu’OpenAI accorde à chaque tâche en cours une période de grâce cachée, que les derniers 3 à 5 % suffisent à terminer n’importe quel gros travail, que ce comportement est stable ou qu’il permet de contourner la limite. La documentation d’OpenAI ne promet rien de tout cela.
Cette distinction est essentielle. Je planifie autour d’un comportement observé plusieurs fois, mais je n’en dépends pas. Si la tâche s’arrête à la limite, ce n’est pas la preuve que quelque chose s’est cassé. La stratégie a quand même rempli son rôle si j’ai utilisé le reste de l’allocation incluse sur une tâche plus importante que quelques petits prompts.
Une tâche terminée n’est pas une tâche vérifiée
Plus la tâche est grande, plus une seconde distinction devient importante : terminé ne veut pas dire correct. Une migration TypeScript qui build ne prouve pas le bon comportement au runtime. Un ESLint propre ne prouve pas la logique métier. Une revue qui signale un motif suspect n’a pas nécessairement trouvé un vrai bug. Même un refactoring avec des tests verts n’est fiable qu’à hauteur des tests et checks qui le couvrent.
Ce workflow modifie le moment où je lance le travail. Il ne réduit pas le niveau de validation. Les gros changements agentiques doivent toujours subir les contrôles adaptés au risque : revue du diff, typecheck, tests, build, vérifications runtime ou validation spécifique au projet.
Quand ce pattern est mal adapté
Toute grosse tâche n’est pas une bonne tâche de fin de limite. L’approche est moins adaptée si le travail reste flou, demande des décisions produit fréquentes, implique des opérations destructrices ou sensibles en production, ou laisse le dépôt dans un état dangereux s’il s’interrompt à mi-chemin.
Dans ces cas, une tâche plus petite et bien bornée ou une nouvelle fenêtre d’usage est généralement un meilleur choix d’ingénierie. Le but n’est pas de rendre le dernier prompt spectaculaire, mais d’investir une ressource incluse rare dans un travail capable de produire un progrès utile en sécurité.
Ma règle aujourd’hui
Quand mon usage Codex inclus dans ChatGPT Plus tombe à environ 3 à 5 %, je cesse d’optimiser le nombre de prompts restants. Je regarde les projets préparés à l’avance et je démarre la tâche d’ingénierie la plus lourde, clairement définie et réellement utile.
Si Codex continue après que le compteur visible atteint zéro, je le traite comme un comportement utile que j’ai observé, pas comme un droit. S’il s’arrête, je ne suis pas surpris. Je n’ai pas trouvé un moyen de contourner la limite. J’ai trouvé une meilleure façon de choisir ce que je lance avant de l’atteindre.