I'm...rather confused why the results here are surprising. The title and first paragraph are suggestive of unusual data like analytics or sending all your codebase, but it's just sending the prompt + context.
This is how every LLM API has worked for years; the API is a stateless token machine, and the prompts + turns are managed by the client application. If anything it's interesting how standard it is; no inside baseball, they just use the normal public API.
I built a MITM proxy to inspect Claude Code’s network traffic and was surprised by how much context is sent on every request. This is Part 1 of a 4-part series focusing only on the wire format and transport layer. Happy to answer technical questions.
Seems a bit obvious all the information claude code would send to the llm would be sent to Anthropic no? Isn’t that the point of using it via Azure or AWS Bedrock, for the guarantees of secrecy they provide you?
yes, it's obvious the data goes to Anthropic. What wasn't obvious to me was what exactly is included and how it's structured: system prompt size, full conversation replay, file contents, git history, tool calls. The goal was to understand how the wire level works.
On Azure/Bedrock - good point! My understanding is that they route requests through their infrastructure rather than Anthropic directly, which does change the trust boundary, but my focus here was strictly on what the client sends, that payload structure is the same regardless of backend.
I am surprised that... if they have a session ID of some sort for your chat that they make you re-send the entire message history each time? Not a single kind of cache or stateful proxy/buffering mechanism? Guessing that extra cost in bandwidth is cheaper than having to develop and maintain that? Seems kind of like an obvious optimization/design tradeoff they could eventually decide to change one day?
I feel it has to be something bigger, if they’re just taking client side input for the system prompt seems like a security issue. Doesn’t this mean I could reprogram Claude at its core?
I'm...rather confused why the results here are surprising. The title and first paragraph are suggestive of unusual data like analytics or sending all your codebase, but it's just sending the prompt + context.
This is how every LLM API has worked for years; the API is a stateless token machine, and the prompts + turns are managed by the client application. If anything it's interesting how standard it is; no inside baseball, they just use the normal public API.
I've been waiting for someone to dig into this more deeply! Looking forward to Part 2!
I use both Claude Code and Xcode with a local LLM (running with LM Studio) and I noticed they both have system prompts that make it work like magic.
If anyone reading this interested in setting up Claude Code to run offline, I followed these instructions:
https://medium.com/@luongnv89/setting-up-claude-code-locally...
My personal LLM preference is for Qwen3-Next-80B with 4bit quantization, about ~45GB in ram.
I built a MITM proxy to inspect Claude Code’s network traffic and was surprised by how much context is sent on every request. This is Part 1 of a 4-part series focusing only on the wire format and transport layer. Happy to answer technical questions.
This is great! Would love to see if Opencode sends different payloads and hoe they differ.
Seems a bit obvious all the information claude code would send to the llm would be sent to Anthropic no? Isn’t that the point of using it via Azure or AWS Bedrock, for the guarantees of secrecy they provide you?
yes, it's obvious the data goes to Anthropic. What wasn't obvious to me was what exactly is included and how it's structured: system prompt size, full conversation replay, file contents, git history, tool calls. The goal was to understand how the wire level works. On Azure/Bedrock - good point! My understanding is that they route requests through their infrastructure rather than Anthropic directly, which does change the trust boundary, but my focus here was strictly on what the client sends, that payload structure is the same regardless of backend.
Specifically do you mean when you say git history is sent? How much of it is included in each request?
That makes sense :) Cool analysis!
thank you!
I am surprised that... if they have a session ID of some sort for your chat that they make you re-send the entire message history each time? Not a single kind of cache or stateful proxy/buffering mechanism? Guessing that extra cost in bandwidth is cheaper than having to develop and maintain that? Seems kind of like an obvious optimization/design tradeoff they could eventually decide to change one day?
I feel it has to be something bigger, if they’re just taking client side input for the system prompt seems like a security issue. Doesn’t this mean I could reprogram Claude at its core?