Claude Code का सत्र-वार उपयोग: कैसे देखें कि कौन-सा सत्र आपका प्लान खा रहा है

Claude Code के कई सत्र एक साथ चलाइए, और आपकी साप्ताहिक सीमा उम्मीद से तेज़ घटने लगती है। आप जानना चाहते हैं कि कौन-सा सत्र उसे खा रहा है, पर /usage खोलने पर भी इसका जवाब नहीं मिलता।

सीधा जवाब: सितंबर 2026 तक ऐसी कोई आधिकारिक स्क्रीन नहीं है जो दिखाए कि हर सत्र ने आपके उपयोग का कितना हिस्सा लिया। /usage मौजूदा सत्र के आँकड़े देता है, और साथ में पूरे प्लान की खपत को स्किल, सबएजेंट, प्लगइन और MCP सर्वर के हिसाब से प्रतिशत में बाँटकर दिखाता है। सत्र के हिसाब से देखना हो, तो आपको अपनी ही मशीन पर सहेजे गए बातचीत लॉग ख़ुद जोड़ने होंगे।

पर उन लॉग को बिना सोचे-समझे गिनेंगे तो नतीजा ग़लत आएगा। मैंने अपनी मशीन पर पिछले 7 दिनों के लॉग मापे, तो पंक्तियों को सीधे जोड़ने पर कुल आँकड़ा सही मान का 2.06 गुना निकला। इससे भी बुरा यह कि सबसे ज़्यादा उपयोग वाले सिर्फ़ 12 सत्रों में ही यह त्रुटि 1.30 गुना से 3.02 गुना तक बदलती रही, इसलिए क्रम भी बदल गया। यह लेख बताता है कि आधिकारिक स्क्रीन क्या दिखाती हैं, सही ढंग से कैसे गिनें, लगभग 50 पंक्तियों की एक गिनती स्क्रिप्ट, और मेरे माप के नतीजे।

1. आधिकारिक स्क्रीन क्या दिखाती हैं, और क्या नहीं

उपयोग बताने वाली मुख्य आधिकारिक जगहें ये हैं (सितंबर 2026 तक)। इनमें से कोई भी हर सत्र का हिस्सा नहीं दिखाती। सबसे क़रीब /usage का प्लान ब्यौरा है, पर उसकी धुरी यह है कि उपयोग किस फ़ीचर पर गया, यह नहीं कि किस सत्र ने किया।

स्रोत: Claude Code आधिकारिक दस्तावेज़, Manage costs effectively (/usage, /insights, संगठन डैशबोर्ड), Claude Code आधिकारिक दस्तावेज़, Desktop (उपयोग रिंग), Claude Help Center, Usage limit best practices (Settings का उपयोग पेज), Claude Code आधिकारिक दस्तावेज़, Monitoring (OpenTelemetry)

/usage के प्लान ब्यौरे के बारे में दस्तावेज़ एक और अहम बात कहता है: "आँकड़े अनुमानित हैं और इस मशीन के लोकल सत्र इतिहास से निकाले जाते हैं, इसलिए दूसरे डिवाइस या claude.ai का उपयोग इसमें शामिल नहीं है।" यानी आधिकारिक ब्यौरा भी आख़िरकार आपके लोकल लॉग से ही आता है। वही लॉग ख़ुद पढ़ें, तो आप उन्हें उस धुरी पर भी जोड़ सकते हैं जिसे आधिकारिक स्क्रीन छोड़ देती हैं: सत्र। अगर आप सीमा से टकरा चुके हैं और देखना चाहते हैं कि कितना बचा है, तो Claude Code "usage limit reached" की व्याख्या देखें।

2. जवाब आपकी मशीन के बातचीत लॉग में है

Claude Code हर बातचीत का पूरा रिकॉर्ड JSONL (हर पंक्ति में एक JSON ऑब्जेक्ट) के रूप में सहेजता है, हर सत्र की एक फ़ाइल। ये कहाँ रहती हैं, यह दस्तावेज़ में लिखा है।

स्रोत: Claude Code आधिकारिक दस्तावेज़, Explore the .claude directory

