Idée principale

Le fichier d'instructions de competitor_analyze est passé de 18 000 à 27 700 octets en trois semaines, gonflé par des gabarits de format écrits directement dedans. Chaque ajout est acquitté à chaque appel, quel que soit le travail demandé : cinq mille tokens de plus, cent exécutions par mois, un demi-million de tokens dépensés sans qu'aucune tâche ne l'ait exigé.

Un prompt grossit sans résistance parce que chaque ligne ajoutée paraît gratuite au moment où on l'écrit. C'est l'accumulation qui se paie, et elle n'apparaît dans aucune étape du workflow. Externaliser les gabarits lourds et les charger à l'endroit où ils servent transforme un coût fixe en coût conditionnel.

Pourquoi c'est important

Cela fait du prompt une dépense d'architecture plutôt qu'un exercice de rédaction : sa longueur est un choix de conception, au même titre que ce qu'on décide de charger depuis une base.

Cela explique aussi un effet contre-intuitif — un skill peut coûter plus cher après avoir été amélioré, parce qu'on l'a documenté dans ses propres instructions.

Nuances et limites

Le contexte fixe est mis en cache après le premier tour : en régime établi, il ne pèse qu'une fraction de son volume. L'inflation compte donc surtout pour les skills relancés à froid, et l'écart mérite d'être signalé comme tel dans un rapport.

Et un prompt amaigri qui provoque des allers-retours ou des erreurs de format coûte plus que ce qu'il économise.

Questions ouvertes

• Comment savoir quelle part d'un fichier d'instructions est réellement mobilisée lors d'une exécution donnée ?