• Claude 4.7, पिछले वर्ज़न की तुलना में औसतन 1.3~1.45 गुना अधिक टोकन जनरेट करता है, जिससे समान प्राइसिंग संरचना में प्रति सेशन 20~30% लागत वृद्धि होती है
  • अंग्रेज़ी और कोड कंटेंट में टोकन वृद्धि अधिक स्पष्ट है, जबकि CJK (चीनी·जापानी·कोरियाई) कंटेंट में लगभग कोई बदलाव नहीं है
  • अधिक सूक्ष्म टोकनाइज़ेशन के कारण Instruction Following लगभग 5%p बेहतर हुई, खासकर फ़ॉर्मैट त्रुटियाँ कम हुईं
  • कैश प्रीफ़िक्स और बातचीत इतिहास के टोकन बढ़ने से कैश लागत और rate limit खपत की गति दोनों बढ़ती हैं
  • नतीजतन Claude 4.7 को बेहतर सटीकता और अधिक सूक्ष्म निर्देश पालन के बदले अतिरिक्त टोकन लागत उठानी पड़ने वाली संरचना के रूप में आंका गया है

Claude 4.7 टोकनाइज़र माप के परिणाम

  • Anthropic के Claude Opus 4.7 के बारे में कहा गया है कि वह पिछले वर्ज़न 4.6 की तुलना में 1.0~1.35 गुना अधिक टोकन उपयोग करता है, लेकिन वास्तविक माप में यह 1.45~1.47 गुना स्तर पर पाया गया
  • समान कीमत और quota शर्तों में टोकन संख्या बढ़ने से max window खपत की गति में वृद्धि, कैश प्रीफ़िक्स लागत में बढ़ोतरी, और rate limit जल्दी पहुँचने जैसे प्रभाव दिखे
  • प्रयोग को दो हिस्सों में बाँटा गया: लागत माप और निर्देश पालन माप

लागत माप की विधि

  • Anthropic API के POST /v1/messages/count_tokens endpoint का उपयोग करके वही कंटेंट 4.6 और 4.7 मॉडल में अलग-अलग इनपुट किया गया, ताकि सिर्फ़ टोकनाइज़र के अंतर की तुलना हो सके
  • दो प्रकार के sample set इस्तेमाल किए गए
    • वास्तविक Claude Code उपयोगकर्ताओं द्वारा भेजे गए 7 उपयोग-आधारित sample
    • अंग्रेज़ी, कोड, structured data, CJK, emoji, math symbol आदि के 12 कृत्रिम sample
  • वास्तविक Claude Code कंटेंट के परिणाम

    • 7 उपयोग-आधारित sample का weighted average ratio 1.325 गुना (8,254 → 10,937 टोकन)
    • मुख्य उदाहरण
    • CLAUDE.md फ़ाइल: 1.445 गुना
    • user prompt: 1.373 गुना
    • blog post: 1.368 गुना
    • code diff: 1.212 गुना
  • कंटेंट प्रकार के अनुसार परिणाम (12 कृत्रिम sample)

    • अंग्रेज़ी और कोड कंटेंट का औसत: 1.345 गुना
    • CJK (चीनी·जापानी·कोरियाई) कंटेंट का औसत: 1.01 गुना
    • विस्तृत उदाहरण
    • तकनीकी दस्तावेज़: 1.47 गुना
    • Shell script: 1.39 गुना
    • TypeScript कोड: 1.36 गुना
    • अंग्रेज़ी गद्य: 1.20 गुना
    • JSON: 1.13 गुना
    • जापानी·चीनी गद्य: 1.01 गुना

टोकनाइज़र के बदलाव के पैटर्न

  • CJK, emoji, symbol कंटेंट 1.005~1.07 गुना के स्तर पर रहे, यानी लगभग कोई बदलाव नहीं
    • ऐसा लगता है कि non-Latin शब्दावली में बड़ा बदलाव नहीं किया गया
  • अंग्रेज़ी और कोड कंटेंट 1.20~1.47 गुना बढ़े, और कोड पर गद्य से अधिक असर पड़ा
    • कोड में दोहराए जाने वाले string (keyword, import, identifier आदि) अधिक सूक्ष्म रूप से विभाजित होकर ज़्यादा टोकन में टूट गए
  • अंग्रेज़ी में प्रति token अक्षर अनुपात 4.33→3.60 और TypeScript में 3.66→2.69 तक घटा
    • यानी वही टेक्स्ट अब छोटे units में विभाजित होकर दर्शाया जा रहा है

अधिक टोकन उपयोग करने के कारण

  • Anthropic ने 4.7 में “निर्देशों का अधिक शाब्दिक रूप से पालन करने की प्रवृत्ति” पर ज़ोर दिया
  • छोटे token units शब्द-स्तरीय attention को मज़बूत करते हैं, जिससे सटीक निर्देश निष्पादन, character-level काम, और tool call precision बेहतर होती है
  • Notion, Warp, Factory जैसे पार्टनरों ने tool execution error में कमी की रिपोर्ट दी
  • हालाँकि, टोकनाइज़ेशन के अलावा model weights और post-training भी साथ में बदले गए, इसलिए कारण को अलग-अलग करके तय करना संभव नहीं है

