token बर्बादी दिखाई नहीं देती क्योंकि यह failure नहीं, duplication होती है—एक ही file को दो बार पढ़ना, वही arguments देकर retry करना, वही tool फिर से call करना। इसलिए मैंने एक CLI बनाया है जो पूरी हो चुकी traces को पढ़कर बताता है कि किस step ने पहले किया हुआ काम फिर से किया!
[आजमाकर देखें]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
बिना sign-up के local पर चलता है। torch डाउनलोड नहीं करता, इसलिए install कुछ ही seconds में पूरा हो जाता है। Python 3.12 या उससे ऊपर। Claude Code session files ~/.claude/projects/ के नीचे मिलती हैं।
यह public Claude Code session (258 turns) पर चलाने का असली output है:
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[फैसला कैसे किया जाता है]
यह Langfuse या Phoenix की तरह traces को store और visualize नहीं करता। यह पहले से खत्म हो चुकी traces को पढ़कर सिर्फ waste को pinpoint करता है।
यह 2 steps में होता है। पहले उसी tool को समान arguments के साथ call किए गए cases को group करता है, फिर देखता है कि output का sha256 पूरी तरह same है या नहीं। अगर output अलग है, तो state बदली मानी जाती है और उसे waste नहीं माना जाता।
कोई LLM-based judgement नहीं है। वही trace डालेंगे तो हमेशा वही result आएगा।
मिली हुई waste को चार categories में classify किया जाता है: error repeat (same error को root cause ठीक किए बिना retry करना), side-effect rerun (state बदलने वाले tool को same arguments से फिर call करना), gray area (read-only repetition — side effect नहीं, लेकिन tokens खर्च होते हैं), और unclassified। Bash या PowerShell जैसे tools, जिनका effect arguments की content के हिसाब से पूरी तरह बदल सकता है, उन्हें सिर्फ नाम के आधार पर judge नहीं किया जाता और unclassified छोड़ा जाता है।
[public data में क्या मिला]
Toolathlon benchmark (22 frontier models × 3 runs, 6,780 traces, 176,270 tool spans) पर जैसे का तैसा चलाया, तो 8,042 duplicate calls मिले।
इस number को ज्यों का त्यों इस्तेमाल करना inflated होगा। 47% gray area था (जैसे task-completion declaration repeat करना, पहले से मौजूद directory फिर से बनाना), इसलिए उन्हें हटाने के बाद 4,251 cases बचे। tool span के मुकाबले 2.41%।
सबसे ज्यादा ध्यान खींचने वाली बात state बदलने वाले tools की 1,343 duplicate executions थीं, जिनमें से same arguments से repeated email sending के 459 cases थे। हालांकि यह सिर्फ इतना detect करता है कि "same tool same arguments के साथ दो बार call हुआ"; सच में email दो बार गया या नहीं, यह सिर्फ trace से confirm नहीं किया जा सकता।
[जो unexpected था]
Claude Code खुद उम्मीद से ज्यादा efficient था। file re-read और बेकार retry जैसे candidate patterns को छह बार measure किया, लेकिन पांच बार ये CC की real sessions में लगभग मौजूद ही नहीं थे। caching और context retention से ये पहले ही रोक दिए गए थे।
ज्यादा waste उन environments में थी जहां कई MCP servers जोड़े गए थे। 20 tools वाले CC (0.80%) और 523 tools वाले Toolathlon (2.41%) में 3x का फर्क था।
[सीमाएं]
measured savings के cases अभी नहीं हैं। detect और estimate किया जा सकता है, लेकिन किसी ने इसे देखकर कुछ fix किया और bill सच में कम हुआ—ऐसा data 0 cases है।
gray area वाले 47% को filter out नहीं किया जाता, सिर्फ classify करके दिखाया जाता है। read-only repetition सच में waste है या नहीं, यह execution context पर निर्भर करता है, और यह हिस्सा मैं judge नहीं कर सकता।
Cursor और Codex अभी support नहीं हैं।
validation में fail होने वाले detectors को discard कर दिया जाता है। file re-read detector बनाया था, लेकिन 30 samples में precision 70% threshold से काफी नीचे रहा (generous estimate में भी 3.3%, strict में 0%), इसलिए उसे बंद कर दिया, और preregistration document में prediction और results दोनों छोड़ दिए।
[समापन...]
मैं इस field में research और validation जारी रखूंगा!
readme English में है, इसके लिए माफ़ी.. रोने वाला चेहरा
अगर आप इसे इस्तेमाल करें और लगे कि ये हिस्से बेहतर होने चाहिए या ये चीजें add होनी चाहिए, तो feedback पाना चाहूंगा!
आगे भी clew में आपकी दिलचस्पी बनी रहे, धन्यवाद...!!
1 टिप्पणियां
[आपको पढ़ने में असुविधा न हो, इसलिए मैंने README का Korean अनुवाद लिख दिया है!]
Clew
एजेंट ट्रेस में बेकार हुए काम को खोजने वाला एक deterministic detector।
Clew पूरी हो चुकी AI एजेंट execution traces को पढ़कर ऐसे steps ढूंढता है जिन्होंने पहले से किए गए काम को दोहराया हो — उसी tool को उसी arguments के साथ फिर से call करना, failed call को उसी arguments के साथ retry करना, context में पहले से मौजूद जानकारी को फिर से query करना। यह LLM judgment के बिना काम करता है, इसलिए वही trace देने पर हर बार वही result मिलता है।
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdpublic Claude Code sessions पर चलाए गए actual output का उदाहरण:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsयह क्यों महत्वपूर्ण है
AI coding agent sessions में यह बर्बादी सिर्फ bill आने पर दिखती है। सभी tool calls 200 return करते हैं, और कुछ भी error नहीं देता, इसलिए बर्बादी दिखती नहीं है। लेकिन trace के अंदर एजेंट एक ही file को दो बार पढ़ता है, failed call को उसी arguments के साथ retry करता है, और उसी tool को उसी payload के साथ फिर से बुलाता है।
क्योंकि coding agent sessions में read operation tokens का 65~90% हिस्सा ले लेते हैं, ऐसी बर्बादी बिना ध्यान दिए जमा होती रहती है। observability tools traces तो दिखाते हैं, लेकिन कौन-सा step duplicate था यह नहीं बताते।
क्या detect करता है
Clew तीन तरह के duplicate patterns ढूंढता है:
repeat — वही tool/node बार-बार call होता है
requery — वही tool उसी input के साथ फिर से call होता है (output समान)
pingpong — दो एजेंट लगभग वही सामग्री एक-दूसरे को भेजते हैं (multi-agent)
हर finding को चार श्रेणियों में वर्गीकृत किया जाता है:
error_repeat — output error है, लेकिन वही call दोहराई जाती है
side_effect — state बदलने वाले tools (send/write/create आदि) को फिर से चलाना
idempotent — read-only/declarative tools को दोहराना (side effect नहीं, पर tokens खर्च होते हैं)
unclassified — mapping में नहीं आने वाले tools। effect payload पर निर्भर करता है, इसलिए सिर्फ tool name से अनुमान नहीं लगाया जाता (Bash/PowerShell आदि)
[यह कैसे काम करता है]
यह 2-stage cascade है:
structure gate — उसी tool को उन्हीं (normalized) arguments के साथ call किए गए मामलों को group करता है
identity gate — जांचता है कि output का sha256 पूरी तरह match करता है या नहीं। अलग होने पर state बदल चुकी मानी जाती है, इसलिए flag नहीं किया जाता
सस्ता structural check पहले candidates छांटता है, और महंगा semantic check (embedding+cosine) सिर्फ जरूरत पड़ने पर चलता है। LLM judgment न होने से results deterministic रहते हैं — अगर इसे CI में डालना हो तो यह महत्वपूर्ण है।
[input formats]
Claude Code — session JSONL को सीधे analyze करता है
LangGraph — trace में chain duplication detect करता है
LangChain·CrewAI·AutoGen·LlamaIndex आदि — OpenTelemetry/OpenInference standard format में instrumented traces को parse करता है (format support है, framework-specific empirical validation अभी चल रही है)
public benchmark traces (Toolathlon, RedundancyBench)
Cursor और Codex sessions अभी supported नहीं हैं — local formats की समीक्षा चल रही है।
[validation results]
public benchmark (Toolathlon, 6,780 traces, 176,270 tool spans):
8,042 duplicate calls detect हुईं। इनमें 47% gray area थीं (idempotent operations, completion declarations), और इन्हें हटाने पर 4,251 बचती हैं (tool spans के मुकाबले 2.41%)। यह Claude Code sessions (0.80%) की तुलना में लगभग 3 गुना है।
state-changing tools के 1,343 duplicate executions detect हुए, जिनमें 459 बार वही email उसी arguments के साथ बार-बार भेजी गई। हालांकि, यह सिर्फ इतना detect करता है कि वही tool उसी arguments के साथ duplicate call हुआ; actual side effect हुआ या नहीं, इसकी पुष्टि नहीं हुई है।
labeling benchmark (RedundancyBench):
precision 0.826 (file के भीतर duplication के लिए lower-bound estimate)। RB labels का बड़ा हिस्सा cross-file duplication है, जो session-level analysis design के दायरे से बाहर है। recall 0.157 है, जो कम है।
[ईमानदार सीमाएँ]
मापी गई savings का अभी कोई case नहीं है। detect और estimate तो किया जा सकता है, लेकिन किसी real user ने कुछ सुधारकर bill वास्तव में कम किया हो, ऐसा before/after data 0 है।
benchmark में flag हुई चीज़ों में 47% gray area हैं (idempotent re-execution)। इन्हें filter नहीं किया जाता, सिर्फ classify किया जाता है — क्योंकि read-only re-execution सच में waste थी या नहीं, यह ऐसे context पर निर्भर करता है जो दिखाई नहीं देता।
क्योंकि sha256 का exact match जरूरी है, output थोड़ा भी अलग हो तो flag नहीं किया जाता। recall कम होने का यही कारण है, और design precision की तरफ झुका हुआ है।
Claude Code असामान्य रूप से अच्छी तरह optimized है। actual CC sessions में छह candidate waste patterns मापे गए थे, जिनमें से पाँच वहाँ मौजूद ही नहीं थे। दिलचस्प बर्बादी CC में नहीं, बल्कि multi-tool MCP environments में दिखी।
cost estimation (amplification) measurement नहीं, estimation है, और यह सिर्फ Claude Code format में संभव है।
जो validate नहीं होता, उसे हटा दिया जाता है
मैंने file re-read detector बनाया था, लेकिन 30-sample human annotation में उसकी precision pre-registered threshold (70%) से काफी नीचे निकली (उदारता से देखें तो 3.3%, सख्ती से देखें तो 0%), इसलिए उसे हटा दिया गया। prediction और results दोनों pre-registration document में साथ छोड़े गए हैं।