मेरी मशीन पर <प्रोजेक्ट> फ़ोल्डर का नाम काम वाले फ़ोल्डर का पूरा (absolute) पाथ था, जिसमें चिह्नों को - से बदल दिया गया था (D:\work\site-a बन जाता है D--work-site-a)। डेस्कटॉप ऐप के Code टैब से चलाए गए सत्र भी इसी जगह लिखे गए थे, और हर पंक्ति पर "entrypoint":"claude-desktop" दर्ज था।

आपको वह usage जोड़ना है जो Claude के जवाब दर्ज करने वाली पंक्तियों ("type":"assistant") के साथ लगा होता है। यह रही एक असली पंक्ति, जिसमें सिर्फ़ गिनती में काम आने वाले फ़ील्ड रखे गए हैं (ID छिपाई गई हैं)।

{"type":"assistant","requestId":"req_…","timestamp":"2026-07-25T00:16:37.822Z",
 "message":{"id":"msg_…","model":"claude-opus-5",
  "content":[{"type":"text","text":"…"}],
  "usage":{"input_tokens":2,"output_tokens":255,
           "cache_read_input_tokens":33775,"cache_creation_input_tokens":17265,
           "cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":17265}}}}

usage की चार संख्याएँ (इनपुट, आउटपुट, कैश रीड, कैश राइट) Claude API के जवाब के आधिकारिक फ़ील्ड हैं। लेकिन लॉग फ़ाइल का अपना फ़ॉर्मेट, यानी हर पंक्ति में क्या लिखा जाता है, आधिकारिक रूप से कहीं दर्ज नहीं है। इस लेख का गिनती का तरीक़ा मैंने v2.1.197 से v2.1.260 तक के अपने लॉग पर जाँचा है, और आगे के संस्करणों में यह काम करना बंद कर सकता है।

दस्तावेज़ एक और सावधानी साफ़ लिखता है: "ट्रांसक्रिप्ट और इतिहास डिस्क पर एन्क्रिप्ट नहीं होते। OS की फ़ाइल अनुमतियाँ ही एकमात्र सुरक्षा हैं।" अगर कोई टूल .env फ़ाइल पढ़ता है, तो उसकी सामग्री भी लॉग में पहुँच जाती है। जोड़े हुए नतीजे दूसरों को दिखाना ठीक है, पर लॉग ख़ुद किसी को सौंपते समय, या किसी ऐसे टूल से पढ़वाते समय जिसे आप ठीक से नहीं जानते, सावधान रहें।

3. सीधे जोड़ें तो लगभग दोगुना आता है: चार जाल

usage वाली पंक्तियाँ ढूँढें और सबको जोड़ दें। यही सबसे सीधा तरीक़ा लगता है, पर मेरे लॉग में कुल आँकड़ा सही मान का लगभग दोगुना निकला। इसकी चार वजहें हैं।

जाल 1: एक जवाब कई पंक्तियों में लिखा जाता है

Claude का एक जवाब (एक API अनुरोध) ज़रूरी नहीं कि लॉग में एक ही पंक्ति हो। मेरी मशीन पर हर सामग्री खंड, जैसे सोच (thinking), टेक्स्ट या टूल कॉल, अपनी अलग पंक्ति में लिखा गया था (99.9% से ज़्यादा पंक्तियों में ठीक एक खंड था), और उनमें से हर पंक्ति पर usage लगा था। किसी जवाब की पहचान message.id और requestId की जोड़ी से होती है।

दो या ज़्यादा पंक्तियों में लिखे गए 142,345 जवाबों में से 76% में हर पंक्ति पर बिल्कुल एक-सा usage था। बाक़ी 24% में आउटपुट टोकन का मान पंक्ति-दर-पंक्ति अलग था। इसलिए हर जवाब के लिए सिर्फ़ वह एक पंक्ति रखें जिसमें आउटपुट टोकन सबसे ज़्यादा हों। इसके अलावा, 1,903 जवाब किसी दूसरी फ़ाइल में भी मौजूद थे (कुल टोकन का 0.95%)। इसकी वजह मैंने नहीं खोजी, पर एक ही कुंजी पर सबको एक कर देने से ये भी दो बार नहीं गिने जाते।

जाल 2: सबएजेंट के रिकॉर्ड अलग फ़ाइलों में होते हैं

सिर्फ़ मुख्य .jsonl फ़ाइलें पढ़ेंगे तो सबएजेंट पूरी तरह छूट जाएँगे। मेरे लॉग में, सही कुल आँकड़ों में सबएजेंट का हिस्सा यह था।

