Context Mode - Claude Code की context खपत 98% तक कम करने वाला MCP सर्वर

 (mksg.lu)
39 पॉइंट द्वारा GN⁺ 2026-03-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बाहरी टूल कॉल के दौरान बनने वाले बड़े raw data को context window को तेज़ी से खत्म करने की समस्या का समाधान
  • Claude Code और टूल आउटपुट के बीच स्थित होकर डेटा को compress और filter करता है, 315KB को घटाकर 5.4KB करता है (98% कमी)
  • sandbox संरचना के ज़रिए हर execution को isolate करता है, और सिर्फ stdout को context में शामिल करके logs, snapshots जैसे मूल डेटा के leak को रोकता है
  • SQLite FTS5 आधारित knowledge base से Markdown content को index करता है, और BM25 ranking व Porter stemming लागू कर सटीक code block search को support करता है
  • उसी 200K token सीमा में session duration 30 मिनट से बढ़कर 3 घंटे हो जाता है, जिससे AI agent का efficient context management संभव होता है

समस्या

  • Claude Code की MCP tool calls हर कॉल पर raw data को सीधे 200K context window में dump कर देती हैं
    • Playwright snapshot 56KB, GitHub issues 20 items 59KB, access logs 45KB आदि
    • लगभग 30 मिनट इस्तेमाल पर पूरे context का 40% खर्च हो जाता है
  • MCP बाहरी टूल इस्तेमाल का standard बन चुका है, लेकिन input definitions और output data दोनों context भर देते हैं, यह एक संरचनात्मक सीमा है
  • 81 से अधिक tools active होने पर पहला message भेजने से पहले ही 72% (143K tokens) खर्च हो जाते हैं

Context Mode की संरचना

  • Claude Code और टूल आउटपुट के बीच मौजूद MCP server, जो raw data को न्यूनतम करके आगे भेजता है
    • 315KB output घटकर 5.4KB हो जाता है (98% कमी)
  • हर execute कॉल isolated subprocess में चलती है, इसलिए memory या state share किए बिना स्वतंत्र execution होता है
    • सिर्फ stdout ही context में शामिल होता है, जबकि logs, API responses, snapshots आदि sandbox के भीतर रहते हैं
  • 10 language runtimes का support: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R
    • Bun auto-detection से JS/TS execution speed 3~5 गुना तेज़
  • authenticated CLI (gh, aws, gcloud, kubectl, docker) में environment variable inheritance के ज़रिए credentials सुरक्षित रूप से pass किए जाते हैं

Knowledge base

  • index टूल Markdown को heading units में split करता है और code blocks को जस का तस रखते हुए SQLite FTS5 virtual table में store करता है
  • search के समय BM25 ranking algorithm का इस्तेमाल कर word frequency, inverse document frequency, और document length normalization के आधार पर relevance निकाली जाती है
  • Porter stemming लागू होने से “running”, “runs”, “ran” एक ही root के रूप में match होते हैं
  • search कॉल पर summary नहीं, बल्कि सटीक code blocks और heading hierarchy लौटाई जाती है
  • fetch_and_index URL को fetch कर HTML को Markdown में बदलकर index करता है, और original page context में शामिल नहीं होता

प्रदर्शन के आँकड़े

  • 11 वास्तविक scenarios (test triage, TypeScript error diagnosis, git diff review आदि) में सभी जगह output 1KB से कम रखा गया
    • Playwright snapshot: 56KB → 299B
    • GitHub issues (20): 59KB → 1.1KB
    • access logs (500 entries): 45KB → 155B
    • CSV analysis (500 rows): 85KB → 222B
    • Git logs (153 commits): 11.6KB → 107B
    • repository investigation (subagent): 986KB → 62KB (5 calls vs 37 calls)
  • पूरे session में 315KB → 5.4KB, session duration 30 मिनट → 3 घंटे
  • 45 मिनट बाद बचा हुआ context: पहले 60% → अब 99%

