Claude Code नियमित रूप से प्रत्येक बैकग्राउंड एजेंट के ट्रांसक्रिप्ट को अपने मॉडल पर भेजता है

मूल लेख ↗ Hacker News चर्चा ↗

Claude Code के built‑in background agent status summaries उपयोगकर्ताओं के paid tokens का आश्चर्यजनक हिस्सा खा रहे हैं, और कुछ रिपोर्टों में कुल उपयोग का 8–16% periodic “agent_summary” calls में जा रहा है जो एक छोटे status label को अपडेट करते हैं। Anthropic के स्टाफ का कहना है कि telemetry इससे कम average impact दिखाती है और वे हालिया fixes तथा सस्ते summary modes की योजना की ओर इशारा करते हैं, लेकिन कई उपयोगकर्ता स्पष्ट toggle की कमी की आलोचना करते हैं, harness और billing दोनों पर model providers के नियंत्रण को conflict of interest मानते हैं, और waste कम करने के लिए hacks, alternative clients, या पुराने binaries आज़माते हैं। यह घटना Claude Code की बढ़ती bloat, opaque limits, और privacy quirks पर व्यापक निराशा को भी बढ़ाती है, और हल्के third‑party harnesses तथा प्रतिद्वंद्वी tools से तुलना को जन्म देती है.

बैकग्राउंड एजेंट सारांश और टोकन खर्च

  • मुख्य समस्या: Claude Code लगभग हर 30 सेकंड में प्रत्येक सक्रिय बैकग्राउंड एजेंट का पूरा ट्रांसक्रिप्ट मॉडल को भेजता है, ताकि छोटे स्टेटस सारांश बनाए जा सकें।
  • एक भारी उपयोगकर्ता ने इन कॉल्स से साप्ताहिक token-equivalent खर्च का लगभग ~16% मापा; अन्य लोग वर्कफ़्लो और subagent उपयोग के आधार पर ~3–8% से लेकर 15%+ तक की श्रेणियाँ रिपोर्ट करते हैं।
  • असर लंबे-context वाले agents (जैसे, सैकड़ों हज़ार tokens) और कई concurrent subagents के साथ सबसे ज़्यादा होता है।

दायरा, caching, और mechanics

  • सारांश केवल सक्रिय रूप से काम कर रहे background agents पर लागू होते हैं, idle agents पर नहीं। नियमित single-session उपयोग कम प्रभावित होता है।
  • कुछ परीक्षकों का कहना है कि workflows (“ultracode”) प्रभावित नहीं होते, केवल subagents होते हैं।
  • Prompts ज़्यादातर provider के prompt cache से सर्व होते हैं, इसलिए अधिकांश “cheap reads” होते हैं, लेकिन बार-बार होने वाली बड़ी cached reads फिर भी लागत बढ़ाती हैं।
  • Cache TTLs: main sessions ~1 hour; subagents डिफ़ॉल्ट रूप से ~5 minutes, जब तक premium cache write के लिए इसे बढ़ाया न जाए। इससे cache behavior और लागत कुछ जटिल और timing-dependent हो जाती है।
  • उपयोगकर्ता ध्यान देते हैं कि cache expiry के करीब aggressive auto-compaction लागत कम करता है, लेकिन continuity को नुकसान पहुँचा सकता है या कुछ workloads के लिए “lobotomy” जैसा महसूस हो सकता है।

प्रदाता की प्रतिक्रिया और नियोजित fixes

  • एक Claude Code engineer telemetry की रिपोर्ट करते हैं, जिसके अनुसार summaries लगभग:
    • कुल लागत का ~2% (API list prices),
    • requests का थोड़ा कम 4% से,
    • terminal में लागत का ~6%, जहाँ ऐसे अधिकांश calls होते हैं।
  • वे मानते हैं कि यह “a lot for a status line” है, दावा करते हैं कि cache misses के लिए fix ship कर दिया गया है (version 2.1.311+), और छोटे model को short notes इस्तेमाल करने वाला सस्ता mode पर काम कर रहे हैं।
  • अभी summaries को पूरी तरह disable करने का कोई official setting नहीं है, जब तक background agents/forks को भी disable न किया जाए।

उपयोगकर्ता workarounds और tooling

  • एक Bun preload script setTimeout को patch करके summary timer को intercept और suppress करता है, binary को बदले बिना; नियंत्रित tests दिखाते हैं कि यह summary calls को zero तक घटा देता है जबकि agents चलते रहते हैं। Windows runners और इसी तरह के tools साझा किए गए हैं।
  • कुछ उपयोगकर्ता पुराने Claude Code CLI versions पर freeze रहते हैं और auto-updates disable कर देते हैं, यह दावा करते हुए कि नए versions background features के माध्यम से अधिक tokens जलाते हैं।
  • अन्य लोग बाहरी orchestrators/“decision models” (जैसे, Pi-based harnesses, omp.sh, custom bridges) पर निर्भर करते हैं ताकि सस्ते models चुने जा सकें और Claude Code के behavior से बचा जा सके।

प्रोत्साहन, भरोसा, और विवाद

  • कई लोगों के लिए यह अनावश्यक, गैर-पारदर्शी token burn है जिसे user-togglable या free होना चाहिए, खासकर enterprise/API-priced customers के लिए।
  • Intent पर मतभेद हैं:
    • कुछ लोग इसे exploitative या यहाँ तक कि “fraud” कहते हैं, यह तर्क देते हुए कि model vendors के पास harnesses पर नियंत्रण होने से tokens बर्बाद करने का अंतर्निहित प्रोत्साहन होता है।
    • अन्य इसे खराब engineering/product design मानते हैं: internal, cost-insensitive environment में बने features, फिर पर्याप्त cost controls के बिना ship कर दिए गए।
    • कुछ का तर्क है कि competition और user churn deliberate waste को बहुत अधिक rational होने से सीमित करते हैं।
  • Claude Code की perceived bloat, बार-बार behavior changes, opaque quotas, और token-heavy features के पैटर्न को लेकर व्यापक निराशा भी सामने आती है।

अन्य harnesses और models से तुलना

  • कई टिप्पणीकार हल्के या OSS harnesses (Pi, omp.sh, Codex, Muse Code, Copilot) को प्राथमिकता देते हैं, यह दावा करते हुए कि:
    • बेहतर token efficiency,
    • अधिक predictable behavior,
    • कम “spyware-like” या intrusive defaults।
  • अन्य लोग कहते हैं कि Opus + Claude Code, उच्च token उपयोग के बावजूद, उनके लिए अब भी असाधारण productivity देता है; अनुभव project size, language, और workflows पर बहुत निर्भर करते हैं।

गोपनीयता और safety concerns

  • एक अलग लेकिन संबंधित मुद्दा: Claude Code user का email system prompts में और कभी-कभी HTTP headers (User-Agent) में भी शामिल करता है, जब sites contact info माँगती हैं (जैसे SEC, Wikipedia, Crossref)।
  • कुछ उपयोगकर्ता plugins के जरिए इसे patch out करते हैं; अन्य मानते हैं कि agent को व्यक्तिगत identifiers भेजने से पहले हमेशा consent माँगना चाहिए।
  • prompt-injection scenarios को लेकर चिंता है, जहाँ third-party sites स्पष्ट user approval के बिना PII exfiltrate कर सकती हैं या sensitive tool calls trigger कर सकती हैं; अन्य लोग current leaks (जैसे UA में email) को मामूली मानते हैं, लेकिन बेहतर mechanisms की आवश्यकता से सहमत हैं।