Claude Code कितना तेज़ है? टोकन प्रति सेकंड, 20,000 टर्न पर मापे गए

Claude Code आपको टोकन के बारे में बहुत कुछ बताता है। /usage दिखाता है कि आपने सत्र और हफ़्ते का कितना हिस्सा इस्तेमाल कर लिया है, AgentsRoom का सत्र मॉनिटर इनपुट, आउटपुट, कैश रीड और कैश राइट को टर्न दर टर्न गिनता है, और स्टेटस लाइन इस्तेमाल हो रहे कॉन्टेक्स्ट विंडो का हिस्सा दिखा सकती है। इनमें से कोई भी वह एक संख्या नहीं दिखाता जिसे लोग बार-बार खोजते हैं: जब आप इंतज़ार कर रहे होते हैं, तब मॉडल असल में प्रति सेकंड कितने टोकन बनाता है।

यह संख्या छिपी नहीं है, बस कभी निकाली नहीं जाती। हर सत्र का हर संदेश ~/.claude/projects/ के अंदर एक JSONL ट्रांसक्रिप्ट में पहुँचता है, और असिस्टेंट के हर संदेश में एक टाइमस्टैम्प और उसका टोकन उपयोग होता है। तो हमने इसे खुद निकाला, अपनी ही मशीन पर, पिछले चार हफ़्तों के डेटा पर। यह रहा तरीका, स्क्रिप्ट, और जो नतीजा निकला।

डेटा कहाँ से आता है

Claude Code हर सत्र के लिए एक फ़ाइल ~/.claude/projects/<project slug>/<session id>.jsonl में लिखता है। हर इवेंट की एक पंक्ति। यहाँ काम की पंक्तियाँ असिस्टेंट के संदेश हैं, और सिर्फ़ उपयोगी फ़ील्ड रखने पर हर एक कुछ ऐसी दिखती है:

{
  "type": "assistant",
  "uuid": "24d13076-…",
  "parentUuid": "d4447285-…",
  "requestId": "req_011CepWq…",
  "timestamp": "2026-09-07T18:00:08.412Z",
  "message": {
    "model": "claude-opus-5",
    "usage": {
      "input_tokens": 2,
      "cache_read_input_tokens": 0,
      "cache_creation_input_tokens": 51591,
      "output_tokens": 200,
      "output_tokens_details": { "thinking_tokens": 0 },
      "speed": "standard"
    }
  }
}

चार चीज़ें इस माप को संभव बनाती हैं:

• timestamp तब लिखा जाता है जब कंटेंट ब्लॉक जोड़ा जाता है, इसलिए किसी टर्न के आख़िरी ब्लॉक पर स्ट्रीम के अंत का समय होता है।
• parentUuid ठीक पिछली पंक्ति की ओर इशारा करता है, यानी वह उपयोगकर्ता संदेश या टूल का नतीजा जिसका मॉडल जवाब दे रहा था। उसका टाइमस्टैम्प वह पल है जब अनुरोध निकला।
• requestId एक API कॉल के ब्लॉकों को एक साथ रखता है। जो टर्न कुछ टेक्स्ट लिखता है और फिर एक टूल कॉल करता है, वह एक ही requestId और एक ही usage वाली दो असिस्टेंट पंक्तियाँ बनाता है, इसलिए टोकन हर अनुरोध पर एक बार गिने जाने चाहिए, हर पंक्ति पर नहीं।
• usage.output_tokens अनुरोध का कुल आउटपुट है, थिंकिंग समेत; output_tokens_details.thinking_tokens बताता है कि उसमें से कितना थिंकिंग था।

फ़ाइल में कुछ भी पहले टोकन तक का समय नहीं बताता। जो आप माप सकते हैं वह पूरा टर्न है: अनुरोध के आपकी मशीन से निकलने से लेकर आख़िरी टोकन के पहुँचने तक। इंतज़ार करते समय आप यही एक संख्या महसूस करते हैं, इसलिए हमने यही रखी।

तरीका

हर requestId के लिए: उसे रखने वाली पहली और आख़िरी असिस्टेंट पंक्ति लें, पहली पंक्ति से usage पढ़ें, पहली पंक्ति का पैरेंट ढूँढें, और आउटपुट टोकन को पैरेंट के टाइमस्टैम्प और आख़िरी पंक्ति के टाइमस्टैम्प के बीच के सेकंड से भाग दें। फिर हर मॉडल का वितरण देखें, कभी एक अकेला औसत नहीं, क्योंकि 40 सेकंड का टर्न और 2 सेकंड का टर्न एक जैसी चीज़ नहीं हैं।

