La page d'accueil ne porte qu'un seul chiffre. Pas parce que les autres seraient moins bons — parce qu'un site qui aligne quinze pourcentages ne prouve rien, il donne l'impression de choisir ceux qui l'arrangent. Ils sont donc tous ici, chacun avec ce qu'il mesure exactement, sur quel échantillon, et où aller vérifier la donnée brute.
Le chiffre de tête : coût à tâche égale. Banc public apparié, corpus gelé (lié par SHA-256), notation par exécution du code — pas par un juge qui donne son avis. Qualité strictement identique entre les deux bras (0,0 d'écart exactement, 29/30 des deux côtés), borne basse empirical-Bernstein 0,14 > 0.
C'est le plus défendable de nos chiffres parce que c'est le plus dur à obtenir : qualité égale prouvée, pas supposée. Rejouez le banc — le vérificateur et le corpus sont publiés.
| Mesure | Ce qu'elle mesure exactement | Vérifier |
|---|---|---|
| −58 % | ChaserBench v2, banc apparié, corpus gelé, notation par exécution du code, borne basse > 0. | /bench |
| −57 % | Le même banc en v1, noté par oracle regex au lieu de l'exécution. Même verdict — c'est ce qui compte : changer d'oracle ne change pas la conclusion. | /bench |
| −63,5 % | Run réel sur l'API (et non sur corpus gelé), bornes anytime-valid, qualité préservée. Chaque résultat scellé au journal. | /preuves |
| −52,5 % | AI-Scientist-v2 : un fork non modifié de l'agent de SakanaAI, routé par Chaser. 0,0612 $ contre 0,1288 $. | le rapport |
| −80 % | Un run précis, tracé : 5 posts LinkedIn à 0,0117 $ au lieu de 0,0584 $ si tout avait tourné sur Opus. Un exemple, pas une moyenne. | trace JSON du run |
| Mesure | Ce qu'elle mesure exactement | Vérifier |
|---|---|---|
| 71,7 % | Compression, mode max — médiane sur 123 observations réelles. Jamais une moyenne : une moyenne se laisse tirer par quelques cas extrêmes. | journal scellé |
| 64,8 % | Élagage relais, médiane sur 72 observations. | journal scellé |
| −82 % | Réduction de contexte, un exemple mesuré : 66 000 tokens ramenés à 12 000. | exemple documenté |
| jusqu'à −98,8 % | Un plafond, pas un cas typique. Tool calling : N outils remplacés par 2 méta-outils. Ce chiffre suppose des schémas très verbeux ; sur un petit jeu d'outils courts, c'est plutôt −55 à −65 %. Attesté sur vos propres outils et scellé. | outil MCP attester |
| Mesure | Ce qu'elle mesure exactement | Vérifier |
|---|---|---|
| 89 % | Taux d'acceptation de la cascade auto-vérifiée sur 195 décisions réelles, borne basse > 0 (anytime-valid). Ce n'est pas une économie : c'est la part des essais bon marché qui ont suffi. | journal scellé |
| 56,9 % borne 43,6 % |
Réduction mesurée par la couche d'expérimentation (intervalles anytime-valid, réduction de variance CUPED). La borne basse compte autant que le point : c'est elle qui tient si l'échantillon grandit. | export OpenTelemetry |
Deux catégories de chiffres circulent sur le site sans être des mesures. Les distinguer est le minimum honnête.
| Chiffre | Nature |
|---|---|
| −70 à −90 % | Estimation, pas mesure : projection de coûts API en combinant routage, Batch API et prompt caching. Elle n'est scellée dans aucun journal parce qu'elle ne décrit aucun run réel. |
| 30 % · 60 % | Parts de trafic, pas économies : les scénarios entreprise supposent qu'une fraction du trafic passe par Chaser. Un lecteur pressé les compte comme des pourcentages d'économies — ils n'en sont pas. |
Parce qu'ils mesurent des choses différentes : un coût à tâche égale, une réduction de tokens, un taux d'acceptation et une part de trafic ne sont pas comparables entre eux. Les empiler sur une page d'accueil ne rend pas la preuve plus forte, il la rend illisible — et donne au lecteur la seule impression qu'on cherche à éviter : celle du chiffre choisi après coup.
D'où la règle qu'on s'impose : un seul chiffre en page d'accueil, le plus défendable, et tous les autres ici avec leur protocole. Les comptes du produit (défauts, suites de tests, modules, composants) sont eux recalculés depuis leurs sources à chaque livraison, et un déploiement est refusé s'ils dérivent — voir la page transparence.