J’ai créé un outil proxy qui permet de voir sous quelle forme Claude Code envoie `CLAUDE.md` au serveur et transmet le texte brut des skills.

En travaillant avec Claude Code, je me suis soudain demandé comment le serveur Claude perçoit des données comme le fichier CLAUDE.md, les skills, ou encore rules / memory.

J’ai donc créé moi-même un proxy MITM, ainsi qu’un outil permettant d’inspecter le trafic.

Le principe consiste à modifier la baseURL au lancement de Claude Code afin de capturer et d’afficher les communications HTTP générées dans Claude Code.

Voici ce que cet outil a permis de découvrir.

Même un simple hello embarque 12 KB

• Il s’agit de ce qui se passe lorsqu’on envoie hello juste après avoir lancé Claude Code.
• content[0] contient la liste des skills sur ~2 KB, content[1] contient CLAUDE.md sur ~10 KB, et content[2] contient le texte réellement saisi, hello.
• Autrement dit, si CLAUDE.md fait 500 lignes, il est renvoyé en entier à chaque requête, ce qui explique pourquoi il faut le garder concis.

Plus la conversation s’allonge, plus chaque requête grossit en boule de neige

• L’ensemble de messages[] est renvoyé à chaque requête. — 15 KB au 1er tour, 200 KB au 10e, 1 MB+ au 30e
• Même les réponses de Claude sont incluses dans les messages de requête.
• Cela montre que si l’on ne fait pas régulièrement /clear sur la fenêtre de contexte, on gaspille des tokens et les anciens échanges continuent à s’accrocher aux suivants, ce qui peut dégrader les performances.

Les outils MCP ne sont chargés qu’au moment où ils sont nécessaires

• Au départ, seuls N outils intégrés sont chargés (cela varie selon la version de Claude), puis lorsqu’il faut utiliser un outil MCP, le serveur appelle ToolSearch pour trouver l’outil à utiliser.
• Ensuite, les outils trouvés ci-dessus sont ajoutés aux appels suivants.
• Autrement dit, comme les outils MCP sont chargés dynamiquement, les outils MCP jamais utilisés n’entraînent pas réellement une grosse consommation de tokens.

Les sous-agents s’exécutent dans un contexte totalement isolé

• Un sous-agent revient à ouvrir une nouvelle session sans aucun historique de la conversation parente.
• Dans l’Inspector, vous pouvez comparer visuellement côte à côte les appels du parent et du sous-agent.

Une seule image jointe ajoute plusieurs centaines de KB

• Lorsqu’on joint une capture d’écran, elle est encodée en base64 puis insérée inline dans le corps JSON.
• Il est possible de voir en temps réel dans quelle mesure l’image augmente la taille de la requête.

---

Vous pouvez l’installer avec la commande ci-dessous.

brew install --cask kangraemin/tap/claude-inspector && sleep 2 && open -a "Claude Inspector"   

GitHub: https://github.com/kangraemin/claude-inspector

Pour l’instant, c’est réservé à macOS et c’est encore une version initiale, donc je serai très réceptif à toute suggestion d’amélioration.

J’espère que vous l’essaierez et que cela vous aidera dans votre apprentissage, merci !

[winterjung]

Dans l’article suspiciously precise floats, or,
how I got Claude's real limits, il y avait une analyse selon laquelle, contrairement au coût via l’API, il n’y aurait pas de coût de lecture du cache dans l’offre par abonnement. J’ai aussi l’impression que, plus la session est longue, plus il peut y avoir un certain écart entre le coût calculé et le coût réel.

[remin1994]

Oh… je n’avais pas du tout vu ce post… je vais vérifier ça ! Merci

[kgcrom]

https://github.com/badlogic/lemmy/tree/main/apps/claude-trace
J’ai regardé avec ça le prompt et quels outils étaient utilisés, mais il va falloir que j’essaie aussi celui que vous avez créé.
Merci pour le partage. :+1:

[remin1994]

En complément, après la requête, vous pouvez voir dans la réponse le volume de tokens utilisés pour cette requête !

Modèle : claude-sonnet-4-6
Taille de la requête : 68.9 KB

"usage": {
"input_tokens": 3,
"cache_creation_input_tokens": 12394,
"cache_read_input_tokens": 6499,
"cache_creation": {
"ephemeral_5m_input_tokens": 0,
"ephemeral_1h_input_tokens": 12394
},
"output_tokens": 74,
"service_tier": "standard",
"inference_geo": "not_available"
}

J’ai aussi calculé le coût par requête en appliquant la tarification par modèle, donc n’hésitez pas à l’utiliser haha

Lecture du cache : 6.5K tok × $0.3/MTok = $0.0019
Écriture du cache : 12.4K tok × $3.75/MTok = $0.0465
Entrée non mise en cache : 3 tok × $3/MTok = $0.0000
Sortie : 74 tok × $15/MTok = $0.0011

Total : $0.0495
Taux de réussite du cache : 34%