Fifteen thousand tokens can disappear before Claude reads a single line of your code. Not from your prompt, not from the file you’re editing, just from tools sitting quietly configured in the background. A Redditor over on r/PromptEngineering decided to actually watch where the money goes instead of guessing, and the breakdown is worth your attention.
What’s new
The original poster set up local proxy capture to intercept the real API payloads Claude Code sends on every turn. Not the after-the-fact log summary most usage trackers give you, the actual wire traffic, request by request, byte by byte. From that they mapped out five places your token budget quietly leaks: MCP tool schemas re-sent on every single call, prompt cache misses that kill your 90% discount, extended thinking blocks that can run 4x bigger than the code they produce, old tool output (like a 500-line test log) that sits in context until compaction, and the compaction step itself, which has to read your bloated context in full before it can shrink it. None of these show up on a typical dashboard because most usage trackers only show you the final bill, not the path the tokens took to get there.
To make all this visible instead of theoretical, the creator built and open-sourced a tool called “cost-xray.” It captures local traffic for both Claude Code and Codex, attributes every token back to its source (MCP servers, system prompt, thinking, cache reads and writes), and graphs your context window occupancy turn by turn. It runs entirely on your machine. No telemetry, no external API key required, no data leaving your laptop. You install it, point it at your existing sessions, and it starts logging the same requests your terminal is already sending, just with the receipts attached this time.
The twist
Here’s the part that catches people off guard: the model doesn’t even need to touch your code to cost you money. If you’re running 4 or 5 MCP servers, their tool schemas get attached to every request, whether you use them that turn or not. That’s 15,000 to 25,000 input tokens spent just defining what’s available before any actual work happens. Run a quick one-line fix through a session with five MCP servers connected and you’ll find the tool definitions alone can outweigh the diff you actually shipped.
And the thinking overhead is worse than most people assume. Because output tokens cost more than input tokens, a refactor where the thinking block runs 4x longer than the code it produces can mean thinking alone eats over half your dollar cost for that turn. Most people assume their bill tracks their code output. It tracks the model’s internal monologue more than that. The poster’s own example: a session doing what looked like a small function rename came back with a thinking block several times longer than the actual renamed code, and that’s where most of the spend was sitting the whole time.
How to see it for yourself
- 🔍 Clone the “cost-xray” repo and point it at your local Claude Code or Codex session.
- 🕵️ Let the proxy capture run through a normal working session, ideally one with a few MCP tools active, so you’re seeing realistic usage instead of a synthetic test.
- 📊 Open the per-turn graph and look at what’s actually filling your context window before compaction kicks in. Pay attention to which category grows fastest across the session, not just the total at the end.
- 🧮 Compare your MCP schema cost against your real file-edit cost. That ratio alone tells you if your setup is bloated. If schemas are pulling more weight than your actual edits, that’s your first place to trim.
That side-by-side is the whole point. Most of us have a vague sense that “MCP costs something,” but seeing the actual number next to your real work is a different kind of clarity. It’s the difference between suspecting your grocery bill is high and actually reading the receipt line by line.
Pro tips
If you’re not using an MCP server in a given session, disconnect it before you start. Every idle server is still billing you on every turn, it doesn’t know it’s idle, and it won’t apologize for it either. A quick habit worth building: before you start a focused task, check which servers are connected and drop anything you won’t touch for the next hour.
Watch for cache miss spikes specifically. The original poster noted a turn that should cost around $0.03 jumping to $0.35 on a full cache rewrite, and that usually happens right after you change your tool config mid-session. If you’re about to swap MCP servers, finish your current task first, then swap, rather than juggling both in the same window.
On long refactors, keep an eye on the thinking-to-output ratio. If thinking is running 3 to 4x your actual code output, it might be worth breaking the refactor into smaller, more targeted requests instead of one giant one. Smaller asks tend to produce tighter thinking blocks, and you get more checkpoints to catch a wrong turn before it compounds across the whole task.
One more thing worth doing once you have the tool running: check your compaction cost separately from everything else. Since compaction has to read your full bloated context before it can shrink it, a context window stuffed with old tool output (that 500-line test log nobody needed after the first read) makes every future compaction more expensive too. Trimming what you keep around pays you back twice.
This is the kind of tool you run once out of curiosity and then can’t stop checking. If you’ve ever wondered whether your MCP setup is quietly draining your budget, go grab “cost-xray” 🧭 and find out for yourself.
We captured raw Claude Code API traffic: where tokens and budget actually go (breakdown of 5 request-level components)
by u/navune in PromptEngineering