हमने वे टर्न हटाए जिनमें कोई आउटपुट टोकन नहीं था, वे टर्न जिनकी अवधि शून्य या ऋणात्मक थी (फिर से शुरू किए गए सत्र में पैरेंट का समय उसके चाइल्ड के बाद का हो सकता है) और पंद्रह मिनट से लंबे टर्न, जो लंबे जवाब नहीं बल्कि बीच में रुके सत्र होते हैं। इसके अलावा कुछ भी फ़िल्टर नहीं किया गया।

स्क्रिप्ट Python की 40 पंक्तियाँ है, बिना किसी डिपेंडेंसी के। इसे कहीं से भी चलाएँ; यह मशीन के सभी प्रोजेक्ट पढ़ती है।

import json, glob, os, statistics as st
from datetime import datetime
from collections import defaultdict

def ts(s): return datetime.fromisoformat(s.replace("Z", "+00:00")).timestamp()

turns = []
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    by_uuid, groups, order = {}, {}, []
    with open(path) as fh:
        for line in fh:
            try: o = json.loads(line)
            except ValueError: continue
            if "uuid" in o: by_uuid[o["uuid"]] = o
            msg = o.get("message") or {}
            if o.get("type") == "assistant" and msg.get("usage") and o.get("timestamp"):
                rid = o.get("requestId") or o["uuid"]
                if rid not in groups: groups[rid] = []; order.append(rid)
                groups[rid].append(o)
    for rid in order:
        first, last = groups[rid][0], groups[rid][-1]
        out = first["message"]["usage"].get("output_tokens", 0)
        parent = by_uuid.get(first.get("parentUuid"))
        if not parent or not parent.get("timestamp") or out <= 0: continue
        dur = ts(last["timestamp"]) - ts(parent["timestamp"])
        if 0 < dur <= 900:
            turns.append((first["message"].get("model"), out, dur))

by_model = defaultdict(list)
for model, out, dur in turns: by_model[model].append((out, dur))
for model, rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    rates = [o / d for o, d in rows]
    print(f"{model:18s} turns={len(rows):6d} median={st.median(rates):5.1f} tok/s "
          f"weighted={sum(o for o, _ in rows) / sum(d for _, d in rows):5.1f} tok/s")

weighted कॉलम कुल टोकन को कुल सेकंड से भाग देने पर मिलता है। एक लंबा ऑटोनॉमस रन यही अनुभव करता है; मीडियन वह है जो एक अकेला इंटरैक्टिव टर्न अनुभव करता है।

आंकड़े

फ़्रांस में एक Mac, 319 ट्रांसक्रिप्ट, 27 अगस्त से 25 सितंबर 2026 के बीच 20,408 टर्न, 45 घंटे के जनरेशन में बने 12.0 मिलियन आउटपुट टोकन। हर टर्न पर स्टैंडर्ड स्पीड (नीचे फ़ास्ट मोड देखें)। ट्रांसक्रिप्ट में पाँच मॉडल उन नामों से दिखते हैं जो Claude Code लिखता है।

किसी और बात से पहले दो निष्कर्ष। पहला, Opus 5.5, Opus 5 से थोड़ा-सा तेज़ नहीं है, वह मीडियन पर डेढ़ गुना और वेटेड आंकड़े पर 57% तेज़ है, और उसमें लंबे टर्न का हिस्सा कहीं ज़्यादा है। दूसरा, एक ही मॉडल के भीतर का फैलाव मॉडलों के बीच के अंतर से बड़ा है: 25वें पर्सेंटाइल पर Opus 5 का टर्न 51 टोकन प्रति सेकंड स्ट्रीम करता है और 75वें पर 72। इसकी वजह टर्न का आकार है, और वह एक अलग सेक्शन की हक़दार है।

छोटा जवाब हमेशा धीमा होता है

यह फिर से Opus 5 है, टर्न के आउटपुट टोकन की संख्या के हिसाब से बाँटा गया:

