04 Seeing what Claude Code actually sent

Why I built it

In February, a lot of us started noticing weird answers and actions from Claude. I knew the model wasn’t updated, but Claude Code was getting new releases. I wanted to find out what was going on. Perhaps something was updated in the system prompt.

If you know Claude, you know its calls to Anthropic carry a system prompt block, but there are multiple system prompts: a billing header, which is just boring, a server/Claude system prompt, then your system prompt. If you’ve ever used the flag to override the system prompt, you overrode that last prompt and not the “harness” one. I started digging into that prompt and realized I couldn’t really change it, as it came from Claude. To see it and interact with it, I’d need to build a way to capture and change it. I wanted to poke the thing and see what happened.

There was prior art like mitmproxy. I tried it but it didn’t work as well as I liked, so using an abundance of Dunning-Kruger, I started building mike.

I realized also while building mike, that it could also give me a level of insight into my sessions that the transcripts in your global ~/.claude folder just would never be able to provide easily.

What it does

mike is a set of tools and systems that runs on your own machine, between Claude Code and Anthropic. mike claude starts Claude Code routed through it, and from then on every request and answer of that session is stored in the capture db (if you turned that on). Open http://localhost:9990 and the session is under Sessions, updating as you work: the system prompt, the prompt you typed, each tool call with its result, and the streamed answer, turn by turn. Search finds a past turn by the text of a request or an answer.

There are a bunch of other tools in mike, like steerers, judges, tool captures, comms systems, fleet systems, embedding, semantic retrieval, an MCP to get all the information back and full history of all the sessions that it’s captured.

A fresh install only records. It forwards your requests unchanged and sends nothing to anyone but Anthropic. It marks replies that claim something they did not check, blame something else or skip the work, and you can tell Claude to record a correction as a lesson. Everything that changes a request is off until you turn it on: handing those lessons to later sessions, steerers that notice a session drifting from its goal, and filter rules that rewrite the system prompt. When one of them changes a request, mike shows the original beside what was sent.

mike-mcp, the companion program, gives a Claude Code session tools to search that history, so Claude can look up which session changed a file instead of guessing. mike can also start Claude Code sessions, carry messages between them, and run a fleet: several sessions working on one goal in one checkout, each with its own task.

Install it with brew install temet-ai/mike/mike temet-ai/mike/mike-mcp, run mike setup to choose where history is kept, then mike claude. It runs on Apple Silicon Macs and on Linux x86_64 with glibc 2.35 or newer.

How I built it

mike is Rust. One program forwards and records, and serves the web UI, which is written in Svelte. History is kept in PostgreSQL, which mike can run for you in Docker, or in memory for a first look. mike-mcp is a second, small program that reads the same history through mike’s local API.

I built it with Claude Code, and mike recorded those sessions as it recorded the others. Fleets came out of that work: my own take on running several full sessions on one goal. The measured findings on this site come out of what mike recorded.

mike is in alpha. Capture your first session, or read the source.