HN Reader

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.

Here's a related issue that took me a whole day to figure out why Claude Code telemetry pings were causing a total network failure when using CC with a local LLM via llama-server.

I wanted to use local LLMs (~30B) on my M1 Macbook Pro Max, with Claude Code for a privacy-sensitive project. I spun up Qwen3-30B-A3B via llama-server and hooked it up to Claude Code, and after using it for an hour or so, found that my network connectivity got totally borked: browser not loading any web-pages at all.

Some investigation showed that Claude Code assumes it's talking to the Anthropic API and sends event logging requests (/api/event_logging/batch) to the llama-server endpoint. The local server doesn't implement that route and returns 404s, but Claude Code retries aggressively. These failed requests pile up as TCP connections in TIME_WAIT state, and on macOS this can exhaust the ephemeral port range. So my browser stopped loading pages, my CLI tools couldn't reach the internet, and the only option was to reboot my macbook.

After some more digging (with Claude Code's help of course) I found that the fix was to add this setting in my ~/.claude/settings.json

    {
    // ... other settings ...
     "env": {
        "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
     }
    // ... other settings ...
    
   }

I added this to my local-LLM + Claude Code/ Codex-CLI guide here:

https://github.com/pchalasani/claude-code-tools/blob/main/do...

I don't know if others faced this issue; hopefully this is helpful, or maybe there are other fixes I'm not aware of.

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 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?

This is great! Would love to see if Opencode sends different payloads and hoe they differ.