वही मॉडल, वही महीना, वही मशीन, और एक पंक्ति के जवाब और लंबे जवाब के बीच दर दोगुनी हो जाती है। मॉडल लंबे टर्न पर तेज़ स्ट्रीम नहीं करता। हर टर्न पहला टोकन दिखने से पहले एक निश्चित लागत चुकाता है: अनुरोध जाता है, प्रॉम्प्ट प्रोसेस होता है, स्ट्रीम शुरू होती है। 80 टोकन वाले टर्न पर यह लागत बीते समय का एक तिहाई है; 3,000 टोकन वाले टर्न पर यह शोर में खो जाती है।

आउटपुट टोकन के सापेक्ष अवधि पर लीस्ट-स्क्वेयर्स फ़िट इन दोनों को अलग कर देता है। ढलान स्ट्रीमिंग स्पीड देती है, इंटरसेप्ट निश्चित लागत देता है:

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

डेटा का सबसे लंबा अकेला टर्न Opus 5 पर 236 सेकंड में 21,332 आउटपुट टोकन का है, यानी शुरू से अंत तक 90 टोकन प्रति सेकंड: निश्चित लागत बँट जाने के बाद, स्टैंडर्ड स्पीड पर उस मॉडल की यही ऊपरी सीमा हमने देखी।

थिंकिंग टोकन भी आउटपुट टोकन हैं

output_tokens में वह सोच शामिल है जो मॉडल जवाब देने से पहले करता है, और output_tokens_details.thinking_tokens बताता है कि कितनी। हमारे डेटा में थिंकिंग Opus 5 के कुल आउटपुट का 30%, Opus 5.5 का 18%, Fable 5.1 का 36%, और Sonnet 5 का 54% है, जिसे हमने ज़्यादातर रिव्यू के कामों पर ऊँचे एफ़र्ट लेवल पर चलाया।

धीमे टर्न को समझने में यह मायने रखता है। जो टर्न आठ सेकंड सोचता है और दो पंक्तियाँ लिखता है, वह धीमा मॉडल नहीं है, वह ऐसा टर्न है जिसने 600 टोकन बनाए जो आपने कभी देखे ही नहीं। थिंकिंग वाले टर्न, प्रति टोकन, बिना थिंकिंग वाले टर्न से थोड़े तेज़ हैं: Opus 5 पर 57 के मुकाबले 67 टोकन प्रति सेकंड, क्योंकि वे लंबे होते हैं और निश्चित लागत को बेहतर तरीके से बाँटते हैं। अगर कोई सत्र सुस्त लगे और आपको रीज़निंग की ज़रूरत न हो, तो असली लीवर एफ़र्ट लेवल है, मॉडल नहीं।

कैश रीड बिल बदलते हैं, दर नहीं

Claude Code में लगभग हर टर्न प्रॉम्प्ट कैश से मिलता है: Opus 5 के 16,680 टर्न में से सिर्फ़ 130 में cache_read_input_tokens शून्य था, और वे सत्र के पहले टर्न हैं। 100 से 500 आउटपुट टोकन वाले टर्न पर, कैश वाले टर्न मीडियन में 60.6 टोकन प्रति सेकंड स्ट्रीम करते हैं और 3.4 सेकंड लेते हैं; बिना कैश वाले 58.0 पर स्ट्रीम करते हैं और 3.7 सेकंड लेते हैं। अंतर असली है पर छोटा, और वह निश्चित लागत में है, स्ट्रीमिंग स्पीड में नहीं। कैश का संबंध उस कॉन्टेक्स्ट की कीमत से है जो आप साथ लेकर चलते हैं, इसीलिए AgentsRoom टर्मिनल का टोकन काउंटर कैश रीड और कैश राइट को अलग-अलग आंकड़ों के रूप में दिखाता है।

पूरे महीने स्थिर

एक संचयी संख्या किसी बदलाव को छिपा सकती है, इसलिए हमने सबसे आम तरह के टर्न, यानी 100 से 500 टोकन वाले टर्न पर Opus 5 का साप्ताहिक मीडियन भी देखा: हफ़्ते दर हफ़्ते 63.6, 64.1, 60.9, 61.7, 56.9 टोकन प्रति सेकंड, फिर अधूरे आख़िरी हफ़्ते में 68.7। 57 और 69 के बीच, कोई रुझान नहीं। अगर किसी दोपहर आपके सत्र धीमे लगें, तो मॉडल को दोष देने से पहले सिर्फ़ उसी दिन पर स्क्रिप्ट चलाकर देखना फ़ायदेमंद है।