• इनपुट (कैश के बाहर): 42.9%
• आउटपुट: 23.2%
• कैश राइट: 10.8%
• कैश रीड: 6.9%

सत्र के स्तर पर फ़ासला और भी बड़ा है: पिछले 7 दिनों में, मूल्य से भारित करने पर, यह 0% वाले सत्रों से लेकर 54% वाले एक सत्र तक गया। कोई सत्र जितना ज़्यादा काम सबएजेंट को सौंपता है, सिर्फ़ मुख्य फ़ाइल गिनने पर वह उतना ही छोटा दिखता है।

जाल 3: दोनों त्रुटियाँ कुछ हद तक एक-दूसरे को काटती हैं, पर हर सत्र में अलग ढंग से

मुख्य फ़ाइलों की पंक्तियाँ जैसी हैं वैसी जोड़ें, तो जाल 1 गिनती को फुलाता है और जाल 2 उसे घटाता है। पिछले 7 दिनों में कुल आँकड़ा सही मान का 2.06 गुना निकला। अगर हर सत्र एक ही गुणक से ग़लत होता, तो हिस्से फिर भी सही रहते। असल में ऐसा नहीं हुआ।

स्रोत: मेरा अपना माप (15 सितंबर 2026 तक के पिछले 7 दिन। तुलना आसान बनाने के लिए सिर्फ़ इस तालिका में बिना भार वाली टोकन गिनती इस्तेमाल की गई है, सबएजेंट के हिस्से में भी। सत्रों के अक्षर ऊपर के चित्र से मेल खाते हैं)

दूसरा और तीसरा स्थान आपस में बदल गए, चौथा और पाँचवाँ भी, और G, जो असल में 9वें स्थान पर था, 6वें पर चढ़ गया। D का सबएजेंट पर निर्भर होने की वजह से छोटा दिखना ठीक जाल 2 है, पर E, जिसका सबएजेंट हिस्सा D जितना ही 39% है, उल्टी दिशा में 2.60 गुना पर गया। हर जवाब कितनी पंक्तियों में बँटता है (उसमें कितनी सोच और कितने टूल कॉल हैं), इसका भी असर पड़ता है, इसलिए गुणक का पहले से अनुमान नहीं लगाया जा सकता। "बस दो से भाग दे दो" वाला तरीक़ा काम नहीं करता।

जाल 4: 97% टोकन कैश रीड हैं

सही गिनती कर लेने के बाद भी, कच्ची टोकन गिनती की तुलना करने से यह ग़लत आँका जाता है कि कौन-सा सत्र कितना भारी है। पिछले 7 दिन इन चीज़ों से बने थे।

पर इनकी प्रति-इकाई क़ीमतें बिल्कुल बराबर नहीं हैं। Anthropic के आधिकारिक मूल्य पेज पर कैश रीड की क़ीमत बेस इनपुट क़ीमत की 0.1 गुना है (Claude Fable 5.1 और Claude Mythos 5.1 पर 0.025 गुना), 5 मिनट वाले कैश राइट की 1.25 गुना और 1 घंटे वाले की 2 गुना, और हर मौजूदा मॉडल पर आउटपुट इनपुट क़ीमत का 5 गुना है। सत्र C, जिसके पास टोकन का 12.7% था, इन क़ीमतों से भारित करने पर 10.4% पर आ गया।

संख्याओं का आकार भी कुछ बताता है। शीर्ष 12 सत्रों में से D और E को छोड़कर बाक़ी 10 ने हर जवाब में औसतन लगभग 4.1 लाख से 4.8 लाख टोकन का कॉन्टेक्स्ट पढ़ा (सबएजेंट पर निर्भर D और E का औसत लगभग 2.4 लाख और 3.1 लाख था)। "Claude Code हर अनुरोध के साथ आपकी पूरी बातचीत भेजता है", इसलिए कोई सत्र जितनी देर खुला रहता है, हर अनुरोध उतना ही भारी होता जाता है। यह कैसे होता है, इसे Claude Code का कॉन्टेक्स्ट खा कौन रहा है? मापने का तरीक़ा में विस्तार से समझाया गया है।

4. गिनती की स्क्रिप्ट

