Earlier quoted context omitted.
> For example, if you’re working with a tool that dumps a lot of logged information into context I've set up a hook that blocks directly running certain common tools and instead tells Claude to pipe the output to a temporary file and search that for relevant info. There's still some noise where it tries to run the tool once, gets blocked, then runs it the right way. But it's better than before.
I think telling it to run those in a subagent should accomplish the same thing and ensure only the answer makes it to the main context. Otherwise you will still have some bloat from reading the exact output, although in some cases that could be good if you’re debugging or something
MCP server that reduces Claude Code context consumption by 98%
91–100 of 119 posts
Re: MCP server that reduces Claude Code context consumption by 98%
#92Re: MCP server that reduces Claude Code context consumption by 98%
#93Re: MCP server that reduces Claude Code context consumption by 98%
#94Re: MCP server that reduces Claude Code context consumption by 98%
#95It parses ~/.claude/projects/*/*.jsonl and breaks usage down by session, tool, project, and timeline with cost estimates (including cache read/create split).
Context Mode solves output compression really well; this is more of a measurement layer so you can see where the burn is before/after changes.
Disclosure: I built it.
Re: MCP server that reduces Claude Code context consumption by 98%
#96The FTS5 index approach here is right, but I'd push further: pure BM25 underperforms on tool outputs because they're a mix of structured data (JSON, tables, config) and natural language (comments, error messages, docstrings). Keyword matching falls apart on the structured half. I built a hybrid retriever for a similar problem, compressing a 15,800-file Obsidian vault into a searchable index for Claude Code. Stack is…
Re: MCP server that reduces Claude Code context consumption by 98%
#97Re: MCP server that reduces Claude Code context consumption by 98%
#98[dead]
But it's not. It might be discounted cost-wise, however it will still degrade attention and make generation slower/more computationally expensive even if you have a long prefix you can reuse during prefill.
Re: MCP server that reduces Claude Code context consumption by 98%
#99Nice work. It strikes me there's more low hanging fruit to pluck re. context window management. Backtracking strikes me as another promising direction to avoid context bloat and compaction (i.e. when a model takes a few attempts to do the right thing, once it's done the right thing, prune the failed attempts out of the context).
Agree. I’d like more fine grained control of context and compaction. If you spend time debugging in the middle of a session, once you’ve fixed the bugs you ought to be able to remove everything related to fixing them out of context and continue as you had before you encountered them. (Right now depending on your IDE this can be quite annoying to do manually. And I’m not aware of any that allow you to snip it out if y…
Re: MCP server that reduces Claude Code context consumption by 98%
#100This post made me realize I had zero visibility into where my Claude Code tokens were actually going, so I built a small companion CLI this morning: https://github.com/vexorkai/claude-trace It parses ~/.claude/projects/*/*.jsonl and breaks usage down by session, tool, project, and timeline with cost estimates (including cache read/create split). Context Mode solves output compression really well; this is more of a me…
/context?