फ़ास्ट मोड क्या बदलता है, और हम क्या नहीं माप पाए

हर usage ब्लॉक में एक speed फ़ील्ड होता है, और हमारे सभी 20,408 में standard लिखा है। Anthropic, Claude Opus के लिए एक फ़ास्ट मोड का दस्तावेज़ देता है, जिसे CLI में /fast से या उपयोगकर्ता सेटिंग्स में "fastMode": true से चालू किया जाता है, और जो मॉडल को प्रति टोकन ऊँची कीमत पर 2.5 गुना तक तेज़ बनाता है: Opus 5.5 पर प्रति मिलियन इनपुट टोकन 8 डॉलर और प्रति मिलियन आउटपुट टोकन 40 डॉलर, Opus 5 और Opus 4.8 पर 10 और 50। Pro और Max प्लान पर इसका बिल उपयोग क्रेडिट पर जाता है, सदस्यता विंडो के बाहर; Sonnet और Haiku इसे सपोर्ट नहीं करते, और इसे चालू करने पर आप Opus पर चले जाते हैं। प्रॉम्प्ट के पास बिजली का आइकन बताता है कि यह चालू है।

हमने इसके लिए भुगतान नहीं किया, इसलिए दस्तावेज़ में बताए गए 2.5 गुना के बगल में रखने के लिए हमारे पास कोई मापा हुआ आंकड़ा नहीं है। अगर आप इसे चलाते हैं, तो वही स्क्रिप्ट आपको बताएगी कि आपको क्या मिला: टर्न को usage["speed"] == "fast" पर फ़िल्टर करें और मीडियन की तुलना करें। हमें आंकड़े भेजिए।

इससे हमारे एजेंट चलाने के तरीके में क्या बदलता है

तीन चीज़ें, और उनमें से कोई भी तेज़ मॉडल चुनने के बारे में नहीं है।

पहली अपेक्षाओं के बारे में है। अगर सात एजेंटों का एक रात का रन दो मिलियन आउटपुट टोकन बनाता है, तो यह 70 टोकन प्रति सेकंड पर आठ घंटे का जनरेशन है, जो समानांतर चल रहे एजेंटों में बँटा है। दर जानने से ही आप कह पाते हैं कि कोई शेड्यूल किया गया काम अगले काम के शुरू होने से पहले पूरा हो सकता है या नहीं।

दूसरी टर्न के बारे में है। हर टर्न का निश्चित एक सेकंड 30 टोकन की पुष्टि पर भी उतना ही है जितना 3,000 टोकन के diff पर। जो एजेंट हर छोटे कदम से पहले पूछते हैं, या फ़ाइलें एक-एक करके पढ़ते हैं, उनका समय उसी सेकंड में जाता है। इसीलिए बिना निगरानी चलने वाले एजेंटों के प्रॉम्प्ट में हम लिखते हैं "अपनी स्वतंत्र रीड को एक बैच में करो"।

तीसरी इस बारे में है कि काउंटर को क्या दिखाना चाहिए। AgentsRoom का सत्र मॉनिटर टोकन और कैश दिखाता है, और सत्र भारी होने पर लाल हो जाता है; वह कोई दर नहीं दिखाता, और इस माप के बाद हमें पक्का नहीं कि उसे दिखाना चाहिए। दर मॉडल और टर्न के आकार की विशेषता है, सत्र की नहीं, और डेवलपर को जिस संख्या की ज़रूरत है वह ऊपर की तालिकाओं में है। इसीलिए यह एक लेख है, विजेट नहीं।

अक्सर पूछे जाने वाले प्रश्न

Claude Code प्रति सेकंड कितने टोकन बनाता है?

27 अगस्त से 25 सितंबर 2026 के बीच रिकॉर्ड किए गए हमारे 20,408 टर्न पर: Opus 5 का मीडियन 63 आउटपुट टोकन प्रति सेकंड है (सभी टोकन को सभी सेकंड से भाग देने पर 69), Opus 5.5 का 95 (109), Sonnet 5 का 77 (87), Fable 5.1 का 75 (80) और Opus 4.8 का 61 (64)। ये आंकड़े पूरे टर्न को गिनते हैं, उस पल से जब अनुरोध आपकी मशीन से निकलता है, आख़िरी स्ट्रीम हुए टोकन तक, इसलिए यही वह समय है जिसका आप असल में इंतज़ार करते हैं।

