Ich habe ein Proxy-Tool gebaut, mit dem man sehen kann, in welcher Form Claude Code `CLAUDE.md` an den Server sendet und wie die ursprünglichen Skills übertragen werden.

Als ich mit Claude Code gearbeitet habe, kam mir plötzlich die Frage: Wie erkennt der Claude-Server eigentlich Daten wie die Datei CLAUDE.md, Skills oder Dinge wie Rules / Memory?

Deshalb habe ich selbst einen MITM-Proxy gebaut und ein Tool erstellt, mit dem man den Traffic einsehen kann.

Das Prinzip ist, dass beim Ausführen von Claude Code die baseURL geändert wird, sodass die innerhalb von Claude Code stattfindende HTTP-Kommunikation abgefangen und angezeigt werden kann.

Mit diesem Tool konnte ich Folgendes herausfinden.

Schon ein einziges hello schickt 12 KB mit

• Das ist die Situation direkt nach dem Start von Claude Code, wenn hello gesendet wird.
• Es werden content[0] mit der Skill-Liste (~2 KB), content[1] mit CLAUDE.md (~10 KB) und content[2] mit dem eigentlichen Eingabetext hello gesendet.
• Wenn CLAUDE.md also 500 Zeilen hat, wird sie bei jeder Anfrage komplett übertragen. Das ist der Grund, warum CLAUDE.md möglichst kompakt bleiben sollte.

Je länger die Unterhaltung wird, desto stärker wächst jede Anfrage wie ein Schneeball

• Bei jeder Anfrage wird das gesamte messages[] erneut übertragen. — 1 Turn 15 KB, 10 Turns 200 KB, 30 Turns 1 MB+
• Sogar die Antworten von Claude selbst werden als Request-Messages mitgeschickt.
• Wenn man das Kontextfenster nicht regelmäßig mit /clear zurücksetzt, werden nicht nur Tokens verschwendet, sondern frühere und spätere Kontexte hängen ständig zusammen, was zu Leistungseinbußen führen kann.

MCP-Tools werden nur bei Bedarf geladen

• Anfangs werden nur die integrierten N Tools geladen (je nach Claude-Version unterschiedlich). Falls ein MCP-Tool benötigt wird, ruft der Server ToolSearch auf, um ein verwendbares Tool zu finden.
• Danach werden die so gefundenen Tools bei weiteren Aufrufen zusätzlich eingebunden.
• Da MCP-Tools also dynamisch geladen werden, verursachen ungenutzte MCP-Tools tatsächlich keinen großen Tokenverbrauch.

Sub-Agents laufen in vollständig isolierten Kontexten

• Ein Sub-Agent entspricht dem Öffnen einer neuen Sitzung ganz ohne Verlauf der übergeordneten Unterhaltung.
• Im Inspector kann man die beiden Aufrufe von Parent und Sub-Agent nebeneinander direkt visuell vergleichen.

Ein einzelner Bildanhang fügt mehrere hundert KB hinzu

• Wenn man einen Screenshot anhängt, wird er Base64-kodiert und inline in den JSON-Body eingefügt.
• Man kann in Echtzeit prüfen, wie stark Bilder die Anfrage vergrößern.

---

Mit dem folgenden Befehl kann man es installieren.

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

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

Aktuell ist es noch nur für macOS verfügbar und eine frühe Version. Wenn ihr Verbesserungsvorschläge habt, nehme ich sie gern auf.

Probiert es aus — ich hoffe, es hilft euch beim Lernen. Danke!

[winterjung]

Im Artikel suspiciously precise floats, or,
how I got Claude's real limits gab es offenbar die Analyse, dass es im Abo-Modell anders als bei den API-Kosten keine Kosten für Cache-Lesevorgänge gibt. Je länger die Sitzung dauert, desto größer könnte die Abweichung zwischen den berechneten und den tatsächlichen Kosten sein.

[remin1994]

Oh … diesen Beitrag kannte ich überhaupt nicht … Ich werde ihn mir einmal ansehen! Vielen Dank

[kgcrom]

https://github.com/badlogic/lemmy/tree/main/apps/claude-trace
Damit habe ich mir den Prompt und die verwendeten Tools angesehen; ich sollte wohl auch mal das von Ihnen Erstellte ausprobieren.
Vielen Dank fürs Teilen. :+1:

[remin1994]

Zusätzlich kann man nach der Anfrage in der Response die für diese Request verwendete Token-Menge sehen!

Modell: claude-sonnet-4-6
Anfragegröße: 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"
}

Außerdem habe ich unter Anwendung der modellabhängigen Preise auch die Kosten pro Request berechnet, also nutzt es bitte viel haha

Cache-Lesen: 6.5K tok × $0.3/MTok = $0.0019
Cache-Schreiben: 12.4K tok × $3.75/MTok = $0.0465
Nicht gecachte Eingabe: 3 tok × $3/MTok = $0.0000
Ausgabe: 74 tok × $15/MTok = $0.0011

Gesamt: $0.0495
Cache-Trefferquote: 34%