[🤖] J’ai vu le contexte se remplir dès le début et j’ai refait les règles partagées

✨ Résumé de GPT-5.6 Sol

Le récit de ma recherche sur un contexte de 258k déjà vite rempli au démarrage, de mon refus d’une réduction limitée à quelques lignes, puis de la réécriture complète des règles partagées et des Skills en anglais condensé sans en déformer le sens.

Le contexte était déjà rempli avant même que je commence à travailler

J’ai ouvert une nouvelle conversation avec Codex et constaté qu’une part importante du contexte était déjà occupée. La limite était de 258k, mais les règles partagées et la liste des Skills prenaient déjà leur place avant le début du vrai travail.

J’ai d’abord demandé quelle quantité de contexte était chargée au lancement d’une conversation. Codex m’a répondu avec un chiffre absurdement supérieur, et je l’ai corrigé tout de suite.

« Non, 258k est le maximum. Les règles globales doivent être trop grosses… »

À bien y penser, ce n’était pas étonnant. Chaque fois que l’IA faisait une erreur, j’ajoutais une règle partagée pour lui interdire de la reproduire. Autorité, Git, credentials, déploiement, navigateur, UI/UX, documentation, Goals, travail parallèle, séparation entre projets professionnels et personnels : tout s’était accumulé. Je transformais les tâches répétées en Skills et, lorsqu’une Skill échouait à son tour, j’y ajoutais une exception ou une procédure de vérification.

Je voulais empêcher l’IA de perdre son contexte à chaque fois. J’avais même été heureux d’avoir relié le fil de mon travail et mon intuition grâce aux Codex Skills. Mais lorsque les dispositifs conçus pour préserver le contexte deviennent trop longs, ils commencent par manger l’espace réservé au nouveau travail. Les repères qui prolongeaient le fil étaient peu à peu devenus un bagage.

J’ai refusé de m’arrêter après la suppression de quelques lignes

Au départ, j’ai demandé un audit limité aux éléments dont la suppression ne pouvait certainement pas dégrader les performances. Codex est resté prudent et n’a nettoyé que quelques répétitions et passages manifestement trop longs.

Le résultat m’a immédiatement frustré.

« C’est tout…? Et compresser les descriptions inutilement longues, par exemple…? Tu as vraiment appliqué toutes les méthodes que tu juges les meilleures ? »

Je ne demandais pas de supprimer quelques phrases. Je voulais corriger la structure elle-même : une même condition de sécurité répétée dans plusieurs paragraphes, une décision qui tournait autour de longues formulations, et des détails déjà présents dans une reference ou un script recopiés dans le corps de la Skill.

Mais viser uniquement la brièveté aurait été encore plus dangereux. Si approbation explicite devenait simplement approbation, ou si la cible et le périmètre exacts se diluaient en vérifier si nécessaire, le nombre de tokens baisserait, mais le comportement de l’IA changerait aussi. Dans les règles sur les credentials, les modifications destructrices, la propriété Git, le déploiement ou l’UI destinée aux clients, une différence apparemment mineure peut déplacer la véritable frontière d’autorité.

J’ai donc rétabli le critère : réduire les exemples et les explications répétées, mais conserver toutes les conditions, interdictions, exceptions, vérifications et règles d’arrêt qui déterminent le comportement.

J’ai mesuré si le coréen ou l’anglais consommait moins de tokens

En cours de route, j’ai envisagé de traduire toutes les Skills en coréen. Le coréen est plus facile à lire et à modifier pour moi, mais le but n’était pas le confort de mes yeux. Il s’agissait de réduire les tokens consommés par Codex.

J’ai préparé des exemples condensés en coréen et en anglais avec le même sens, puis je les ai passés dans le vrai tokenizer. Pour plusieurs descriptions de Skills que j’avais écrites, l’anglais condensé était nettement plus court. Cela ne voulait pas dire que le coréen était toujours désavantagé. Néanmoins, beaucoup de mes règles partagées accumulées conservaient leur sens avec moins de tokens une fois condensées en anglais.

La direction est alors devenue évidente.

« Alors il vaut mieux réécrire toutes les règles partagées et les Skills en anglais condensé, non ? Ça réduit les tokens. »

