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

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

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

Opus 5.5 टोकन प्रति सेकंड: 19 अक्टूबर 2026 का अपडेट

हमने माप को पिछले चार पूरे हफ़्तों पर फिर से चलाया: 21 सितंबर से 18 अक्टूबर 2026 तक (UTC)। हमने डिफ़ॉल्ट ट्रांसक्रिप्ट डायरेक्टरी और AgentsRoom द्वारा इस्तेमाल की जाने वाली अतिरिक्त Claude प्रोफ़ाइलें शामिल कीं, फिर हर अनुरोध को सभी फ़ाइलों में सिर्फ़ एक बार गिना।

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

यह अपडेट टाइमिंग को भी ठीक करता है। सीधा पैरेंट कोई तकनीकी अटैचमेंट हो सकता है, जैसे deferred_tools_record, जो तब लिखा जाता है जब जवाब पहले से आ रहा होता है। एक अनुरोध में, पुराने तरीके ने 562 टोकन को 0.046 सेकंड से भाग दिया, जिससे 12,000 tok/s से ज़्यादा की दर निकली। पैरेंट की शृंखला को पीछे की ओर उस उपयोगकर्ता संदेश या टूल के नतीजे तक ले जाने से, जिसने अनुरोध शुरू किया था, लगभग सात सेकंड का बीता समय वापस मिल जाता है। इस सुधार और दोहराए गए अनुरोधों को हटाने के बाद, इस अवधि का कोई भी Opus 5.5 अनुरोध 400 tok/s से ऊपर नहीं जाता; हमने ऊँची दरों को फ़िल्टर नहीं किया।

नीचे की सितंबर की तालिकाएँ मूल माप ही हैं। उनका 94.9 tok/s का मीडियन और 109.3 tok/s की वेटेड दर पुरानी टाइमिंग और एक अलग सैंपल पर आधारित हैं, इसलिए यह अंतर इस बात का सबूत नहीं है कि Opus 5.5 धीमा हो गया। ये आंकड़े हमारे वर्कलोड, हमारे नेटवर्क और ट्रांसक्रिप्ट के टाइमस्टैम्प को दर्शाते हैं, मॉडल के किसी अलग-थलग बेंचमार्क को नहीं।

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

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 पिछले इवेंट की ओर इशारा करता है, जो जवाब के दौरान लिखा गया कोई तकनीकी अटैचमेंट हो सकता है। attachment, system और progress इवेंट को पार करते हुए शृंखला को उस उपयोगकर्ता संदेश या टूल के नतीजे तक ले जाएँ जिसने टर्न शुरू किया; उसका टाइमस्टैम्प टर्न की शुरुआत का एक अनुमानित संकेत है।
• requestId एक API कॉल के ब्लॉकों को एक साथ रखता है। जो टर्न कुछ टेक्स्ट लिखता है और फिर एक टूल कॉल करता है, वह एक ही requestId और एक ही usage वाली दो असिस्टेंट पंक्तियाँ बनाता है, इसलिए टोकन हर अनुरोध पर एक बार गिने जाने चाहिए, हर पंक्ति पर नहीं।
• usage.output_tokens अनुरोध का कुल आउटपुट है, थिंकिंग समेत; output_tokens_details.thinking_tokens बताता है कि उसमें से कितना थिंकिंग था।

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

तरीका

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

हम वे टर्न हटाते हैं जिनमें कोई आउटपुट टोकन नहीं है, जिन्हें शुरू करने वाला संदेश नहीं मिलता, जिनकी अवधि शून्य या ऋणात्मक है, या जिनकी अवधि पंद्रह मिनट से ज़्यादा है। नीचे की स्क्रिप्ट तारीख वाले अपडेट की अवधि इस्तेमाल करती है, UTC में, जिसमें शुरुआत की तारीख शामिल है और अंत की तारीख शामिल नहीं। कोई दूसरी अवधि मापने के लिए START और END बदलें।

अपडेट की गई स्क्रिप्ट को Python 3.10 या उससे नया संस्करण चाहिए, और कोई अतिरिक्त डिपेंडेंसी नहीं। इसे कहीं से भी चलाएँ; यह डिफ़ॉल्ट प्रोजेक्ट और अतिरिक्त स्थानीय Claude प्रोफ़ाइलें पढ़ती है, उनकी सामग्री कहीं अपलोड किए बिना।

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

START, END = "2026-09-21", "2026-10-19"  # UTC, end exclusive
PATTERNS = ("~/.claude/projects/*/*.jsonl",
            "~/.agentsroom/claude-profiles/*/projects/*/*.jsonl")

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

def read_session(path):
    by_uuid, groups = {}, defaultdict(list)
    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"):
                groups[o.get("requestId") or o["uuid"]].append(o)
    return by_uuid, groups

def trigger(first, by_uuid):
    parent, visited = by_uuid.get(first.get("parentUuid")), set()
    while parent and parent.get("type") in ("attachment", "system", "progress"):
        uid = parent.get("uuid")
        if uid in visited: return None
        visited.add(uid)
        parent = by_uuid.get(parent.get("parentUuid"))
    return parent if parent and parent.get("type") == "user" else None

by_model, seen = defaultdict(list), set()
for pattern in PATTERNS:
    for path in glob.glob(os.path.expanduser(pattern)):
        by_uuid, groups = read_session(path)
        for rid, blocks in groups.items():
            first, last = blocks[0], blocks[-1]
            if rid in seen or not START <= first["timestamp"] < END: continue
            usage = first["message"]["usage"]
            out, parent = usage.get("output_tokens", 0), trigger(first, by_uuid)
            if not parent or not parent.get("timestamp") or out <= 0: continue
            dur = ts(last["timestamp"]) - ts(parent["timestamp"])
            if not 0 < dur <= 900: continue
            seen.add(rid)
            thinking = (usage.get("output_tokens_details") or {}).get("thinking_tokens", 0)
            key = first["message"].get("model"), usage.get("speed", "unknown")
            by_model[key].append((out, dur, thinking))

for (model, speed), rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    outputs, durations, thinking = zip(*rows)
    median = st.median(o / d for o, d, _ in rows)
    weighted = sum(outputs) / sum(durations)
    overhead = st.linear_regression(outputs, durations).intercept if len(set(outputs)) > 1 else float("nan")
    print(f"{model} {speed}: turns={len(rows)} median={median:.1f} "
          f"weighted={weighted:.1f} tok/s overhead={overhead:.2f}s "
          f"thinking={100 * sum(thinking) / sum(outputs):.1f}%")

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 Opus 5.5 प्रति सेकंड कितने टोकन बनाता है?

19 अक्टूबर 2026 को अपडेट किए गए हमारे माप में, Claude Opus 5.5 ने 21 सितंबर से 18 अक्टूबर तक के 30,119 यूनिक अनुरोधों पर 89.4 आउटपुट टोकन प्रति सेकंड का मीडियन दिया, सभी स्टैंडर्ड स्पीड पर। कुल आउटपुट टोकन को कुल बीते सेकंड से भाग देने पर 97.5 tok/s मिलता है। थिंकिंग आउटपुट टोकन का 42.1% है। ये हमारे अपने सत्रों के ट्रांसक्रिप्ट से लिए गए, पूरे टर्न के शुरू से अंत तक के माप हैं, स्ट्रीमिंग स्पीड का कोई सार्वभौमिक बेंचमार्क नहीं।

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 लिखा है), इसलिए इसका हमारे पास कोई मापा हुआ आंकड़ा नहीं है; इस लेख के आंकड़े स्टैंडर्ड स्पीड के हैं।