Live data from Hacker News

MCP server that reduces Claude Code context consumption by 98%

mksg.lu

91–100 of 119 posts

Re: MCP server that reduces Claude Code context consumption by 98%

#91
post #77

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

Not really because it reliably greps or searches the file for relevant info. So far I haven't seen it ever load the whole file. It might be more efficient for the main thread to have a subagent do it but probably at a significant slowdown penalty when all I'm doing is linting or running tests. So this is probably a judgement call depending on the situation.

Re: MCP server that reduces Claude Code context consumption by 98%

#95
This 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 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%

#96
post #71

The 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…

Seconded that I would love to see the what, why and how of your Obsidian work.

Re: MCP server that reduces Claude Code context consumption by 98%

#98

[dead]

> With prompt caching, verbose context that gets reused is basically free.

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%

#99
post #6

Nice 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…

[dead]

Re: MCP server that reduces Claude Code context consumption by 98%

#100

This 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…

> I had zero visibility into where my Claude Code tokens were actually going

/context?

Post reply on HN