Caveman et Ponytail arrivent dans l’API GreenPT

Si vous avez utilisé des agents de code IA cette année, vous avez sans doute remarqué un phénomène étrange : plus ces modèles progressent, plus ils parlent. Chaque question déclenche trois paragraphes d’explication. Chaque correction de code arrive avec un préambule, une visite guidée et un résumé. Le modèle veut se rendre utile, et il le fait en étant bavard. Et vous payez chaque mot.

Deux projets open source ont discrètement changé la façon dont les développeurs abordent ce problème. Aujourd’hui, nous les intégrons tous les deux dans l’API GreenPT elle-même.

Le problème : des agents qui en disent trop, en font trop et coûtent trop

Quiconque utilise des outils de code IA à grande échelle sait que le calcul ne tient pas. Les modèles de la classe GPT-5 facturent la sortie autour de 10 à 15 $ par million de tokens. Un seul développeur senior qui fait tourner un agent de code toute la journée peut consommer des millions de tokens en une semaine, pour l’essentiel de la narration, du code passe-partout et du code écrit par excès de prudence.

Un second coût attire moins l’attention : l’énergie. Chaque token de sortie correspond à une passe complète dans un grand modèle. Moins de tokens de sortie, c’est moins de calcul, moins d’électricité, moins de CO2. Pour les fournisseurs d’IA, la verbosité des réponses est en somme une taxe environnementale cachée, répercutée en silence sur des clients qui n’y peuvent pas grand-chose, sauf passer à des modèles plus petits (et moins bons).

Deux développeurs de la communauté open source ont estimé que le problème pouvait se résoudre au niveau du langage, pas du modèle.

Caveman : la même réponse, avec beaucoup moins de mots

Julius Brussee est parti d’un constat simple : l’essentiel de ce que génère un agent de code IA, c’est de la prose, pas du code. Si vous compressez la prose sans toucher au code, vous obtenez une grande partie de l’économie totale.

Sa réponse s’appelle Caveman, un ensemble de règles qui demande à l’agent d’écrire comme… un homme des cavernes. Au lieu de « Vous devriez probablement envelopper l’objet dans useMemo, car une nouvelle référence est créée à chaque rendu, ce qui empêche React de court-circuiter le rendu par égalité de référence », vous obtenez « Nouvelle réf d’objet à chaque rendu. Envelopper dans useMemo. »

La même réponse. Environ un neuvième du temps de lecture. Et surtout : les blocs de code, les messages d’erreur, les appels d’outils et les diffs sont conservés à l’octet près. Caveman compresse l’emballage, pas le sens.

La moyenne mesurée est une réduction de 65 % des tokens de sortie sur des prompts de type conversation (de 22 à 87 % selon les cas). Un article de mars 2026 cité par Brussee a même constaté que la concision des réponses d’IA améliorait la précision sur certains benchmarks d’environ 26 points. Moins de bruit, et le signal ressort mieux.

Caveman est disponible sous forme de skill pour Claude Code, Codex, Cursor, Windsurf, Cline, Copilot et une quarantaine d’autres agents. Il est sous licence MIT, n’envoie aucune télémétrie et compte désormais plus de 95 000 étoiles sur GitHub. Brussee est aussi d’une honnêteté rafraîchissante sur les compromis : Caveman ne compresse que les tokens de sortie, pas les tokens d’entrée ni de raisonnement, et ajoute environ 1 000 à 1 500 tokens de surcoût par tour. Sur des flux de travail surtout composés de code, l’économie diminue. Sur des flux surtout composés de prose, elle est énorme.

Ponytail : le code que vous n’écrivez pas

Dietrich Gebert a choisi un autre angle. Là où Caveman s’attaque à la façon dont l’agent parle, Ponytail s’attaque à ce que l’agent construit. Son idée centrale : les développeurs seniors sont paresseux. Pas dans le mauvais sens du terme. Dans le sens où ils savent que le meilleur code est celui qu’on n’écrit pas.

Ponytail impose une échelle de décision avant que l’agent n’écrive quoi que ce soit :

1. Est-ce que cela doit exister ? (YAGNI d’abord)
2. Est-ce que cela existe déjà dans ce code ? (Le réutiliser)
3. La bibliothèque standard le couvre-t-elle ? (Utiliser la stdlib)
4. Une fonctionnalité native de la plateforme le couvre-t-elle ? (L’utiliser)
5. Une dépendance déjà installée le résout-elle ? (L’utiliser)
6. Cela peut-il tenir en une ligne ? (L’écrire en une ligne)

Ce n’est que si la réponse est non aux six questions que l’agent écrit du nouveau code. Et même alors, le strict minimum.