क्या /usage या /cost टोकन प्रति सेकंड दिखाते हैं?

नहीं। /usage आपके प्लान का कोटा, 5 घंटे और साप्ताहिक विंडो और इस्तेमाल हो रहे कॉन्टेक्स्ट विंडो का हिस्सा दिखाता है; /cost, /usage का ही उपनाम है। दोनों में से कोई भी दर नहीं दिखाता। स्पीड सिर्फ़ एक जगह मौजूद है: ~/.claude/projects/ के अंदर सत्र का ट्रांसक्रिप्ट, जहाँ असिस्टेंट के हर संदेश में एक टाइमस्टैम्प और उसके आउटपुट टोकन की संख्या होती है। इस लेख की स्क्रिप्ट यही पढ़ती है।

छोटा जवाब लंबे जवाब से धीमा क्यों लगता है?

क्योंकि हर टर्न पहले टोकन के आने से पहले एक निश्चित लागत चुकाता है: अनुरोध भेजना, प्रॉम्प्ट प्रोसेस करना, स्ट्रीम शुरू करना। हमारे डेटा में यह अतिरिक्त समय Opus 5 और Opus 5.5 पर लगभग एक सेकंड और Sonnet 5 पर आधा सेकंड है। 80 टोकन के जवाब में एक सेकंड पूरे टर्न का एक तिहाई है, इसलिए मापी गई दर गिरकर 40 टोकन प्रति सेकंड हो जाती है; 3,000 टोकन के जवाब में वही सेकंड गायब हो जाता है और दर 80 या उससे ऊपर चली जाती है। स्ट्रीमिंग स्पीड खुद स्थिर रहती है।

क्या थिंकिंग टोकन स्पीड में गिने जाते हैं?

हाँ। हर संदेश का usage ब्लॉक output_tokens बताता है, साथ में output_tokens_details.thinking_tokens का ब्योरा, और थिंकिंग टोकन output_tokens का हिस्सा हैं। हमारे डेटा में ये Opus 5 के कुल आउटपुट का 30%, Opus 5.5 का 18% और Sonnet 5 का 54% हैं, जो ज़्यादातर ऊँचे एफ़र्ट लेवल पर चला। जो टर्न देर तक सोचता है वह धीमा नहीं है, वह ऐसे टोकन बना रहा है जो आपको दिखते नहीं।

क्या प्रॉम्प्ट कैश Claude Code को तेज़ बनाता है?

आउटपुट दर को नहीं। 100 से 500 टोकन वाले टर्न पर, जब अनुरोध प्रॉम्प्ट कैश से मिल जाता है तो Opus 5 मीडियन में 60.6 टोकन प्रति सेकंड स्ट्रीम करता है और न मिलने पर 58.0, और पूरा टर्न 3.7 के मुकाबले 3.4 सेकंड लेता है। कैश का संबंध इस बात से है कि आप कॉन्टेक्स्ट के लिए कितना चुकाते हैं, इससे नहीं कि जवाब कितनी तेज़ी से आता है।

Claude Code का फ़ास्ट मोड क्या है, और यह कितना तेज़ है?

Claude Opus का एक कॉन्फ़िगरेशन जिसे Anthropic 2.5 गुना तक तेज़ बताता है, प्रति टोकन ऊँची कीमत पर: Opus 5.5 पर प्रति मिलियन इनपुट टोकन 8 डॉलर और प्रति मिलियन आउटपुट टोकन 40 डॉलर, Opus 5 और Opus 4.8 पर 10 और 50, और इसका बिल सदस्यता विंडो पर नहीं बल्कि उपयोग क्रेडिट पर जाता है। आप इसे /fast से चालू करते हैं, और प्रॉम्प्ट के पास बिजली का एक छोटा आइकन दिखता है। हमने जो 20,408 टर्न मापे उनमें से कोई भी फ़ास्ट मोड में नहीं चला (हर ट्रांसक्रिप्ट में speed: standard लिखा है), इसलिए इसका हमारे पास कोई मापा हुआ आंकड़ा नहीं है; इस लेख के आंकड़े स्टैंडर्ड स्पीड के हैं।