Universal Claude.md – Claude आउटपुट टोकन में कमी

 (github.com/drona23)
2 पॉइंट द्वारा GN⁺ 2026-04-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude मॉडल के अनावश्यक शुरुआती वाक्य, समापन, और दोहराव हटाकर आउटपुट टोकन की बर्बादी कम करने वाली सेटिंग फ़ाइल
  • प्रोजेक्ट रूट में CLAUDE.md जोड़ने पर कोड बदले बिना तुरंत लागू होता है, और औसतन 63% टोकन कमी का प्रभाव मिलता है
  • ASCII-only आउटपुट, अनुमान पर रोक, अनुरोध की सीमा के भीतर उत्तर सीमित करना जैसी 12 नियमों के ज़रिए उत्तर को संक्षिप्त बनाया जाता है
  • ऑटोमेशन पाइपलाइन, कोड जेनरेशन, एजेंट लूप जैसे बड़े आउटपुट वाले वातावरण में लागत बचत का असर बड़ा है, जबकि एकल क्वेरी में यह अलाभकारी हो सकता है
  • MIT लाइसेंस के तहत जारी, इसलिए टीम या कार्य के अनुसार प्रोफ़ाइल-आधारित नियम प्रबंधन और कम्युनिटी योगदान संभव है

समस्या का अवलोकन

  • Claude Code में बनने वाला हर शब्द टोकन लागत पैदा करता है, और डिफ़ॉल्ट सेटिंग में उपयोगकर्ता के लिए उत्तर के फ़ॉर्मैट को नियंत्रित करना मुश्किल होता है
  • डिफ़ॉल्ट रूप से “Sure!”, “Great question!” जैसे विनम्र शुरुआती वाक्य, “I hope this helps!” जैसे औपचारिक समापन, प्रश्न का दोहराव, और अनावश्यक सुझाव अपने-आप शामिल हो जाते हैं
  • साथ ही यह em dash, smart quotes, Unicode characters जैसे ऐसे वर्ण भी इस्तेमाल करता है जो parser को तोड़ सकते हैं, और अत्यधिक code abstraction या गलत सहमति-प्रदर्शन भी शामिल कर देता है
  • इसके कारण टोकन की बर्बादी होती है जबकि वास्तविक सूचना-मूल्य लगभग नहीं के बराबर होता है

समाधान

  • प्रोजेक्ट रूट में CLAUDE.md फ़ाइल जोड़ने पर Claude Code इसे अपने-आप पढ़कर आउटपुट व्यवहार तुरंत बदल देता है
  • यह बिना कोड बदलाव या अतिरिक्त सेटिंग के काम करता है, और आउटपुट टोकन उपयोग को लगभग 63% तक घटाता है
  • संरचना का उदाहरण 
    your-project/
└── CLAUDE.md

किन मामलों में उपयोगी है और किनमें नहीं

  • उपयोगी मामले

    • ऑटोमेशन पाइपलाइन, एजेंट लूप, कोड जेनरेशन जैसे अधिक आउटपुट वाले कार्य

      • जब दोहराए जाने वाले और संरचित कार्यों में Claude के लंबे डिफ़ॉल्ट उत्तर जमा होते जाते हैं
      • जब टीम वातावरण में सेशनों के बीच एकसमान आउटपुट फ़ॉर्मैट चाहिए होता है

  • कम उपयोगी मामले

    • एकल छोटी क्वेरी या वन-ऑफ उपयोग में CLAUDE.md हर बार इनपुट टोकन लेता है, इसलिए लागत उल्टा बढ़ सकती है
    • hallucination सुधार या आर्किटेक्चरल त्रुटि सुधार जैसे गहरे समस्या-समाधान में इसका प्रभाव नहीं है
    • हर काम के लिए नया session खोलने वाली पाइपलाइन में persistent session-आधारित बचत का असर खत्म हो जाता है
    • बड़े पैमाने पर parser reliability के लिए JSON mode या schema-आधारित tools अधिक उपयुक्त हैं
    • exploratory या discussion-केंद्रित कार्यों में यह सीमित करने वाला लग सकता है

  • वास्तविक trade-off

    • CLAUDE.md स्वयं इनपुट टोकन खर्च करता है, इसलिए तभी शुद्ध लाभ होता है जब आउटपुट पर्याप्त बड़ा हो
    • कम उपयोग में बचत से अधिक लागत हो सकती है