Résultat : environ 54 % de code généré en moins en moyenne, et jusqu’à 94 % dans les scénarios de sur-ingénierie les plus marqués. Ponytail conserve 100 % de la logique de sécurité et de validation, qui est souvent la première chose que des agents trop zélés tentent de « simplifier ». Gebert l’a lancé en juin 2026 et il a dépassé les 95 000 étoiles, ce qui en fait l’un des outils de code à la croissance la plus rapide de l’année.

Comme Caveman, il fonctionne avec plus de 13 agents grâce à des plugins, des hooks et des fichiers de règles, et il est sous licence MIT.

Pourquoi nous avons intégré les deux dans la couche API

Le problème des skills, des plugins et des fichiers de règles, c’est qu’il faut les installer. Les configurer. Les maintenir à jour dans toute l’équipe. S’assurer que les nouvelles recrues connaissent leur existence. Ce sont autant de frictions, et les frictions freinent l’adoption.

Nous nous sommes posé une question simple : et si la compression se faisait directement au niveau de l’endpoint de l’API, sans rien à installer ?

C’est ce que nous lançons aujourd’hui. GreenPT propose désormais trois nouveaux endpoints basés sur GLM-5.2 :

• glm-5.2-caveman applique nativement les règles de Brussee (-22 % à -87 % de tokens de sortie)
• glm-5.2-ponytail applique nativement les règles de Gebert (-22 % à -94 % de tokens de sortie)
• glm-5.2-honey combine les deux, avec le même équilibre que notre skill Honey, pour les charges de travail qui mêlent prose et code (-6 % à -77 %)

Chacun existe en intensités -lite, par défaut et -ultra. Aucun paramètre supplémentaire, aucun en-tête, aucune acrobatie avec le SDK. Vous changez l’identifiant du modèle dans votre requête compatible OpenAI existante, et le tour est joué :

{
  "model": "glm-5.2-ponytail",
  "messages": [{ "role": "user", "content": "Add retry with backoff to this fetch call." }]
}

Comme l’endpoint est compatible OpenAI, il s’intègre directement à OpenCode, Cursor, Claude Code et à tous les outils de code qui parlent l’API OpenAI. La compression est intégrée.

Pourquoi c’est important, au-delà de la facture de tokens

Pour nous, chez GreenPT, cette version résume toute notre mission : la même réponse, avec moins d’énergie.

Le modèle de tarification ne change pas. Vous payez toujours au token, avec le même CO2 par token que GLM-5.2 standard. Mais comme il y a moins de tokens de sortie, votre facture totale baisse. Votre temps de réponse baisse. Votre consommation d’énergie baisse. Et nous vous reversons l’intégralité de l’économie, parce qu’elle est réelle : ce n’est pas une remise destinée à faire du volume.

Sur GreenPT, nous publions en standard les mesures de CO2 de chaque appel d’API. Avec ces endpoints, le chiffre baisse nettement, et vous pouvez le mesurer dans votre tableau de bord dès le premier jour.

Un partenariat avec les créateurs

Nous sommes le premier sponsor référencé de Ponytail, et les deux ensembles de règles tournent nativement sur nos endpoints, avec le plein crédit accordé à leurs créateurs. Julius Brussee et Dietrich Gebert ont construit ces outils en open source, les ont placés sous licence MIT et les ont mis à la disposition de tous. Cela mérite d’être reconnu, pas seulement adopté.

Si vous voulez utiliser leurs outils directement avec votre propre configuration d’agents, nous vous y encourageons aussi. Ce que nous avons fait, c’est rendre les mêmes principes accessibles à tous ceux qui utilisent déjà notre API, sans étape d’installation en plus. La même idée, livrée autrement.

Une vision plus large

Une partie de l’industrie de l’IA part du principe que l’efficacité viendra de modèles plus gros, d’un meilleur matériel ou d’astuces d’inférence ingénieuses. C’est parfois vrai. Mais certains des plus grands gains possibles aujourd’hui ne se trouvent pas dans le modèle : ils se trouvent dans la sortie. Chaque mot superflu généré par un agent coûte de l’argent et de l’énergie qui auraient pu être économisés.

Caveman et Ponytail l’ont prouvé au niveau des outils de développement. Nous le portons au niveau de l’infrastructure.

Si vous utilisez l’API de GreenPT, changer une seule chaîne dans votre requête peut réduire vos tokens de sortie jusqu’à 70 %. Ce n’est pas une remise. C’est simplement ce qui se passe quand le modèle arrête de trop expliquer.

Essayez-le

• Documentation des modèles de compression
• Caveman sur GitHub
• Ponytail sur GitHub