Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP server that reduces Claude Code context consumption by 98%

mksg.lu

Post reply on HN
Print view View original

101–110 of 119 posts

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

#101

Post by thecopy »

blakec wrote: 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…

Very interesting, one big wrinkle with OP:s approach is exactly that, the structured responses are un-touched, which many tools return. Solution in OP as i understand it is the "execute" method. However, im building an MCP gateway, and such sandboxed execution isnt available (...yet), so your approach to this sounds very clever. Ill spend this day trying that out

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

#104

Post by bear3r »

muddi900 wrote: post #92

A lot of this token usage can be avoided by using CLI apps instead of MCPs. For example, the github cli is very robust and does the job of the MCP with a fraction of the token cost

yeah gh cli in particular is lean. though `gh pr view --json body,comments` can still flood context fast. the real win here is gatekeeping what hits context at all, regardless of source.

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

#106

Post by dsclough »

elephanlemon wrote: post #10
nr378 wrote: 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…

Trees in pi let you do this, after done debugging you move back up and continue, leaving all the debugging context in its own branch

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

#107

Post by doctorpangloss »

thecopy wrote: post #101
blakec wrote: 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…

Very interesting, one big wrinkle with OP:s approach is exactly that, the structured responses are un-touched, which many tools return. Solution in OP as i understand it is the "execute" method. However, im building an MCP gateway, and such sandboxed execution isnt available (...yet), so your approach to this sounds very clever. Ill spend this day trying that out

The LLM that wrote the comment you are replying to has no idea what it is talking about...

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

#108

Post by doctorpangloss »

esafak wrote: post #27
mksglu wrote: post #2

Author here. I shared the GitHub repo a few days ago ( https://news.ycombinator.com/item?id=47148025 ) and got great feedback. This is the writeup explaining the architecture. The core idea: every MCP tool call dumps raw data into your 200K context window. Context Mode spawns isolated subprocesses — only stdout enters context. No LLM calls, purely algorithmic: SQLite FTS5 with BM25 ranking and Porter stemming. Since…

Does your technique break the cache? edit: Thanks.

The LLM that the "author" is using has no idea what it's talking about, and the reply you got is nonsense.

@dang it's really bad lately.

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

#109

Post by doctorpangloss »

tomhow wrote: post #58
mksglu wrote: post #42

Earlier quoted context omitted.

Thanks, really appreciate hearing that! Glad it's working well for your team.

HN Mod here. Is the date on the post an error? It says Feb 2025 but the project seems new. I initially went to put a date reference on the HN title but then realised it's more likely a mistake on your post.

His post, code and all the replies here are LLM authored and don't make any sense. He has no idea why his Claude Code instance wrote Feb 2025 instead of Feb 2026. I mean all his results are placebos or nonsense. I can also start new conversations with only 2% of the context in it, or you can call compact, it will all work better. The post has to be flagged.

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

#110

Post by nharada »

Nice, I like the idea. It sounds like qualitatively you haven't had any performance regressions while doing this, but have you tested it at all on any sort of benchmark or similar eval? I'm curious how well the actual system performs with less context like this. I mean it's possible it actually improves...
Post reply on HN