बेंचमार्क परिणाम

  • समान 5 prompts के साथ परीक्षण
    परीक्षण डिफ़ॉल्ट ऑप्टिमाइज़्ड कमी दर
    async/await विवरण 180 शब्द 65 शब्द 64%
    कोड रिव्यू 120 शब्द 30 शब्द 75%
    REST API विवरण 110 शब्द 55 शब्द 50%
    hallucination सुधार 55 शब्द 20 शब्द 64%
    कुल 465 शब्द 170 शब्द 63%
  • लगभग 295 शब्दों की कमी, बिना सूचना-हानि के
  • हालांकि यह केवल दिशात्मक संकेतक है; सांख्यिकीय नियंत्रण या repeated experiments नहीं किए गए
  • सिर्फ़ अधिक आउटपुट की स्थिति में ही शुद्ध बचत प्रभाव होता है

  • बड़े पैमाने के उपयोग पर बचत का उदाहरण

    उपयोग दैनिक बचत टोकन मासिक बचत राशि (Sonnet मानक)
    100 बार/दिन लगभग 9,600 लगभग $0.86
    1,000 बार/दिन लगभग 96,000 लगभग $8.64
    3 प्रोजेक्ट लगभग 288,000 लगभग $25.92

पहले और बाद की तुलना

  • डिफ़ॉल्ट कोड रिव्यू उत्तर (120 शब्द)

    • लंबी प्रशंसा, व्याख्या और सुझाव शामिल

  • CLAUDE.md लागू होने के बाद (30 शब्द)

    • “Bug: <= causes an off-by-one error…” जैसे रूप में केवल मुख्य बात, 75% टोकन कमी

क्या-क्या बदला जाता है

क्रमांक समस्या बदलाव का तरीका
1 चापलूसी भरी शुरुआत प्रतिबंधित – पहली पंक्ति से ही उत्तर शुरू
2 खोखला समापन प्रतिबंधित – “I hope this helps!” हटाया जाता है
3 प्रश्न का दोहराव प्रतिबंधित – तुरंत कार्रवाई
4 em dash, smart quotes, Unicode ASCII-only आउटपुट अनिवार्य
5 “As an AI…” वाक्यांश प्रतिबंधित
6 अनावश्यक disclaimer सिर्फ़ वास्तविक सुरक्षा जोखिम पर अनुमति
7 अनुरोध से बाहर के सुझाव प्रतिबंधित – केवल अनुरोधित दायरे में काम
8 अत्यधिक code abstraction सिर्फ़ सबसे सरल काम करने वाला कोड अनुमत
9 अनिश्चित तथ्यों पर hallucination “मालूम नहीं” स्पष्ट, अनुमान निषिद्ध
10 उपयोगकर्ता के सुधार की अनदेखी सुधारित सामग्री session-आधारित तथ्य के रूप में स्थिर
11 फ़ाइलों को बार-बार पढ़ना उसी फ़ाइल को दोबारा पढ़ना निषिद्ध
12 दायरे का विस्तार अनुरोध से बाहर कोड बदलाव निषिद्ध

कम्युनिटी टिप्स

  • वास्तविक failure patterns के अनुसार नियम लिखना सबसे प्रभावी है
    • उदाहरण: जब Claude पाइपलाइन त्रुटि को निगल जाता है → “किसी चरण के fail होते ही तुरंत रोकें और पूरी त्रुटि व traceback रिपोर्ट करें” नियम जोड़ें

  • CLAUDE.md फ़ाइलों को hierarchical रूप से merge किया जा सकता है

    • global (~/.claude/CLAUDE.md): सामान्य नियम (tone, ASCII आदि)
    • project root: प्रोजेक्ट-विशिष्ट प्रतिबंध (उदाहरण: /config संशोधन निषिद्ध)
    • subdirectories: कार्य-विशिष्ट विस्तृत नियम
    • इससे नियमों का वितरित प्रबंधन और फ़ाइल के अनावश्यक बड़े होने से बचाव संभव है

प्रोफ़ाइल कॉन्फ़िगरेशन

  • प्रोजेक्ट प्रकार के अनुसार अलग compression level चुना जा सकता है
    प्रोफ़ाइल उपयुक्त उपयोग
    CLAUDE.md सामान्य उपयोग
    profiles/CLAUDE.coding.md डेवलपमेंट, कोड रिव्यू, डिबगिंग
    profiles/CLAUDE.agents.md ऑटोमेशन, मल्टी-एजेंट सिस्टम
    profiles/CLAUDE.analysis.md डेटा एनालिसिस, रिसर्च, रिपोर्टिंग

उपयोग का तरीका

ओवरराइड नियम

  • उपयोगकर्ता का कमांड हमेशा प्राथमिक

    • यदि उपयोगकर्ता स्पष्ट रूप से “विस्तार से समझाइए” जैसा कहे, तो Claude उसी के अनुसार चलता है
    • CLAUDE.md उपयोगकर्ता की मंशा को दबाता नहीं है

