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

51–60 of 119 posts

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

#51

Post by re5i5tor »

mksglu wrote: post #33
re5i5tor wrote: post #14

Earlier quoted context omitted.

Really intrigued and def will try, thanks for this. In connecting the dots (and help me make sure I'm connecting them correctly), context-mode _does not address MCP context usage at all_, correct? You are instead suggesting we refactor or eliminate MCP tools, or apply concepts similar to context_mode in our MCPs where possible? Context-mode is still very high value, even if the answer is "no," just want to make sure…

Right, context-mode doesn't change how MCP tool definitions get loaded into context. That's the "input side" problem that Cloudflare's Code Mode tackles by compressing tool schemas. Context-mode handles the "output side," the data that comes back from tool calls. That said, if you're writing your own MCPs, you could apply the same pattern directly. Instead of returning raw payloads, have your MCP server return a comp…

Hmmm. I was talking about the output side. When data comes back from an MCP tool call, context-mode is still not in the loop, not able to help, is it?

Edit: clarify "MCP tool"

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

#52

Post by 8note »

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…

i think something kinda easy for that could be to pretend that pruned output was actually done by a subagent. copy the detailed logs out, and replace it with a compacted summary.

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

#53

Post by 8note »

mksglu wrote: post #29
elephanlemon wrote: post #10

Earlier quoted context omitted.

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…

That's exactly what context-mode does for tool outputs. Instead of dumping raw logs and snapshots into context, it runs them in a sandbox and only returns a summary. The full data stays in a local FTS5 index so you can search it later when you need specifics.

what i want is for the agent to initially get the full data and make the right decision based on it, then later it doesnt need to know as much about how it got there.

isnt that how thinking works? intermediate tokens that then get replaced with the reuslt?

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

#54

Post by jaredsohn »

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…

Treat context like git shas. Yes, there is a specific order within a 'branch' but you should be able to do the equivalent of cherry-picking and rebasing it

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

#55

Post by IncreasePosts »

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).

I do this with my agents. Basically, every "work" oriented call spawns a subprocess which does not add anything to the parent context window. When the subprocess completes the task, I ask it to 1) provide a complete answer, 2) provide a succinct explanation of how the answer was arrived at, 3) provide a succinct explanation of any attempts which did not work, and 4) Anything learned during the process which may be useful in the future. Then, I feed those 4 answers back to the parent as if they were magically arrived at. Another thing I do for managing context window is, any tool/MCP call has its output piped into a file. The LLM then can only read parts of the file and only add that to its context if it is sufficient. For example, execute some command that produces a lot of output and ultimately ends in "Success!", the LLM can just tail the last line to see if it succeeded. If it did, the rest of the output doesn't need to be read. if it fails, usually the failure message is at the end of the log. Something I'm working on now is having a smaller local model summarize the log output and feed that summarization to the more powerful LLM (because I can run my local model for ~free, but it is no where near as capable as the cloud models). I don't keep up with SOTA so I have no idea if what I'm doing is well known or not, but it works for me and my set up.

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

#56

Post by re5i5tor »

esperent wrote: post #50
mksglu wrote: post #35

Earlier quoted context omitted.

Haven't looked at rtk closely but from the description it sounds like it works at the CLI output level, trimming stdout before it reaches the model. Context-mode goes a bit further since it also indexes the full output into a searchable FTS5 database, so the model can query specific parts later instead of just losing them. It's less about trimming and more about replacing a raw dump with a summary plus on-demand retr…

Does context mode only work with MCPs? Or does it work with bash/git/npm commands as well?

I'm not sure it actually works with MCPs *at all*, trying to get that clarified. How can context-mode get "into the MCP loop"?

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

#57

Post by nitinreddy88 »

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…

Any reason why it doesn't support Codex? I believe the idea and implementation seems to be pretty much agent independent

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

#58

Post by tomhow »

mksglu wrote: post #42
agrippanux wrote: post #11

I am a happy user of this and have recommended my team also install it. It’s made a sizable reduction in my token use.

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.

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

#59

Post by re5i5tor »

re5i5tor wrote: post #51
mksglu wrote: post #33

Earlier quoted context omitted.

Right, context-mode doesn't change how MCP tool definitions get loaded into context. That's the "input side" problem that Cloudflare's Code Mode tackles by compressing tool schemas. Context-mode handles the "output side," the data that comes back from tool calls. That said, if you're writing your own MCPs, you could apply the same pattern directly. Instead of returning raw payloads, have your MCP server return a comp…

Hmmm. I was talking about the output side. When data comes back from an MCP tool call, context-mode is still not in the loop, not able to help, is it? Edit: clarify "MCP tool"

I dug into this further. Tested empirically and read the code.

Confirmed: context-mode cannot intercept MCP tool responses. The PreToolUse hook (hooks/pretooluse.sh) matches only Bash|Read|Grep|Glob|WebFetch|WebSearch|Task. When I called my obsidian MCP's obsidian_list via MCP, the response went straight into context — zero entries in context-mode's FTS5 database. The web fetches from the same session were all indexed.

The context-mode skill (SKILL.md) actually acknowledges this at lines 71-77 with an "after-the-fact" decision tree for MCP output: if it's already in context, use it directly; if you need to search it again, save to file then index. But that's damage control — the context is already consumed. You can't un-eat those tokens.

The architectural reason: MCP tool responses flow via JSON-RPC directly to the model. There's no PostToolUse hook in Claude Code that could modify or compress a response before it enters context. And you can't call MCP tools from inside a subprocess, so the "run it in a sandbox" pattern doesn't apply.

So the 98% savings are real but scoped to built-in tools and CLI wrappers (curl, gh, kubectl, etc.) — anything replicable in a subprocess. For third-party MCP tools with unique capabilities (Excalidraw rendering, calendar APIs, Obsidian vault access), the MCP author has to apply context-mode's concepts server-side: return compact summaries, store full output queryably, expose drill-down tools. Which is essentially what you suggested above.

Still very high value for the built-in tool side. Just want the boundary to be clear.

Correct any misconceptions please!

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

#60

Post by re5i5tor »

esperent wrote: post #50
mksglu wrote: post #35

Earlier quoted context omitted.

Haven't looked at rtk closely but from the description it sounds like it works at the CLI output level, trimming stdout before it reaches the model. Context-mode goes a bit further since it also indexes the full output into a searchable FTS5 database, so the model can query specific parts later instead of just losing them. It's less about trimming and more about replacing a raw dump with a summary plus on-demand retr…

Does context mode only work with MCPs? Or does it work with bash/git/npm commands as well?

See my comment above, context-mode has no way to inject itself into the MCP tool-call - response loop.

Still high-value, outside MCPs.

Post reply on HN