निर्देश पालन परीक्षण

  • IFEval benchmark (2023, Google) का उपयोग: “ठीक N शब्दों में उत्तर दो”, “comma के बिना लिखो” जैसे 541 prompt में से 20 sample test किए गए
  • परिणाम
    • strict mode prompt स्तर: 4.6 → 85%, 4.7 → 90% (+5pp)
    • strict mode instruction स्तर: 86% → 90% (+4pp)
    • loose mode में कोई अंतर नहीं
  • सुधार मुख्य रूप से formatting-संबंधित त्रुटियों में कमी से आया
  • स्पष्ट अंतर सिर्फ़ एक single prompt (change_case:english_capital) में दिखा
  • sample size छोटा होने के कारण (+5pp सांख्यिकीय रूप से अनिश्चित), इसे छोटा लेकिन लगातार सुधार माना गया

Claude Code सेशन-स्तरीय लागत गणना

  • 80 round-trip बातचीत वाले सेशन को मानकर
    • static prefix: 6K टोकन (CLAUDE.md 2K + tool definition 4K)
    • conversation history: हर turn पर 2K की वृद्धि, 80 turn पर 160K तक पहुँचती है
    • input/output: प्रति turn 500 / 1,500 टोकन
    • cache hit rate: 95%
  • 4.6 के आधार पर सेशन लागत

    • | मद | गणना | लागत |
    • | --- | --- | --- |
    • | पहला cache write | 8K × $6.25/MTok | $0.05 |
    • | cache read (79 बार) | 79 × 86K × $0.50/MTok | $3.40 |
    • | नया input | 79 × 500 × $5/MTok | $0.20 |
    • | output | 80 × 1,500 × $25/MTok | $3.00 |
    • | कुल | | लगभग $6.65 |
  • 4.7 के आधार पर सेशन लागत

    • CLAUDE.md: 1.445 गुना → 2K → 2.9K
    • tool definition: 1.12 गुना → 4K → 4.5K
    • conversation history: 1.325 गुना → 160K → 212K
    • user input: 1.325 गुना → 500 → 660
    • औसत cache prefix: लगभग 115K टोकन
    • | मद | गणना | लागत |
    • | --- | --- | --- |
    • | पहला cache write | 10K × $6.25/MTok | $0.06 |
    • | cache read (79 बार) | 79 × 115K × $0.50/MTok | $4.54 |
    • | नया input | 79 × 660 × $5/MTok | $0.26 |
    • | output | 80 × 1,500–1,950 × $25/MTok | $3.00–$3.90 |
    • | कुल | | लगभग $7.86–$8.76 |
    • प्रति सेशन 20~30% लागत वृद्धि, टोकन unit price बदले बिना
    • Max प्लान उपयोगकर्ताओं के लिए समान समय विंडो में सेशन समाप्ति का समय और जल्दी आता है

prompt cache पर प्रभाव

  1. model-वार cache अलगाव के कारण 4.7 पर स्विच करने पर पुराना 4.6 cache अमान्य हो जाता है
    • पहला सेशन cache लागू हुए बिना शुरू होता है, जिससे बड़ा prefix cost आता है
  2. cache volume खुद 1.3~1.45 गुना बढ़ता है, इसलिए read और write दोनों समान अनुपात से बढ़ते हैं
  3. एक ही बातचीत लॉग में भी token count बदल जाता है, जिससे पिछले बिलिंग और monitoring metrics के साथ discontinuity पैदा होती है

आपत्तियाँ और व्याख्या

  • “ज़्यादातर input तो cache read है, इसलिए असर मामूली है”

    • cache hit rate ऊँचा होने पर लागत प्रभाव छोटा हो सकता है, लेकिन TTL expiry, cache invalidation, और model switch होने पर कुल अनुपात के अनुसार लागत बढ़ती है
  • “1.35 गुना ऊपरी सीमा नहीं बल्कि एक range है”

    • वास्तविक माप upper bound के पास (1.325 गुना) केंद्रित थे, और कुछ फ़ाइलें इसे पार भी कर गईं
    • वास्तविक उपयोग में upper bound के आधार पर योजना बनाना अधिक सुरक्षित है

निष्कर्ष

  • अंग्रेज़ी और कोड-केंद्रित कार्यों में token usage 1.3~1.45 गुना बढ़ा
  • निर्देश पालन लगभग +5pp बेहतर हुआ, यानी सुधार छोटा है लेकिन व्यावहारिक है
  • प्रति सेशन लागत 20~30% बढ़ी, जबकि token unit price समान रहा
  • नतीजतन इसे बेहतर सटीकता और अधिक सूक्ष्म निर्देश निष्पादन के लिए अतिरिक्त लागत चुकाने वाली संरचना के रूप में देखा गया

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.