योगदान कैसे करें

  • यदि कोई संशोधित किया जा सकने वाला व्यवहार मिले तो Issue दर्ज करें
    1. समस्या पैदा करने वाला डिफ़ॉल्ट व्यवहार
    2. उसे ट्रिगर करने वाला prompt
    3. प्रस्तावित सुधार नियम
  • कम्युनिटी सुझाव अगले संस्करण में शामिल किए जाते हैं और योगदानकर्ता क्रेडिट दिया जाता है

सत्यापन और संदर्भ

  • पूरा बेंचमार्क परिणाम BENCHMARK.md में देखा जा सकता है
  • प्रोजेक्ट Claude कम्युनिटी की वास्तविक शिकायतों के मामलों के आधार पर बनाया गया है
  • कई संबंधित संदर्भ स्रोत शामिल हैं (GitHub issues, The Register, DEV Community, Medium, Anthropic Docs आदि)

लाइसेंस

  • MIT लाइसेंस, स्वतंत्र उपयोग, संशोधन और वितरण संभव

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

1 टिप्पणियां

 
GN⁺ 2026-04-01
Hacker News टिप्पणियाँ

  • यहाँ का benchmark single explanatory task की ओर biased है, और code generation जैसे agent loop के लिए उपयुक्त नहीं लगता
    सोचता हूँ कि जब project चल रहा हो, तब Claude की लंबी-चौड़ी व्याख्या क्या session की consistency और focus बनाए रखने में मदद करती है
    “redundant context को दोहराओ मत” वाला नियम अच्छा है, लेकिन मुझे तो उल्टा ज़्यादा goal-oriented reasoning token इस्तेमाल करना मददगार लगता है
    यह तरीका असली agentic coding में प्रभावी है या नहीं, इस पर अभी पर्याप्त data नहीं है

    • मैंने /handoff नाम की एक skill बनाई, जो session के compression limit तक पहुँचने से पहले अपने-आप Markdown report generate कर देती है
      यह file session का permanent record और “daily report” दोनों का काम करती है, इसलिए बाद में reference के लिए या manager के साथ share करने में सुविधाजनक है
      लंबी अवधि की consistency बनाए रखने के लिए मुझे ऐसा summary documentation approach ज़्यादा बेहतर लगता है
      install करने का तरीका यहाँ डाला है
    • “क्या करना है यह मत समझाओ, बस कर दो” वाले rule की वजह से, जब Claude गलत दिशा में जाता है तो मैं उसे तुरंत पकड़कर prompt ठीक कर पाता हूँ
    • समझ नहीं आता लोग अनावश्यक भाषा को रोकने वाला rule CLAUDE.md में क्यों नहीं डालते
      हाल की research के मुताबिक redundant reasoning paths (self-consistency) और model ensembling performance improvement में मदद करते हैं
    • reasoning time scaling भी महत्वपूर्ण है। जवाब खोजते समय ज़्यादा token खर्च करना उल्टा quality बढ़ा सकता है
      minimum length पर ज़्यादा अटकना RL training objective के खिलाफ जाता है
    • मैंने कई settings के साथ coding test चलाए, और इस approach में 30 runs में कुल मिलाकर performance कम रही
      test code यहाँ है

  • Claude Code का planning mode ठीक से काम नहीं करता, इसलिए .md file approach पर मुझे संदेह है
    मेरे हिसाब से planning mode बस ऐसा feature होना चाहिए जो file writing disable कर दे

  • “जवाब हमेशा पहली पंक्ति में, reasoning उसके बाद” वाला rule LLM की autoregressive nature को ignore करता है
    अगर पहले answer fix कर दिया जाए, तो बाद की reasoning में confirmation bias आने का खतरा बढ़ जाता है

    • इस approach का idea अच्छा है, लेकिन implementation गलत लगता है
      Compressed Chain of Thought (CCoT) paper की तरह reasoning को compress करना ज़्यादा efficient है
      quality loss थोड़ा होता है, लेकिन speed और cost के लिहाज़ से फायदा है (paper link)
    • महत्वपूर्ण sessions में मैं “sanity check” जैसी second-pass review prompt जोड़ता हूँ, ताकि शुरुआती plan को फिर से verify किया जा सके
    • reasoning LLM जवाब लिखने से पहले अंदर ही अंदर हज़ारों reasoning token generate कर सकता है
      यानी “answer first” rule असल reasoning order नहीं बदलता, सिर्फ output order बदलता है
    • Claude Code में “no thinking” option नहीं है, और कम-से-कम low thinking mode default है

  • यह benchmark accuracy को देखे बिना सिर्फ output token count compare करता है, इसलिए अर्थहीन है
    “हमेशा एक ही शब्द में जवाब दो” जैसे prompt से भी score आसानी से बढ़ाया जा सकता है
    “अगर user factual error बताए तो उसे हमेशा मान लो” जैसे rule खतरनाक हैं

    • लोग कहते हैं “prompt engineering वापस आ गई?”, लेकिन पिछले 1~2 साल में meta prompt से कोई खास improvement नहीं दिखा
    • “गलती मत करो” जैसे rule व्यावहारिक नहीं हैं

  • ऐसे universal solution टाइप ideas में लोग जल्दी interest खो देते हैं, या फिर वे CC में absorb हो जाते हैं
    बार-बार workflow बदलना बहुत थकाने वाला है
    अभी के लिए default Claude Code settings सबसे stable लगती हैं

    • मैं भी लगभग यही सोचता हूँ। लंबे समय में vanilla setting बनाए रखना बेहतर लगता है
      Skills अच्छे हैं, लेकिन MCP या worktree मैं लगभग इस्तेमाल नहीं करता
    • Anthropic अंदर ही अंदर पहले से self-dogfooding के जरिए optimize कर रहा है, इसलिए default setting के सबसे efficient होने की संभावना ज़्यादा है
      CLAUDE.md को किसी समझदार सहकर्मी को भेजे गए draft memo की तरह treat करना ही काफ़ी अच्छी तरह काम करता है
    • “आख़िर में यह CC में integrate हो जाएगा” वाली बात से सहमत हूँ
      अगर Anthropic ने कोई feature खुद नहीं जोड़ा, तो शायद performance improvement साबित नहीं हुआ होगा
    • ऐसे “Claude improvement layer” आख़िरकार workflow instability पैदा करते हैं
      थोड़ी देर के लिए उपयोगी हों, फिर जल्दी ही default features में समा जाते हैं या गायब हो जाते हैं
    • Claude में भी md optimization features लगातार update हो रहे हैं
      इसलिए ऐसे experimental scripts इस्तेमाल करो तब भी md files को बार-बार update करते रहो, तो सब latest बना रहेगा

  • “अगर file हर message पर context में load होती है, तो क्या यह token waste नहीं है?” इस सवाल पर,
    मुझे लगता है Claude की personalization feature पहले से वही काम करती है
    मेरे लिए brevity तभी मायने रखती है जब वह quality बढ़ाए
    Reddit पर देखे कुछ संबंधित tools भी दिलचस्प हैं:
    Headroom context को 34% compress करता है,
    RTK CLI output को 60~90% compress करता है,
    MemStack persistent memory देता है, जिससे बेवजह files दोबारा पढ़ने से बचा जा सके

  • लगता है ऐसी कोशिशें उल्टा LLM के मूल सिद्धांत को गलत समझने का नतीजा हैं
    “answer first, reasoning later” transformer की autoregressive architecture को ignore करता है
    RL training पहले से optimal length और quality को balance कर रही है, इसलिए ज़रूरत से ज़्यादा tweaking performance drop ला सकती है

    • response length को ज़बरदस्ती घटाने से reasoning quality और consistency गिरती है, और hallucination की संभावना बढ़ती है
      model को English के आधार पर multi-step reasoning करने के लिए train किया गया है
    • “answer first” rule वास्तविक reasoning order नहीं बदलता। model पहले ही अंदर सोचकर फिर answer output करता है
    • लेखक transformer नहीं समझता ऐसा नहीं, बल्कि शायद उसने सिर्फ token cost कम करने वाला hack आज़माया है
      यह quality से ज़्यादा efficiency पर केंद्रित experimental approach है
    • ज़्यादातर APIs पहले से COT length control options देती हैं। ऐसे workaround की जगह API settings का उपयोग करना बेहतर है
    • आख़िरकार मुझे Anthropic के बनाए tools ही सबसे भरोसेमंद लगते हैं
      इसलिए मैं OpenCode जैसे third-party के बजाय सिर्फ 1st-party tools इस्तेमाल करता हूँ

  • Karpathy के video में देखा था कि model जितने ज़्यादा token इस्तेमाल करता है, accuracy बढ़ने की प्रवृत्ति उतनी होती है
    यह approach उल्टा model को और खराब बना सकता है

    • हाँ, अगर यहाँ मकसद low-value output (जैसे चापलूसी भरे वाक्य, formatting noise) घटाना हो, तो यह ठीक हो सकता है
      लेकिन reasoning के बिना सीधे answer निकलवाने से premature commitment bias का खतरा रहता है
    • “redundant output” दिशा को reinforce करने का काम करता है, इसलिए उसे हटाने से ambiguity बढ़ सकती है

  • समझ नहीं आता ऐसे बेमतलब projects HN पर trend क्यों बन जाते हैं
    सच में token usage घटाने वाले tools claude-mem और lumen जैसे हैं

    • वजह सीधी है। HN का trend algorithm accuracy से ज़्यादा engagement पर optimize है

  • पहले लोग नए hash, encryption, compression algorithms पर research करते थे
    अब हम इस विडंबना में जी रहे हैं कि AI को चुप रहने का तरीका सिखाने पर research कर रहे हैं