यह गिनती स्क्रिप्ट चारों जालों का ध्यान रखती है। यह सिर्फ़ Python 3 की स्टैंडर्ड लाइब्रेरी पर चलती है (मैंने 3.11 पर जाँची)। यह लॉग सिर्फ़ पढ़ती है, न कुछ बदलती है, न कहीं भेजती है। अगर आपने CLAUDE_CONFIG_DIR एनवायरनमेंट वेरिएबल से अपनी कॉन्फ़िगरेशन डायरेक्टरी कहीं और रखी है, तो यह वहीं से पढ़ती है।

import json, os, sys
from collections import defaultdict
from datetime import datetime, timedelta, timezone
from pathlib import Path

DAYS = float(sys.argv[1]) if len(sys.argv) > 1 else 7
ROOT = Path(os.environ.get("CLAUDE_CONFIG_DIR") or Path.home() / ".claude") / "projects"
SINCE = datetime.now(timezone.utc) - timedelta(days=DAYS)
# USD per 1M input tokens (output = 5x). First match wins.
PRICES = [("sonnet-5", 2), ("sonnet", 3), ("haiku", 1), ("opus-4-1", 15),
          ("opus-4-2025", 15), ("opus", 5), ("fable", 10), ("mythos", 10)]

best = {}  # one API response = one (message.id, requestId)
for path in ROOT.rglob("*.jsonl"):  # also reads <session>/subagents/*.jsonl
    project = path.relative_to(ROOT).parts[0]
    with path.open(encoding="utf-8", errors="replace") as f:
        for line in f:
            if '"usage"' not in line:
                continue
            try:
                row = json.loads(line)
            except ValueError:
                continue
            msg = row.get("message") or {}
            usage = msg.get("usage")
            ts = row.get("timestamp")
            if row.get("type") != "assistant" or not usage or not ts:
                continue
            if datetime.fromisoformat(ts.replace("Z", "+00:00")) < SINCE:
                continue
            key = (msg.get("id"), row.get("requestId"))
            old = best.get(key)
            if old is None or usage.get("output_tokens", 0) >= old[2].get("output_tokens", 0):
                best[key] = (project, msg.get("model") or "", usage)

totals = defaultdict(lambda: [0, 0.0])  # [tokens, weight]
for project, model, u in best.values():
    p = next((v for name, v in PRICES if name in model), 5)
    read_rate = 0.025 if "5-1" in model and ("fable" in model or "mythos" in model) else 0.1
    inp, out = u.get("input_tokens", 0), u.get("output_tokens", 0)
    read, write = u.get("cache_read_input_tokens", 0), u.get("cache_creation_input_tokens", 0)
    write_1h = (u.get("cache_creation") or {}).get("ephemeral_1h_input_tokens", 0)
    totals[project][0] += inp + out + read + write
    totals[project][1] += p * (inp + out * 5 + read * read_rate
                               + (write - write_1h) * 1.25 + write_1h * 2)

all_tokens = sum(t for t, _ in totals.values()) or 1
all_weight = sum(w for _, w in totals.values()) or 1
print(f"last {DAYS:g} days: {len(best):,} responses")
print(f"{'weight':>7} {'tokens':>7}  project")
for project, (t, w) in sorted(totals.items(), key=lambda kv: -kv[1][1]):
    print(f"{w / all_weight:7.1%} {t / all_tokens:7.1%}  {project}")

इसे usage_by_session.py जैसे किसी नाम से सहेजें और दिनों की संख्या आर्ग्युमेंट के रूप में दें। न दें तो पिछले 7 दिन मिलते हैं।

python usage_by_session.py        # पिछले 7 दिन
python usage_by_session.py 1      # पिछले 24 घंटे
python usage_by_session.py 30     # पिछले 30 दिन

आउटपुट ऐसा दिखता है (फ़ोल्डर के नाम छिपाए गए हैं)। weight मूल्य से भारित हिस्सा है और tokens कच्ची टोकन गिनती के हिसाब से हिस्सा।

last 7 days: 19,991 responses
 weight  tokens  project
  32.3%   31.7%  D--work-project-a
  11.1%   11.4%  D--work-project-b
  10.4%   12.7%  D--work-project-c
   7.7%    8.6%  D--work-project-d
   6.4%    5.4%  D--work-project-e

5. माप का नतीजा: 29 में से एक सत्र ने लगभग एक-तिहाई खर्च किया