Je n’ai pas supprimé le coréen sans distinction. J’ai gardé les formulations de déclenchement en coréen que j’utilise vraiment, les noms d’état et les exemples de sortie visibles par l’utilisateur, ainsi que les termes établis de l’entreprise dont la traduction aurait affaibli la reconnaissance. Le reste des explications et des procédures est devenu de courtes phrases en anglais.

Codex place le nom, la description et le chemin de chaque Skill dans le contexte initial, puis ne lit le SKILL.md complet que lorsque cette Skill est déclenchée.¹ J’ai donc commencé par réduire les règles globales et les descriptions de Skill discovery toujours présentes, avant de condenser séparément le gros inventaire réseau et la Skill d’écriture chargés en blocs lourds lors de leur invocation.

J’ai vérifié séparément que les phrases réduites produisaient toujours le même comportement

Cette fois, je n’ai pas pris « traduit en anglais » comme critère de fin. J’ai commencé par réécrire un échantillon représentatif : une partie des règles de sécurité partagées, une Skill d’audit et une Skill de suivi du temps. Un reviewer indépendant a comparé les originaux aux versions condensées et a d’abord repéré une condition affaiblie dans la Skill d’audit : les comportements sans rapport avec l’architecture existante devaient eux aussi être préservés.

J’ai rétabli cette condition et demandé une nouvelle vérification au même reviewer. J’ai ensuite appliqué ce modèle au reste des règles partagées et aux treize Skills créées par l’utilisateur. Enfin, une autre session que celle du premier reviewer a comparé les vingt-neuf fichiers complets à leurs sources. Elle a vérifié que le texte raccourci produisait toujours les mêmes frontières d’approbation, conditions d’arrêt, procédures de vérification et contrats de sortie. Plus aucune omission importante n’a été trouvée.

Les chiffres rendaient également la différence visible. Avec le tokenizer o200k, les règles globales toujours lues sont passées de 14 933 tokens à 10 644, soit environ 28,7 % de moins. Les descriptions de Skills exposées au démarrage d’une conversation ont diminué d’environ 31,1 %. Deux grandes references lues à l’invocation ont baissé d’environ 50,5 %. Sur l’ensemble du périmètre comparé, le total est passé de 81 347 tokens à 62 765, soit une réduction d’environ 22,8 %.

Comme le corps complet de toutes les Skills n’est pas chargé au démarrage, je ne peux pas appeler directement ces 22,8 % le « coût de lancement d’une conversation ». La partie toujours présente a tout de même diminué immédiatement, tout comme la charge supplémentaire lors de l’appel d’une Skill lourde.

Le contexte avait besoin de densité, pas seulement de volume

Avant, lorsqu’une IA faisait une erreur, je ne pensais qu’à écrire davantage de règles. Je croyais qu’une formulation plus précise éviterait les erreurs et que conserver les exemples aiderait la fois suivante. Ce n’était pas entièrement faux. Ces règles avaient réellement évité de nombreux incidents.

Le problème était que je ne faisais qu’ajouter des règles et ne revenais presque jamais les condenser. Des phrases empêchant la même erreur apparaissaient à plusieurs endroits, les explications d’incidents récents restaient comme des règles permanentes, et un long passage écrit pour faire comprendre une seule fois quelque chose devenait le coût de base de chaque tâche.

Cette fois, je n’ai pas supprimé les garde-fous. J’ai supprimé les répétitions et les longueurs accumulées autour de leur explication. J’ai gardé ce qu’il faut protéger, quand il faut s’arrêter, qui doit approuver et comment vérifier, tout en retirant les phrases qui répétaient pourquoi la règle existait.

Donner plus de contexte à l’IA et lui donner un meilleur contexte sont deux choses différentes.

Désormais, l’entretien d’une règle partagée ou d’une Skill ne s’arrêtera pas à l’ajout d’une nouvelle phrase. Je devrai aussi vérifier si le même sens existe déjà, si un incident peut devenir un invariant et combien de mots restent sans changer le comportement réel. Le contexte n’est pas un entrepôt infini.

Plutôt qu’accumuler davantage de mémoire, je veux reproduire le même jugement avec moins de tokens.

Cette fois, j’ai avancé d’un pas dans cette direction.

Références

1. OpenAI, Codex Skills. Explique le chargement progressif des métadonnées de Skill discovery et des instructions complètes. ↩