इंस्टॉलेशन और उपयोग

  • Plugin Marketplace के ज़रिए automatic routing hooks और slash commands का support
  • सिर्फ MCP के लिए अलग installation भी संभव
  • Claude Code restart करने के बाद तुरंत इस्तेमाल किया जा सकता है

वास्तविक बदलाव

  • इस्तेमाल के तरीके में बदलाव किए बिना PreToolUse hook अपने आप output routing करता है
  • subagents डिफ़ॉल्ट टूल के रूप में batch_execute इस्तेमाल करते हैं
  • Bash subagent को general-purpose में upgrade किया गया है, जिससे MCP tools तक access मिलता है
  • नतीजतन context window अब इतनी जल्दी नहीं भरती, और वही tokens लेकर लंबे sessions चलाए जा सकते हैं

विकास पृष्ठभूमि

  • MCP Directory & Hub चलाते समय यह common pattern मिला कि सभी MCP servers raw data को context में dump कर रहे थे
  • Cloudflare के Code Mode से प्रेरणा मिली, जिसने tool definitions को compress किया था; इसे आगे बढ़ाकर output data compression की दिशा में विकसित किया गया
  • Claude Code sessions में 6 गुना लंबे समय तक काम कर पाना verify होने के बाद इसे MIT license के तहत open source जारी किया गया
  • GitHub: mksglu/claude-context-mode

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-02
Hacker News टिप्पणियाँ

  • यहाँ प्रस्तावित FTS5 index approach सही है, लेकिन मुझे लगता है कि इसे एक कदम और आगे जाना चाहिए
    tool output में structured data (JSON, tables, config) और natural language (comments, error messages, docstring) मिला-जुला होता है, इसलिए pure BM25 का प्रदर्शन कमजोर पड़ता है
    मैंने इसी तरह की समस्या हल करने के लिए Model2Vec + sqlite-vec + FTS5 को मिलाकर एक hybrid retriever बनाया था। दोनों search results को Reciprocal Rank Fusion(RRF) से मिलाने पर BM25 की precise keyword matching और vector search की semantic matching दोनों साथ मिलती हैं
    incremental indexing भी महत्वपूर्ण है। मेरा indexer --incremental flag के साथ सिर्फ बदले हुए chunks को दोबारा embed करता है। पूरे 15,800 files की reindexing में 4 मिनट लगते हैं, और daily incremental update 10 सेकंड से कम में हो जाती है
    caching के लिहाज़ से भी यह तरीका फायदेमंद है। एक ही query के लिए compressed output deterministic होता है, इसलिए prompt cache स्थिर रूप से काम करता है
    Context Mode architecture में मैं यह जोड़ना चाहूँगा कि वही retriever PostToolUse hook में भी चले, ताकि output conversation में जाने से पहले compress हो जाए

    • OP के approach में structured response ज्यों का त्यों रह जाना समस्या थी, और मैं sandbox execution को support न करने वाला MCP gateway बना रहा हूँ, इसलिए यह तरीका मुझे बहुत उपयोगी लग रहा है। आज इसी पर प्रयोग करने वाला हूँ
    • मैं इस विषय पर एक deep-dive लेख ज़रूर पढ़ना चाहूँगा। लगता है HN के बारीकी से नोट्स लेने वाले लोगों को यह पसंद आएगा
    • मैं भी इस Obsidian indexing work की background और implementation process विस्तार से देखना चाहूँगा

  • मैं इस पोस्ट का लेखक हूँ। कुछ दिन पहले मैंने GitHub repository साझा की थी और अच्छा feedback मिला था। यह पोस्ट उसी की architecture explanation है
    core idea यह है कि MCP tool call जो raw data dump करता है, उसे 200K context window में डालने के बजाय Context Mode एक isolated subprocess बनाता है और सिर्फ stdout को context में भेजता है। इसमें LLM call नहीं होती, यह पूरी तरह algorithm-based है, और SQLite FTS5 + BM25 + Porter stemming का उपयोग करती है
    हाल में 228 stars और real-world usage data मिलने के बाद मुझे समझ आया कि subagent routing कितना महत्वपूर्ण है। Bash subagent को automatically general-purpose mode में upgrade करके batch_execute इस्तेमाल किया जाए, तो raw output से context भरने की ज़रूरत नहीं रहती

    • blog post में Cloudflare Code Mode post का link जोड़ना अच्छा रहेगा। README में है, लेकिन main text में नहीं
    • यह बहुत दिलचस्प लगा, इसलिए मैं खुद इसे आज़माने वाला हूँ। लेकिन मेरी समझ यह है कि Context Mode सीधे MCP context usage को नहीं संभालता; क्या यह सही है? मैं कई Claude environments में MCP इस्तेमाल करता हूँ, इसलिए सिर्फ CLI से काम सीमित हो जाता है
    • क्या यह Zed Agent जैसे दूसरे agents के साथ भी इस्तेमाल किया जा सकता है?
    • मैं जानना चाहता हूँ कि Codex को support न करने की कोई खास वजह है क्या। architecture के हिसाब से तो यह agent-independent लगता है
    • क्या यह approach cache को तोड़ता नहीं है, यह भी जानना चाहूँगा

  • समझ नहीं आता कि लोग mcp-cli mode क्यों नहीं इस्तेमाल करते। मैंने wener-mcp-cli से एक cloned version बना रखा है

  • शानदार काम है। मुझे लगता है context window management में अभी भी बहुत सुधार की गुंजाइश है। उदाहरण के लिए, अगर model कई कोशिशों के बाद सही जवाब तक पहुँचता है, तो failed attempts को context से हटाने वाला backtracking approach उपयोगी हो सकता है

    • मैं भी सहमत हूँ। debugging के दौरान बने logs या failure history bug fix होने के बाद हटाई जा सकनी चाहिए। मौजूदा IDEs में इसे manually करना झंझट है। अच्छा होगा अगर agent खुद context manage करे, और log जैसी चीज़ें कुछ समय बाद अपने-आप साफ हो जाएँ। context को सिर्फ stack नहीं, बल्कि freely editable space की तरह देखना चाहिए
    • failed attempts आखिरकार noise ही हैं। retry patterns को automatically detect करके सिर्फ आख़िरी successful version रखना पूरी तरह implement किया जा सकता है
    • अभी सब कुछ 1990 के दशक के आख़िरी दौर जैसा लगता है। तब HTML और SQL थे, आज coding agents हैं। हम पहले से skilled engineers हैं, इसलिए Claude Code इस्तेमाल करते हुए naturally optimization ढूँढ़ लेते हैं
    • subagents का इस्तेमाल भी एक तरीका है। समस्या आए तो subagent fork करके उसे हल कराओ और सिर्फ result वापस लाओ। यह कल्पना भी रोचक है कि model खुद memory साफ करे और पुराने state में लौट जाए
    • मैं वास्तव में ऐसा ही करता हूँ। हर task call एक अलग subprocess में चलता है, इसलिए parent context दूषित नहीं होता। काम पूरा होने पर result, process summary, failed attempts, और learned lessons — इन 4 हिस्सों में parent को वापस भेजता हूँ। tool output को file में save करता हूँ, और LLM सिर्फ ज़रूरी हिस्से पढ़ता है। उदाहरण के लिए अगर अंत में “Success!” हो, तो सिर्फ आख़िरी line देखनी होती है। failure होने पर सिर्फ error message पढ़ता है। मैं local model से logs summarize करके उन्हें cloud model को भेजने का प्रयोग भी कर रहा हूँ। यह cutting-edge न हो, फिर भी मेरे environment में अच्छी तरह काम करता है

  • यह पोस्ट देखकर मुझे एहसास हुआ कि मुझे Claude Code token usage के बारे में लगभग कुछ पता ही नहीं था, इसलिए मैंने आज सुबह claude-trace नाम का एक CLI बना लिया
    यह ~/.claude/projects/*/*.jsonl को parse करके session, tool, project और timeline के हिसाब से usage और cost (cache read/write समेत) का analysis करता है
    अगर Context Mode output compression की समस्या अच्छी तरह हल करता है, तो यह measurement layer की तरह बदलाव से पहले और बाद की consumption को visualize करता है

    • “/context?” जैसे सवाल की तरह, असल बात यह है कि token वास्तव में कहाँ खर्च हो रहे हैं, यह visible होना चाहिए

  • बहुत सा token usage MCP की जगह CLI apps इस्तेमाल करके कम किया जा सकता है। उदाहरण के लिए GitHub CLI, MCP की तुलना में कहीं कम tokens में वही काम कर देता है

  • hooks कुछ ज़्यादा aggressive लगते हैं। हर curl/wget/WebFetch को block करके sandbox में 56KB snapshot बनाना अच्छा है, लेकिन curl api.example.com/health जैसी simple request में जहाँ सिर्फ 200 bytes चाहिए हों, वहाँ यह ज़रूरत से ज़्यादा है
    153 git commits को 107 bytes में compress कर देने का मतलब है कि model को data देखने के लिए बिल्कुल सही extraction script लिखनी होगी। अगर command गलत हुई, तो ज़रूरी जानकारी गायब हो जाएगी
    benchmark यह मानकर चलते हैं कि model हमेशा सही summarization code लिखेगा, लेकिन असलियत में ऐसा नहीं होता

    • मैं भी सहमत हूँ, इसलिए मैंने वह feature हटा दिया

  • बुरा नहीं है, लेकिन इसमें accuracy loss और hallucination risk है। incomplete data या गलत extraction logic की वजह से Claude गलत निष्कर्ष निकाल सकता है। इसमें यह मान लिया गया है कि MCP इतना smart होगा कि अच्छा extraction script और search query दोनों लिख सके। मेरे हिसाब से information preservation वास्तव में बड़ी समस्या है

  • compression ratio प्रभावशाली है, लेकिन मैं यह जानना चाहूँगा कि compressed context के साथ भी model वही quality output देता है या नहीं। session को 30 मिनट से 3 घंटे तक बढ़ाने का मतलब तभी है, जब 2 घंटे बाद भी reasoning quality बनी रहे
    esafak ने जो cache economics की बात की, वह भी महत्वपूर्ण है। अगर prompt caching अच्छी तरह काम करे, तो लंबा context लगभग मुफ्त जैसा हो सकता है। लेकिन अगर compression cache continuity तोड़ दे, तो लागत उल्टा बढ़ सकती है
    इससे भी बुनियादी समस्या यह है कि ज़्यादातर MCP tools SELECT * की तरह सारा data उठा लाते हैं। यह protocol design problem है, जहाँ summarization और drill-down दोनों को support होना चाहिए

    • cache भले मुफ्त जैसा दिखे, लेकिन असल में यह attention degradation और speed slowdown पैदा करता है। लंबा prefix reuse होने पर भी computation कम नहीं होती

  • मुझे संदेह है कि context में 80 से ज़्यादा tools रखने की ज़रूरत है भी या नहीं। context सोने की तरह कीमती है; जितनी ज़्यादा problem से असंबंधित चीज़ें डालोगे, result उतना खराब होगा। data compression से बेहतर approach subagent isolation है

    • बात सही है। लेकिन ज़्यादातर लोग task के हिसाब से MCP servers को सीधे manage नहीं करते। सिर्फ 5~6 servers install करने पर ही default में 80 tools load हो जाते हैं। Context Mode tool definitions की अधिकता को हल नहीं करता। इसके बजाय यह tool execution के बाद dump होने वाले output side को संभालता है। उदाहरण के लिए सिर्फ एक Playwright snapshot या git log से ही 50,000 tokens उड़ सकते हैं, और वह इसे sandbox में संभालता है