पिछले 7 दिनों में मेरी मशीन पर 29 सत्र सक्रिय थे। जैसा ऊपर के चित्र में दिखता है, उपयोग उनमें से मुट्ठी भर सत्रों में ही सिमटा हुआ था।

आँकड़ों को साथ-साथ रखने पर तीन बातें सामने आईं।

पहली, ऊपर वाले सत्र हर एक अनुरोध पर भारी हैं। शीर्ष 3 सत्रों ने हर जवाब में औसतन लगभग 4.1 लाख से 4.8 लाख टोकन पढ़े। बात सिर्फ़ ज़्यादा अनुरोधों की नहीं है: वे पूरे दिन खुले रहे और उनका कॉन्टेक्स्ट बढ़ता रहा। दस्तावेज़ भी बताता है कि देर तक खुले छोड़े गए सत्र में एक पंक्ति का सवाल भी पूरी बातचीत जितना उपयोग खड़ा कर देता है।

दूसरी, सबएजेंट पर निर्भर सत्र मुख्य बातचीत से देखने पर छोटे लगते हैं। D और E में मूल्य-भारित उपयोग का क्रमशः 44% और 54% हिस्सा सबएजेंट का था। साइडबार में मुख्य बातचीत देखते हुए वह हिस्सा आपको कभी नहीं दिखता।

तीसरी, आधे से ज़्यादा सत्रों ने लगभग कुछ भी खर्च नहीं किया। आपकी सीमा इसलिए तेज़ नहीं घटती कि आपके बहुत सारे सत्र खुले हैं; उसे कुछ भारी सत्र घटाते हैं। कुछ करना हो, तो उन्हीं कुछ सत्रों से शुरू करना काफ़ी है। सबसे पहले क्या काटना है, यह Claude Code में टोकन बचाने के तरीक़े और सीमा पार होने पर लगने वाला शुल्क में बताया गया है।

6. आँकड़ों को कैसे पढ़ें, और वे कहाँ तक साथ देते हैं

7. आगे लगातार नज़र रखनी हो तो OpenTelemetry

लॉग जोड़ने की ताक़त यह है कि पिछले 30 दिन आप तुरंत देख सकते हैं। अगर इसके बजाय आप अब से आगे लगातार नज़र रखना चाहते हैं, तो आधिकारिक निगरानी फ़ीचर OpenTelemetry बेहतर है।

इसे चालू करने पर Claude Code एक टोकन मेट्रिक claude_code.token.usage (प्रकार input, output, cacheRead और cacheCreation) और एक लागत मेट्रिक claude_code.cost.usage निर्यात करता है। दोनों में डिफ़ॉल्ट रूप से session.id रहता है (OTEL_METRICS_INCLUDE_SESSION_ID, डिफ़ॉल्ट true)। चूँकि यह लॉग फ़ाइलें नहीं पढ़ता, जाल 1 की डुप्लिकेट पंक्तियाँ इसमें आती ही नहीं, और सबएजेंट का उपयोग query_source (main, subagent, auxiliary) के तहत अलग दर्ज होता है।

पहले लोकल रूप से आज़माना हो, तो दस्तावेज़ में दिखाए अनुसार एक्सपोर्टर को टर्मिनल पर छापने के लिए सेट करके Claude Code शुरू करें।

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000
claude

लगातार गिनती के लिए OTEL_METRICS_EXPORTER=otlp सेट करें और डेटा अपनी ख़ुद चलाई किसी जगह पर भेजें (OTLP स्वीकार करने वाला कोई निगरानी बैकएंड)। वह जगह आपको ख़ुद बनानी पड़ती है, और इसे चालू करने से पहले का कुछ भी दर्ज नहीं होता: लॉग जोड़ने से यही अंतर हैं।

स्रोत: Claude Code आधिकारिक दस्तावेज़, Monitoring (मेट्रिक के नाम, एट्रिब्यूट, एनवायरनमेंट वेरिएबल)

FAQ

Q1. क्या /usage का प्लान ब्यौरा काफ़ी नहीं है?
यह दूसरी धुरी पर मापता है। प्लान ब्यौरा प्रतिशत में दिखाता है कि उपयोग किन स्किल, सबएजेंट, प्लगइन और MCP सर्वर पर गया, और यह नहीं दिखाता कि किस सत्र ने उसे खर्च किया। आपकी सीमा को क्या घटा रहा है, यह फ़ीचर की तरफ़ से खोजना हो तो /usage इस्तेमाल करें; सत्र की तरफ़ से खोजना हो तो इस लेख की गिनती।

