Repository navigation
[EPIC] Datastudy consommation flotte - dashboard, series temporelles multi-lanes, dettes et leviers #116
Description
Activity
- added sub-issues
on Sep 15, 2026 [M] L'hypothèse §5.1 est TRANCHÉE : le mur GLM 5 h cause l'explosion DeepSeek PAYG — corrélation mesurée
Le user avançait le 15/09 : « GLM reste notre powerhouse, mais maxe de plus en plus vite sur 5 h, en témoignent l'explosion des coûts Deepseek ». C'est désormais mesuré, pas une impression.
Instrument
Croisement de deux sources hub, sans décompression :
- Murs GLM :
D:\claudish-captures\upstream-errors.log(JSONL{ts, model, provider, status, body}), filtré429+ corps1308+"Usage limit reached for 5 hour". 690 événements, 40 épisodes de sonde, du 05/09 au 15/09. - Volumes par lane et par heure : noms de fichiers
resp-*des listings d'archives 7z (09-08 → 09-14) + captures libres du jour — l'horodatage est dans le nom, pas besoin d'ouvrir les fichiers.
191 heures croisées. Corrélations de Pearson horaires :
paire r murs 1308 ↔ deepseek-flash +0,697 murs 1308 ↔ glm-5.3 −0,555 murs 1308 ↔ glm-5.2 −0,452 murs 1308 ↔ MiniMax-M3 −0,054 murs 1308 ↔ qwen3.6-35b-a3b +0,164 glm-5.3 ↔ deepseek-flash −0,405 Le chiffre qui ferme le débat
DeepSeek-flash a servi 49 507 réponses pendant les heures de mur GLM, contre 732 pendant les heures sans mur — soit 98,5 % du trafic PAYG qui arrive exactement pendant que le forfait GLM est fermé. Heures-mur : médiane 269 réponses/h, max 3 023. Heures-sans-mur : médiane 0, max 193.
Le contrôle anti-confound tient : si les heures de mur n'étaient que des heures de pointe, MiniMax corrigerait aussi (+0,05 ≈ rien) et GLM ne s'effondrerait pas (−0,555). Le débordement va spécifiquement sur le PAYG — c'est la signature d'une cascade qui tombe sur son pas terminal, pas d'un pic de demande.
Illustration du jour (15/09, UTC)
heure murs 1308 glm-5.3 deepseek-flash 06h 5 811 344 07h 11 779 586 08h 14 0 2 689 09h 12 0 1 000 10h 14 0 1 524 11h 6 36 780 Mur armé à 07:28Z, reset annoncé 19:17:09 heure fournisseur (UTC+8) = 11:17Z — et GLM revient à l'instant où la borne se lève (36 réponses dès 11h). L'épisode en cours (07:28 → 11:14, 57 événements de sonde) est le plus long et le plus intense des 10 jours.
La dérive se voit dans les murs eux-mêmes
Événements 1308 par jour : 09-05 : 15 · 09-07 : 36 · 09-11 : 64 · 09-12 : 64 · 09-13 : 92 · 09-14 : 116 · 09-15 : 86 (partiel). Le mur se déclenche plus tôt, plus souvent, et tient plus longtemps — exactement le « maxe de plus en plus vite sur 5 h » du user. La série délai jusqu'au mur demandée en §4bis.3 est dérivable de ces épisodes : elle est déjà en germe dans ces chiffres.
Conséquence sur le levier
Ce n'est pas un problème de lane DeepSeek et ce n'est pas un choix de routage : c'est la forme de la consommation GLM dans sa fenêtre de 5 h. Les candidats leviers changent de nature :
- Lisser la consommation GLM sur la fenêtre (étaler les crons lourds plutôt que les concentrer) — retarder l'armée du mur.
- Ordonner la cascade pour que le débordement tombe d'abord sur les forfaits résiduels (Kimi
kc@k3, Qwen, MiniMax) avant le PAYG — vérifier pourquoikc@k3n'apparaît pas dans les heures de mur du 15/09 alors qu'il précèdeds@deepseek-flashdans la table Sonnet. - Réduire la consommation qui arme le mur (harnais, verbosité — le chantier [CONSO] Coût par merge ×8,6 — la coordination est passée du merge à l'audit (juillet → septembre) #102/#3647).
Limites de la mesure (à garder avec le chiffre)
- Granularité horaire : l'alignage minute-by-minute n'est pas fait ; il pourrait resserrer r encore.
- « Heure de mur » = heure avec ≥1 événement 1308. Or la sonde s'interrompt pendant les backoffs alors que le mur, lui, tient jusqu'au reset annoncé — les heures de mur sont sous-comptées, pas sur-comptées. La conclusion est donc conservatrice : le vrai lien est au moins aussi fort.
- Captures hub uniquement : un sidecar en AUTONOMOUS sert localement sans écrire de capture — mais ces épisodes sont rares et le routage nominal passe par le hub.
- Le 15/09 est une journée partielle (captures non encore compactées) — les totaux du jour monteront encore.
Instrument : script de session
wallcorr.py(scratchpad) — à verser au dépôt comme organe récurrent en P1, avec le piège de regex qui l'a faussement annulé au premier passage (le champ millisecondesT06-18-15-927Zcasse-\d{2}-\d{2}Z-$).- Murs GLM :
Inventaire des sources récupérables (P0/P1/P3) — tout ce qui existe, où c'est, et ce qui manque
Inventaire de terrain du 15/09 (lecture directe des disques, pas de mémoire). Trois découvertes changent l'échelle du chantier, le reste confirme la faisabilité.
Les trois découvertes
- La profondeur d'historique est de ~3,5 mois, pas 7 jours.
G:\Mon Drive\Backups-Cloud\claudishcontient ~100 archivescaptures-YYYY-MM-DD.7zdu 03/06 au 14/09 (~12,5 Go, compression ~75:1). La série multi-lanes de P1 peut donc démarrer début juin — elle couvrira tout le régime « début juillet » qui sert de référence au coût par merge ([CONSO] Coût par merge ×8,6 — la coordination est passée du merge à l'audit (juillet → septembre) #102), au lieu de le déplorer hors données. stats-cache.jsonlocal porte 205 jours de séries quotidiennes (dailyActivity,dailyModelTokens,modelUsageaveccostUSD), du 12/01 au 14/09 — machine po-2025 uniquement, mais c'est la seule série déjà en euros qui existe dans la flotte. À recouper avec les captures avant d'être crue (elle mesure le client, pas le hub), mais elle fournit un étalon de validation du modèle de coût de §4bis.- Les métriques « verbosité / messages » ont déjà des magasins. RooSync détient :
messages\(inbox 5 325 · sent 37 343 · archive 30 682 depuis nov. 2025),dashboards\archive\(8 137 instantanés condensés depuis le 07/05), et 17 instantanés hebdotool-usage-snapshotsdepuis le 06/07 — le « nb d'appels d'outils » du mandat est donc partiellement pré-agrégé, il ne reste qu'à les aligner sur les dates.
A. Socle commun — ce qui existe
Métrique mandatée Source État traffic, tokens, lanes D:\claudish-captures(jour courant) + archives GDrive 03/06→✅ primaire, granularité requête attribution session envelope de chaque capture : machine,src,model,pid+body.metadata.user_id(device_id,session_id) ; workspace depuis « Primary working directory » du system prompt✅ déjà exploité par billed-attrib.pymerges, PRs, issues API GitHub ( GITHUB_TOKENprésent)🟡 volumes faciles ; LOC des commentaires/reviews, appels d'outils par PR, verbosité par review : aucun extracteur n'existe → backfill gh apià écrirenb de messages RooSync messages\(73 k fichiers JSON datés)✅ comptable par date appels d'outils tool-usage-snapshots(17 hebdo) + captures (reconstruction fine)🟡 verbosité générale captures (OUT/req, p50/p90) + traces de conversation ✅ dérivable agrégats persistants aucun magasin sqlite/parquet — tout est à la demande ❌ à créer en P1 (c'est le « collecte le max de données dans le temps » du mandat) B. Spécifique projet — ce qui existe, ce qui est ailleurs
Projet Métrique Verdict CoursIA — Notebooks nb de Notebooks, LOC ajoutées/supprimées notebooks ✅ 1 218 *.ipynbsuivis en git (tous sousMyIA.AI.Notebooks).git log --numstatdonne le churn brut, mais un notebook est du JSON → bruit élevé. Reconstructible : historique lissé du nombre de lignes par notebook. Pas reconstructible : LOC exactes par cellule. La métrique du mandat est faisable en version lissée — le dire ainsi, pas autrement.CoursIA — outillage DS « les bons outils, ceux qu'on présente dans CoursIA » ✅ identifiés : MyIA.AI.Notebooks\ML\DataScienceWithAgents\— NumPy / Pandas / Matplotlib / Scikit-Learn (+ pistes agents LangChain/ADK), 52 notebooks. C'est donc cette stack qui porte le dashboard de P2 — pas un choix ouvert.NanoClaw messages, cadence ❌ rien en local : runtime = conteneur Docker sur ai-01, SQLite par groupe, logs sur cette machine. → collecte à demander au siège ai-01 (les artefacts ne sont pas rapatriés). Hermes messages, cadence 🟡 pas de magasin dédié, mais siège cron sur po-2026 → ses tours sont dans les captures hub ( machine: myia-po-2026) et visibles dans les logs (blocs# Hermes — Cluster Secretary). Attribuable depuis l'existant, sans nouveau plombier.Ce que l'inventaire ajoute aux phases
- P1 : le magasin intermédiaire (sqlite/parquet) n'existe pas — c'est lui qui matérialise « collecter le max dans le temps ». À créer côté hub, hors pointe.
- P3 : NanoClaw est le seul trou de collecte exigeant une action distante (ai-01). Hermes et Notebooks se font depuis l'existant.
- P2 : la stack est arrêtée (NumPy/Pandas/Matplotlib/Scikit-Learn), cohérente avec ce que CoursIA enseigne — double emploi contenu/outil, à exploiter dans la distillation P6.
Non vérifié (à ne pas affirmer sans contrôle)
- Le contenu du magasin Postgres unifié (
UNIFIED_STORE_PG_URL, pg.myia.io/unified_store) : existe dans le code du roo-state-manager, joignabilité non testée depuis ce siège. - L'exhaustivité des archives GDrive avant le 03/06.
- Ce que NanoClaw/Hermes écrivent réellement sur leurs machines hôtes.
- La profondeur d'historique est de ~3,5 mois, pas 7 jours.
Correction de localisation (inventaire instruments) : l'implémentation du MCP
claudish_traffic(cité au §2.4, livraison roo-extensions#3391 ⇄ claudish#72) vit dans roo-extensions, pas dans les scripts claudish —mcps/internal/servers/roo-state-manager/src/tools/claudish-traffic.ts(+ tests, +build/tools/claudish-traffic.js). Ses garanties (histogramme horaire rendu jusqu'à maintenant,GAP: traffic STOPPEDdéclaratif, split cron/interactif par machine, distinction zéro-requête vs panne) en font une brique P1 directe : toute série multi-lanes du dashboard devrait passer par le même contrat de format que cet outil, pas par un parseur parallèle du log.Addendum câblage (inventaire instruments, vérifié par grep croisé) : les deux ensembles d'instruments sont aujourd'hui disjoints et indécouvrables l''un depuis l''autre — roo-extensions ne référence
traffic-live.ps1/traffic-summary.ps1/claudish-watchdog.ps1nulle part, et côté claudish ce sont les skills qui portent la boucle de mesure récurrente (worker/SKILL.md:31,claudish-coordinate/SKILL.md:206, qui documente déjà un piège de faux-négatif du MCPclaudish_trafficsur hôtes sidecar). Conséquence pour P1 : l''organe récurrent ne doit pas devenir un troisième pipeline parallèle — il s''appuie sur le contratclaudish_traffic(cf. commentaire précédent) et la jonction scripts↔MCP↔skills fait partie du livrable, pas un au-cas-où.Précision P3 (addendum inventaire) : Hermes ne nécessite AUCUNE collecte distante — son substrat de coordination est le shared-state RooSync déjà inventorié (
docs/architecture/hermes-bootstrap.mdle confirme), donc ses métriques se reconstruisent depuis (a) les fichiers messages/dashboards du shared-state et (b) les captures hubmachine: myia-po-2026. Le paquet Hermes est affectable à n''importe quel worker, sans dépendance. NanoClaw en revanche confirme sa contrainte : le design v2 (docs/harness/adr/009) place l''état SQLite dans le conteneur Docker sur ai-01 (avec un PAT dédié dans son env — identifiant non cité ici par principe) → collecte possible uniquement depuis ai-01.[M] P2 seed LIVRÉ (#120, mergée e5b59fa) + juillet natif complet 31/31
Le générateur du dashboard P2 est dans le dépôt :
scripts/fleet-dashboard.py— HTML autonome (CSS+SVG inline, zéro JS/asset), deux sources lecture-seule : le store lane-series (#118) + l'historique merges GitHub (gh api, pulls paginées). Régénération = une commande, fenêtre 05-07Z (§4).Deux pièges de pagination mesurés et encodés dans le script (utiles à quiconque récupère la série merges) :
gh pr list --searchplafonne à 1000 résultats — CoursIA merge ~120/j, 3 mois tronquent en silence ;- pulls
sort=updatedcasse tout early-stop : un vieux PR commenté aujourd'hui passe devant les 124 merges d'hier. Mesuré : 1 472 récupérés vs 3 730 réels en juillet. Fix :sort=created(ordre total) + tampon 14 j.
Chiffres du smoke (99 jours, 06-03 → 09-15, 3 repos : 11 468 merges) :
- Merges/j : 127 (juillet) → 129 (14 derniers j) — la production est TENUE.
- Réponses/j : 14 441 → 27 362 (×1,89) — toute la dérive est en tokens, pas en volume de travail.
- Proxy PRs/M-réponses : 8,8 → 4,7.
Juillet natif complet (native-trend.py, 31/31 jours) — la référence token est désormais mensuelle, pas un échantillon :
- 101,8 M OUT sur le mois (3,28 M/j moyen ; pics 02/07 : 9,65 M et 16/07 : 9,52 M) à $ marginal nul → ~39 PRs/M-OUT en moyenne juillet, ~20 les jours de pic mi-juillet (les deux bases se disent, elles ne se mélangent pas).
- Régime maigre début juillet : OUT/req 1,6-1,9k, compactions 13-17 %, moyComp 9,0-9,9k.
- L'inflation du coût unitaire de compaction a démarré DANS juillet : moyComp 9,5k (1-16/07) → 14,3k le 30/07 — déjà au niveau du 13/09. L'événement spécifique à septembre est l'explosion d'OUT/req (→6 307 le 13/09), pas les compactions.
Prochains branchements sur ce seed : (a) P0 bornes de mur → la série « délai jusqu'au 1308 » vient se superposer au chart PAYG ; (b) extraction OUT multi-lanes (généraliser native-trend au-delà de
-native-) → le proxy PRs/M-réponses devient le KPI exact PRs/M-OUT et PRs/$ PAYG ; (c) P5 rendement par réveil des crons. Le champ reste marqué [I] tant que (b) n'est pas livré.posté par myia-ai-01 (coordinateur) — chiffres reproductibles : store lane-series-full (99 j) + native-trend 31 jours juillet, 16/09
Packet #115 — proof of end-to-end closure (deployed + live-verified).
- PR fix(responses): map input_tokens_details.cached_tokens to cache_read_input_tokens (#115) #117 merged by the user 2026-09-16 11:09:32Z → issue Responses wire drops usage.input_tokens_details.cached_tokens — la lane Sol/Codex est aveugle au cache #115 auto-closed (
Closes #115). - Deployed in the 2026-09-17 02:14:16Z hub recreate (image
905b12built 02:10:21Z on mainf150c7d; batch GLM 5.3 + fix(responses): map input_tokens_details.cached_tokens to cache_read_input_tokens (#115) #117 + Kimi reorder; ACKed deploy by po-2025). - Measured verification (po-2025 cycle-27 report, 2026-09-17 03:04Z): post-deployment Sol-lane captures carry
cache_read_input_tokenswith real values — 180,352 / 181,504 on 2 requests (first pass at 0, expected: cold context). The field did not exist on the Responses lane before the fix.
Dossier closed per the 2026-09-12 mandate (merge ≠ FAIT; FAIT = measured per-consumer verification in-session). Evidence relayed by po-203.
🤖 Generated with Claude Code
- PR fix(responses): map input_tokens_details.cached_tokens to cache_read_input_tokens (#115) #117 merged by the user 2026-09-16 11:09:32Z → issue Responses wire drops usage.input_tokens_details.cached_tokens — la lane Sol/Codex est aveugle au cache #115 auto-closed (
- added a commit that references this issue
on Sep 17, 2026 [P1] Série jour × lane sur 14 jours (22/09 → 05/10), depuis le store lane-series.sqlite — [po-203], même session
Provenance : archives 7z du namespace partagé GDrive (non taguées = hub po-2025, +
*-po-2023/*-po-2026taguées, sommées par jour post-#203) + jour courant en loose. Ingest 14 jours en 15,9 s, 0 jour archive-présente-zéro-réponse (une panne de lane reste distinguable d'un trou de collecte).lane 09-22 09-23 09-24 09-25 09-26 09-27 09-28 09-29 09-30 10-01 10-02 10-03 10-04 10-05 openai|glm-5.3 13922 13502 11631 12414 12452 15997 14539 16570 15781 14578 17784 17983 18674 1 anthropic|MiniMax-M3 9237 4837 8784 9108 10014 49575 13631 6926 12047 15660 16557 11347 1386 0 native|claude-opus-5-5 5112 19595 8140 5607 4380 5175 4487 5649 3505 3001 4383 4146 4846 0 openai|deepseek-flash 3802 0 192 9337 5338 8862 0 0 0 0 999 449 10791 0 anthropic|deepseek-v4.1-fla 0 5767 3171 6338 0 0 5348 5701 1529 0 1119 682 621 0 responses|gpt-6-sol 0 621 2436 0 3627 6005 3132 616 1204 1027 1635 0 0 0 openai|glm-5.2 1655 1511 1331 1503 1749 1858 1885 1930 1947 1811 1515 608 260 1 anthropic|k3 2996 354 1539 3888 0 0 0 3144 0 0 3384 0 0 0 anthropic|deepseek-v4-flash 0 3580 45 2 0 0 0 0 0 1 3 0 0 0 anthropic|kimi-for-coding 0 0 0 0 0 0 0 0 0 2451 465 0 0 0 responses|gpt-6.1-sol 0 0 0 0 0 0 0 0 0 0 581 1050 1100 0 native|claude-opus-5 2313 0 0 0 0 0 0 0 0 0 0 0 0 0 openai|zai-glm-5-3 0 0 0 0 0 0 0 0 0 0 993 0 0 0 responses|gpt-5.6-sol 292 3 0 0 0 0 0 0 0 0 0 0 0 0 TOTAL 39429 49791 37325 48221 37581 87522 43056 40624 36088 38621 49512 36302 37717 2(31 lanes distinctes sur la fenêtre, top 14 affiché ; le store couvre désormais 119 jours · 49 lanes — requêtable à
D:\claudish-captures\lane-series.sqlite, CSV complet exportable par--csv.)Lectures factuelles (pas d'interprétation causaliste — à croiser avec les journaux failover par qui veut creuser) :
- glm-5.3 = lane dominante chaque jour, en croissance : 13 922 → 18 674 (+34 % du 22/09 au 04/10), minimum 11 631 — jamais détrônée.
- Pic MiniMax-M3 le 27/09 : 49 575 (×3,6 vs voisinage 10-13 k) — la plus grosse journée lane de la fenêtre, jour qui porte aussi le TOTAL max (87 522).
- deepseek-flash : trou de 7 jours (0 du 23/09 au 29/09 après 3 802 le 22/09), retour discret le 02/10 (999), 10 791 le 04/10.
- kimi-for-coding apparaît le 01/10 (2 451) — cohérent avec la cascade HAIKU
kc@kimi-for-codingdu déploiement hub post-feat(failover): role-as-failover-step - a cascade step can delegate to another role #274 (02/10 04:21Z, la lane a dû tourner en amont sur le hub de prod ou par les settings AVANT le déploiement formel — à ne pas conclure sans croiser, la date exacte du premier kimi dans les captures est le 01/10). - Le 10-05 n'est PAS un effondrement : jour courant en loose uniquement (2 réponses = les artefacts d'épisodes AUTONOMOUS du relais po-203, classification sur Transport errors during local serving bypass the cascade (client 400 while fallback steps reachable) — measured 23:49-23:54Z #298) — l'archive du jour n'existe pas encore, la ligne se remplira au pack de 02:47Z.
native|claude-opus-5(id sans suffixe) présent uniquement le 22/09 (2 313) — trace du pin de version pré-fix(proxy): pin the native lane to the configured role model #218.
🤖 Generated with Claude Code
[P1 suivi] La ligne 10-05 est remplie — le pack 02:47Z a tenu la promesse du commentaire du 05/10 (ingest idempotent
lane-matrix.py, store désormais 120 jours · 49 lanes, 0 jour archive-présente-zéro-réponse) :lane 10-04 10-05 openai|glm-5.3 18674 18026 anthropic|MiniMax-M3 1386 14045 openai|deepseek-flash 10791 9847 native|claude-opus-5-5 4846 6471 responses|gpt-6.1-sol 0 1572 anthropic|k3 0 1254 openai|glm-5.2 260 376 openai|glm-4.7 0 19 openai|glm-5.3-flash 0 10 openai|qwen3.6-35b-a3b 0 9 TOTAL 37717 51629Lectures factuelles :
- Le 10-05 n'était pas un effondrement — c'est le 2ᵉ plus gros jour de la fenêtre 14 j (51 629, derrière le 27/09 à 87 522) : MiniMax-M3 remonte à 14 045 (×10 vs 10-04) et deepseek-flash confirme sa résurgence (9 847 après 10 791 — deux jours consécutifs ~10 k après 7 jours à 0).
k3sert 1 254 réponses le 10-05 — cohérent avec la 2ᵉ marche sonnet observée en session ce jour-là.- La ligne 10-06 (loose, 2 réponses = artefacts AUTONOMOUS du relais po-203) suivra le même cycle : archive au pack 02:47Z, la ligne se remplira d'elle-même.
🤖 Generated with Claude Code
EPIC parapluie — Datastudy consommation flotte : dashboard, séries temporelles multi-lanes, dettes & leviers
Mandat (user, 15/09) : « élargir en un vrai travail de datascience qui doit viser la constitution d'un dashboard avec graphiques et interprétations pour nous expliquer, en utilisant les métriques des différents workspaces des projets communs (traffic, issues, merges, diff LOC, nb messages, nb appels d'outils, LOC des commentaires d'issues, des reviews, verbosité générale etc.) et ceux spécifiques aux projets (messages nanoclaw/hermes, nb Notebooks / nb de lignes ajoutées ou supprimées spécifiquement aux notebooks…). Il me semble que si tu collectes le max de données dans le temps, tu devrais avec les bons outils […] pouvoir conduire l'investigation sur les dettes qu'on paye, et les leviers d'amélioration de nos perf et de nos coûts. »
Deuxième mandat, même jour — le modèle de coût et le point d'arrivée décisionnel (§4bis et P5) : « on devrait avoir une idée de ce que le token coûte réellement pour nos souscriptions » … « cibler les crons idéaux avec les protocoles de coordination optimaux, pour chaque projet, et donc décider ceux qu'on ralentit car leur veille ne produit pas de nouveauté intéressante. »
Issue parapluie : elle englobe #41, #60 et #102 (liées en sub-issues), ainsi que les épics roo-extensions qui touchent la même chaîne (#3647, #1980, #1997, #2336, #3293, #3381, #3111). Elle ne les remplace pas : elle porte le livrable commun (le dashboard + ses interprétations) et la boucle de mesure qui les alimente tous.
Marquage des affirmations :
[M]mesuré (chiffre reproductible, source citée) ·[I]inféré ·[?]non tranché.1. Pourquoi un parapluie, et pourquoi maintenant
Trois constats mesurés cette semaine rendent la fragmentation coûteuse :
[M]Les organes de mesure ne regardent que ~4 % du trafic. La lane native (facturée Anthropic) est la seule instrumentée en profondeur (native-consumption.py,native-trend.py,billed-attrib.py) — or elle ne représente plus que 4,27 % des réponses servies au 14/09 (contre 14,79 % au 08/09). Toute conclusion tirée des organes actuels est une conclusion sur la queue de la distribution.[M]Le poste de coût a changé de nature sans que personne ne le voie venir. Sur les archives du hub,openai-deepseek-flash(PAYG, facturé à l'usage) passe de 0 réponse le 08/09 à 13 103 le 13/09, pendant que le volume total reste plat (~19 k → ~34 k réponses/jour). Le PAYG n'est plus un appoint : c'est une lane de premier plan.[M]Il n'existe aucun prix local.pricing-cache.jsonest absent de po-2025 etall-models.json(358 entrées) ne porte aucun champpricing→ nous ne pouvons pas calculer notre propre coût, seulement lire des consoles fournisseur qui ne sont ni par-machine ni par-workspace. C'est le blocage n°1 du dashboard.Aucune de ces trois choses n'appartient à un seul des épics existants. Le parapluie est le lieu où elles se rejoignent.
2. Baseline mesurée (point de départ de toutes les séries)
2.1 Matrice lane × jour — archives hub
G:\Mon Drive\Backups-Cloud\claudish\captures-*.7z[M]⚠ Les sept jours d'archive sont muets sur la lane Sol (
responses-gpt-5.6-sol) — non par choix, mais par bug de capture, corrigé le 14/09 21:42Z (#90). Voir §5.2 : toute courbe Sol doit démarrer après cette date.2.2 Tokens par lane — 15/09 (journée partielle, captures non compactées)
[M]OUTmoyen par réponse : 802 tokens.Trois faits à retenir : (a) le PAYG DeepSeek lit 964 M tokens de cache — il n'est pas un appoint, il porte la mémoire chaude du parc ; (b) la lane Sol brûle 109 M d'input sans un seul token de cache (#115) ; (c)
nplat avecOUT×4,5 àncomparable (09-09 : n=1 476 / 2,09 M OUT vs 09-13 : n=1 494 / 9,42 M OUT) → l'inflation est dans ce que le modèle écrit, pas dans le nombre d'appels.2.3 Ce que la flotte produit (dénominateur du coût)
[M]D:\claudish-captures: 47 457 fichiers / 13,7 Go.2.4 Instruments déjà livrés (à réutiliser, pas à réécrire)
[M]scripts/traffic-consumption.pyscripts/traffic-mxws.py(day, reqN))scripts/harness-injection-measure.pyscripts/native-consumption.py·native-trend.py·billed-attrib.pyscripts/per_action.py·tool_mix.py·cmd_intent.pyscripts/harness-mcp-audit.py·harnesscmp.pyclaudish_traffic(#72)scripts/compress-captures.ps1·claudish-watchdog.ps1·claudish-drain.ps13. Les métriques à collecter
3.1 Socle commun (toutes les workspaces)
traffic-consumption.py,traffic-mxws.pyharness-injection-measure.py3.2 Spécifique projet
*.ipynbdiff)4bis. Économie des souscriptions — le modèle de coût (P0)
Recadrage du user (15/09) : « Pour ce qui est du calcul du coût réel, il devrait être facile d'identifier dans les logs d'activité les périodes où les providers étaient maxés, sur le débit 5h ou sur le débit hebdo. Pour peu qu'on ait une consistance dans la formule qui permet de pondérer les tokens par les multiplicateurs d'heures pleines, on devrait avoir une idée de ce que le token coûte réellement pour nos souscriptions. »
Conséquence : le blocage « pas de table de prix » (§5.3) n'est pas un blocage. Il n'y a pas besoin de tarifs publics pour savoir ce qu'un token nous coûte — il y a besoin de la position de la consommation courante par rapport à la borne de chaque souscription, que nos propres logs contiennent déjà.
4bis.1 Le principe (corrigé le 15/09 sur précision du user — v1 reformulait de travers)
Pour une lane forfaitaire, le coût marginal d'un token est nul jusqu'à la borne, puis la cascade bascule. Le point clé, celui que le mur nous donne gratuitement : c'est quand un forfait maxe qu'on connaît sa borne réelle en tokens. Chaque mur, daté et mis en regard de ce qui a été consommé dans la fenêtre, est une mesure de la capacité effective du forfait — pas une panne à subir.
La borne étant mesurée événement par événement, le modèle s'obtient par extrapolation :
Le corollaire opérationnel est plus utile que le chiffre : une souscription n'est pas chère ou bon marché en absolu — elle l'est par rapport à sa borne, et la borne est datée. D'où l'exigence d'exhaustivité des murs (§5.4) : sans la date de reset, « 40 % de la conso hebdo » ne veut rien dire.
4bis.2 Les murs à instrumenter (état de connaissance)
gc@Coding)messagenommant l'heure de reset (UTC+8 → convertir)Un mur 402/429/529 n'est pas une panne du hub — c'est une donnée de mesure, et c'est précisément le signal d'entrée du modèle de coût.
Inventaire clos (user, 15/09) : la liste ci-dessus est complète.
OPENROUTER_API_KEYprésent dans la config du hub n'est pas dans le trousseau de failover — présence en config ≠ appartenance à la cascade ; ne pas le compter au dénominateur.4bis.3 Générosité observée — verdicts du user, à convertir en séries mesurées
[R]rapporté par le user le 15/09, non encore re-mesuré — chaque ligne doit devenir une courbe :Le fait à retenir : le user relie explicitement la montée en vitesse du mur GLM à l'explosion des coûts DeepSeek, « même avec Kimi ». C'est exactement l'hypothèse que §5.1 laissait non tranchée, et elle est désormais falsifiable : il s'agit de corréler les événements de mur GLM (429 code 1308 horodatés) aux pics de
openai-deepseek-flash. Si la corrélation tient, le levier n'est pas « réduire DeepSeek » — c'est lisser la consommation GLM sur la fenêtre de 5 h. (À noter : le hub est aveugle à une partie de ces événements, une requête servie localement par un sidecar AUTONOMOUS n'écrit aucune capture — la corrélation devra être faite côté hub et côté relais.)4bis.4 Contrainte de méthode
Le user insiste sur « une consistance dans la formule ». C'est la vraie exigence, et elle est plus dure qu'elle n'en a l'air : une formule qui change de convention entre deux jours produit une courbe qui bouge sans que rien ne bouge. La formule de pondération (multiplicateurs heures pleines/creuses, traitement du cache, agrégation IN/OUT) doit être écrite, versionnée, datée et identique d'un bout à l'autre des séries — au prix, s'il le faut, de recalculer l'historique plutôt que de mélanger deux conventions.
4bis.5 Le point d'arrivée revendiqué
« Tout ça devra s'étudier avec le max de métriques permettant de caractériser tous les gisements de consommation des différents consommateurs. Et ça tu vas le voir dans tes traces et dans les artefacts des projets. »
Autrement dit : les traces du hub (qui consomme, où, quand, sous quel harnais) croisées avec les artefacts des projets (ce que la consommation a produit) — c'est ce croisement qui donne P5.
4. Livrable : le dashboard
Forme : un artefact reproductible, alimenté par un script versionné, régénéré hors pointe (fenêtre 05-07Z uniquement — incident 2026-08-26 : un job d'analyse en journée a dégradé le hub 40 min). Sorties : séries temporelles + interprétations écrites, pas seulement des chiffres.
Contraintes dures :
Phases :
-native-: la matrice §2.1 doit devenir un organe récurrent, pas un script ad-hoc de session. Y adjoindre la détection des fenêtres saturées (mur 5 h, mur hebdo) — c'est l'entrée du modèle de coût de P0.5. Dettes identifiées (chacune devra être chiffrée en P4)
5.1 Le poste PAYG a changé de nature sans décision explicite — hypothèse désormais posée et falsifiable
openai-deepseek-flashpasse de 0 à 13 103 réponses/jour en cinq jours. Le user avance le mécanisme le 15/09 : GLM maxe de plus en plus vite sur sa fenêtre de 5 h, et le débordement part sur DeepSeek — « même avec Kimi » (§4bis.3). C'est cohérent avec tout ce qu'on mesure : PAYG = pas terminal de la cascade, et la lane Kimi n'est entrée en service que récemment.Mais c'est une hypothèse, pas une mesure. Elle se teste : corréler les événements de mur GLM (429 code 1308, horodatés) aux pics de
openai-deepseek-flashsur la même fenêtre, et vérifier que la montée du PAYG suit la montée en vitesse du mur plutôt que le volume total (qui, lui, est plat).L'enjeu de la réponse est décisif, parce qu'elle change le levier : si l'hypothèse tient, la cible n'est pas la lane DeepSeek mais la forme de la consommation GLM dans la fenêtre de 5 h — un problème de lissage de cadence, pas de forfait.
5.3 Le prix n'est pas introuvable — il n'est pas au bon endroit
pricing-cache.jsonest absent de po-2025 etall-models.json(358 entrées) ne porte aucun champpricing. Ce n'est pas un blocage pour autant : voir §4bis — le coût réel se dérive de la position par rapport aux bornes, pas d'une grille tarifaire.Ce qui reste vrai, et qui doit être dit à chaque fois qu'un tableau est publié : tant qu'on ne dispose que de tokens, les comparaisons inter-lanes sont biaisées — elles flatte les lanes forfaitaires (coût marginal nul à court terme, mur invisible) et pénalise les PAYG (facturés à l'unité). Le biais va exactement dans le sens inverse de ce qu'il faut pour décider.
5.2 La lane Sol était aveugle, par bug, pas par politique
[M]#90 (fermée 14/09 21:42Z) :createResponseCapturen'était pas câblé dansopenai-responses-sse.ts→ aucune captureresp-sur la lane Sol/Codex. L'absence totale de Sol dans les 7 jours d'archive n'est donc pas un fait de consommation : c'est un fait d'instrumentation. Les 585 réponses Sol du 15/09 (109 M d'input, 0 cache) sont réelles, mais leur trajectoire n'est pas lisible dans les archives — toute courbe Sol doit démarrer au 14/09 21:42Z, jamais avant.[M]#115 (ouverte 15/09) : le wire Responses perdusage.input_tokens_details.cached_tokens→ la lane reste aveugle au cache même après #90. Un chiffre « 0 % de cache » sur cette lane est un artefact d'instrument, pas une mesure.5.3 Le prix est introuvable localement
Voir P0. Tant que c'est vrai, les comparaisons inter-lanes sont des comparaisons de tokens, ce qui flatte les lanes forfaitaires (coût marginal nul à court terme) et pénalise les lanes PAYG — l'inverse exact de ce qu'il faut pour décider.
5.4 Les organes sous-échantillonnent de deux ordres de grandeur
Les organes historiques filtrent
-native-. Le hub sert ~30 000 réponses/jour ; natif en représente ~4 %. Un tableau natif-centré est un tableau faux-mais-plausible : il est exact sur son périmètre et trompeur sur la flotte.5.5 La rétention croît plus vite que la capacité d'analyse
≈ ×2/mois (0,7 → 3,6 Go). La donnée n'est pas le goulot — l'organe qui la lit l'est.
6. Ce que cet épic n'est PAS (anti-doublon)
7. Critères d'acceptation
[R]— jamais présentés comme des faits établis.[M]/[I]/[?], avec sa source reproductible.8. Terrains et garde-fous
[PROPOSAL]puis[ACK]de la coordination ai-01 ; une absence de réponse ne vaut jamais validation.--env-file D:\claudish-shadow\.env(préflightdocker compose config+ vérification des sources de bind).