Q2. क्या कोई मौजूदा गिनती टूल इस्तेमाल किया जा सकता है?
हाँ। उदाहरण के लिए, अनौपचारिक टूल ccusage इन्हीं लॉग से सत्र-वार रिपोर्ट बना सकता है। इस्तेमाल से पहले दो बातें जाँच लें। पहली, क्या सारी प्रोसेसिंग आपकी मशीन पर ही रहती है: लॉग में टूल के नतीजे बिना एन्क्रिप्शन के रहते हैं। दूसरी, वह गिनता कैसे है: यह पक्का करने के लिए कि वह डुप्लिकेट पंक्तियों और सबएजेंट को उसी तरह सँभालता है, एक बार उसके आउटपुट को इस लेख की स्क्रिप्ट के नतीजे से मिलाकर देखें।

Q3. दूसरी मशीनों और claude.ai का उपयोग भी शामिल करना है।
लॉग हर मशीन पर अलग-अलग ही रहते हैं, इसलिए हर मशीन पर गिनती करें और नतीजे आपस में जोड़ें। claude.ai की चैट Claude Code के लॉग में दर्ज नहीं होतीं। पूरे प्लान में कुल कितना बचा है, इसके लिए claude.ai पर Settings > Usage की प्रगति पट्टियाँ ही भरोसेमंद जगह हैं।

Q4. पुराना उपयोग भी गिन सकूँ, इसके लिए लॉग सँभालकर रखना चाहता हूँ।
टर्मिनल में इस्तेमाल हुए सत्रों के लिए settings.json में cleanupPeriodDays बढ़ा दें, तो वे ज़्यादा समय तक रहेंगे। डेस्कटॉप ऐप (या Cowork) में शुरू किए गए या आख़िरी बार वहीं जारी रखे गए सत्र v2.1.248 से पहले से ही उम्र की परवाह किए बिना बने रहते हैं (सीमा तय करनी हो तो desktopSessionCleanupPeriodDays इस्तेमाल करें)। पर ध्यान रहे कि दस्तावेज़ लॉग का जोखिम घटाने के एक तरीक़े के रूप में इन मानों को कम करने की बात करता है। आप इन्हें जितनी देर रखेंगे, बिना एन्क्रिप्शन वाले रिकॉर्ड उतनी ही देर आपकी मशीन पर पड़े रहेंगे, यह ध्यान में रखें।

स्रोत

• Claude Code Docs — Manage costs effectively (/usage का Session हिस्सा और प्लान उपयोग ब्यौरा, यह टिप्पणी कि आँकड़े इस मशीन के इतिहास से निकाले जाते हैं, /insights, संगठन डैशबोर्ड, लंबे सत्रों में उपयोग बढ़ने की वजह)
• Claude Code Docs — Explore the .claude directory (लॉग कहाँ रखे जाते हैं, subagents/, cleanupPeriodDays का डिफ़ॉल्ट 30 दिन और डेस्कटॉप ऐप के सत्रों के साथ क्या होता है, एन्क्रिप्शन का न होना)
• Claude Code Docs — Desktop (उपयोग रिंग)
• Claude Help Center — Usage limit best practices (Settings > Usage क्या दिखाता है)
• Claude Code Docs — Monitoring (OpenTelemetry मेट्रिक के नाम, session.id, एनवायरनमेंट वेरिएबल)
• Claude Platform Docs — Pricing (मॉडल-वार क़ीमतें, कैश के गुणक)

संबंधित लेख

• Claude Code का कॉन्टेक्स्ट खा कौन रहा है? मापने का तरीक़ा — हर जवाब भारी क्यों होता जाता है
• Claude Code "usage limit reached" की व्याख्या — जब आप सीमा से टकरा जाएँ
• Claude Code में टोकन बचाने के तरीक़े और सीमा पार होने पर लगने वाला शुल्क — सबसे पहले क्या काटें
• Claude Code की साप्ताहिक सीमा और जल्दी रीसेट — साप्ताहिक सीमा कैसे काम करती है