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

 (claudecodecamp.com)
3 पॉइंट द्वारा GN⁺ 2026-04-18 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 समान रहा
  • नतीजतन इसे बेहतर सटीकता और अधिक सूक्ष्म निर्देश निष्पादन के लिए अतिरिक्त लागत चुकाने वाली संरचना के रूप में देखा गया

संबंधित पढ़ाई

2 टिप्पणियां

 
kaydash 2026-04-18

Claude 4.7 नहीं, बल्कि opus 4.7 है
 
GN⁺ 2026-04-18
Hacker News की राय

  • यह मानकर कि LLM की performance/cost curve लॉगरिदमिक रूप में मौजूद है, यह स्पष्ट नहीं है कि Opus 4.5+ इस curve पर एक नया बिंदु है, या बस वह हिस्सा है जहाँ थोड़ी ज़्यादा performance के लिए लागत तेज़ी से बढ़ती है
    Anthropic का तेज़ी से कीमत बढ़ाना संभवतः operating cost में उछाल का संकेत हो सकता है
    मुझे लगता है कि model evaluation graph में x-axis को cost log में दिखाने की प्रथा इस वास्तविकता को छिपाती है

    • Toby Ord की AI agent की hourly cost analysis देखी थी। उनका performance/cost frontier वाला विचार ज़्यादा ध्यान पाने लायक है
    • अब समय आ गया है कि developers अपने काम के हिसाब से model size और effort level को उचित रूप से चुनें(right-sizing)
      हर बार सबसे अच्छा model इस्तेमाल करने का दौर खत्म हो चुका है। काम के अनुसार कई अलग-अलग बिंदुओं में से चुनने का विकल्प चाहिए
      जटिल कामों के लिए बड़ा model लेकर एक बार में 5 घंटे के token खर्च कर देना भी ठीक हो सकता है
      लेकिन बहुत से लोग इस तरह की पसंद की जटिलता पसंद नहीं करेंगे, और आगे smart routing के प्रयास बढ़ेंगे ऐसा लगता है
    • Anthropic IPO की तैयारी में है, इसलिए प्रति-उपयोगकर्ता राजस्व बढ़ाने का दबाव बड़ा है। आखिरकार pricing अब वास्तविक model operating cost को दर्शाने वाली दिशा में जा रही है
    • जब models सीधे silicon में implement होंगे, तो लागत घटेगी और गति बढ़ेगी। Taalas जैसी कोशिशें देखने लायक हैं
    • अगर ग्राहक ज़्यादा लागत देने को तैयार हों, तो उससे कहीं ज़्यादा शक्तिशाली model भी दिए जा सकते हैं
      जैसे Apple की तरह ultra-premium विकल्प चाहने वाले ग्राहक होते हैं, वैसे ही ultra-high-performance LLM market भी संभव है

  • बहुत लोग AI models की cost पर ध्यान देते हैं, लेकिन असल में इंसानों का AI coding agent को निर्देशित करने और review करने में लगने वाला समय कहीं ज़्यादा महँगा है
    $200/माह शौक के लिए महँगा है, लेकिन business के नज़रिये से यह बहुत छोटा खर्च है
    अहम बात यह है कि model काम कितना अच्छा करता है, और मौजूदा price range में समय के मुकाबले efficiency सबसे महत्वपूर्ण है

    • हमारी टीम ने इस साल Claude के साथ तीन products लॉन्च किए। खास तौर पर 9 लोगों के 6 महीने वाले project को 2 लोगों ने 2 महीने में खत्म कर दिया
      Claude subscription की आर्थिक value मुझे 10,000 से 40,000 euro के बीच लगती है।
      कीमत 100 गुना बढ़ जाए तब भी खरीदूँगा। हाँ, अगर 20,000 euro/माह हो जाए तो alternatives देखूँगा, लेकिन अभी productivity gain बहुत भारी है
    • $200 किसी कंपनी के लिए लगभग बिना बोझ का खर्च है, लेकिन व्यक्तिगत hobby के लिए इसे justify करना मुश्किल है
    • मेरे Openclaw instance पर Opus इस्तेमाल करने से एक दिन में $200 charge हुआ। routing optimization बड़ा मुद्दा है। $1/घंटा पर ठीक था, लेकिन $15/घंटा पर competitiveness घटती है

  • मुझे लगता है model quality में सुधार अंततः diminishing returns के क्षेत्र में पहुँचेगा
    8K बनाम 16K display की तरह, ज़्यादातर users फर्क महसूस नहीं करेंगे
    अगर लागत 20~30% बढ़ती है, तो उतनी ही दिखने वाली value increase भी होनी चाहिए

    • इसी वजह से ज़्यादातर research coding क्षेत्र पर केंद्रित दिखती है। कठिनाई लगातार बढ़ती रहती है और आर्थिक value भी बनी रहती है
      इसके विपरीत सामान्य conversational query पहले से ही saturated है, इसलिए models के बीच फर्क करना मुश्किल है
    • भले 99% सही लगे, लेकिन दिन में 100,000 फैसले लेने हों तो छोटी error भी जमा होकर बड़ा मुद्दा बन जाती है
    • अगर local में चलने वाला 4K model आ गया, तो बड़े research labs मुश्किल में पड़ जाएँगे। फिर भी Google विज्ञापन revenue की वजह से टिक जाएगा शायद
    • यह काम के प्रकार पर निर्भर करता है। उदाहरण के लिए drug design में 95% completion और 100% completion का अंतर दर्जनों गुना value बना सकता है
    • web search या summary के लिए तो शायद हम सीमा के करीब पहुँच चुके हैं, लेकिन coding complexity अनंत तक फैल सकती है

  • GitHub Copilot का model multiplier 3 से बढ़कर 7.5 हो गया है
    यह Microsoft की तरफ से losses कम करने की कोशिश लगती है
    official docs देखें

    • इसलिए हमने अपनी organization में सलाह दी है कि “Opus 4.7 बिल्कुल enable मत करो।” 4.6(3x) और 4.5(3x) ठीक हैं, लेकिन 4.7(7.5x) में value for money बिल्कुल नहीं है
    • हाल में Opus 4.6 में reasoning quality गिरती दिख रही है। यह निष्कर्ष पर जल्दी पहुँचता है और logic छोड़ देता है। कोई बड़ी breakthrough न आई तो तेज़ quality degradation(en**)** आ सकती है

  • लेख का शीर्षक भ्रम पैदा करता है। token count बढ़ा है, लेकिन प्रति-task cost अलग हो सकती है
    मान लेते हैं कि Opus 4.7, Opus 4.6 जैसा वही reasoning path इस्तेमाल नहीं करता
    Artificial Analysis का Intelligence Index आने का इंतज़ार करना होगा

    • internal benchmark में Opus 4.7 50% सस्ता था और performance score 80% (vs 60%) था
    • लेख का शीर्षक “Claude Opus 4.7 costs 20–30% more per session” से बदलकर अधिक neutral कर दिया गया
    • 28-task comparison experiment के अनुसार 4.7 की लागत पुराने 4.6 के करीब है और नए 4.6 से लगभग 20% महँगी है
    • मेरे निजी data के हिसाब से 4.7, 4.6 से ज़्यादा महँगा था, और performance improvement भी साफ़ नहीं थी
    • official announcement graph में भी “strictly better” दावे का आधार देखा जा सकता है

  • कल Opus इस्तेमाल करते समय यह चौंकाने वाला अच्छा था, लेकिन आज साधारण कामों में भी बार-बार गलती कर रहा है
    मुझे तीसरी बार वही समस्या बतानी पड़ी, session बार-बार टूट रही थी और compaction बहुत ज़्यादा हो रहा था
    आखिरकार मैंने Sonnet पर वापस जाने का फैसला किया

    • यह bug नहीं, बल्कि computation कम करने की policy है। आगे यह और खराब होगी
    • LLM कोई व्यक्तित्व नहीं है। probability distribution से sampling करते समय खराब session आने की संभावना आखिरकार 100% है। context reset करके फिर कोशिश करनी चाहिए
    • मैं भी हाल में Opus 4.7 इस्तेमाल करते हुए अक्सर बेकार results देख रहा हूँ। model का खुद अपनी गलती मानकर फिर कोशिश करना थोड़ा कड़वा लगा

  • आजकल दिमाग में बार-बार यही आता है: “क्या सच में और शक्तिशाली model की ज़रूरत है?”
    industry performance race में उलझी हुई है और efficiency व sustainability को नज़रअंदाज़ कर रही है
    आगे 0.5B~1B parameter models को खास कामों के लिए optimize करना ज़्यादा महत्वपूर्ण दिशा लगती है

    • अगर मैं Sonnet 4.6 को local में चला पाता, तो मैं पूरी तरह संतुष्ट होता
      CPUs Aren’t Dead लेख की तरह, Google का Gemma 4 E2B model फोन पर भी चलता है और GPT-3.5-turbo को पार करता है
      Artificial Analysis के Intelligence Index के मुताबिक नया 2B model, 3~4 साल पहले के 175B model जैसी performance देता है
      Gemma 4 E4B कुछ मामलों में GPT-4o को भी पार कर जाता है
      अगर यह trend जारी रहा तो जल्द ही laptop पर भी top-tier models चल सकेंगे
    • बहुत लोगों ने उम्मीद की थी कि Sonnet 4.6, Opus 4.5-स्तर की performance देगा, लेकिन हकीकत वैसी नहीं थी
    • efficiency से पैसा नहीं बनता। बड़े LLM business के लिए inference cost को महँगा बनाए रखना फायदे का सौदा है
      “नया model पागलपन की हद तक अच्छा है” जैसी marketing आखिरकार FOMO marketing ही है
    • हर किसी को advanced calculator की ज़रूरत नहीं होती। ज़रूरत के स्तर का tool चुनना महत्वपूर्ण है
    • लेकिन “आलसी और inaccurate model” से संतुष्ट नहीं हुआ जा सकता। जो lab इस समस्या को हल करेगी, उसे निर्णायक बढ़त मिलेगी

  • भारत के कोलकाता में नमकीन/मिठाई बेचने वाले दुकानदारों ने कच्चे माल की कीमत बढ़ने पर भी दाम नहीं बढ़ाए, तो उन्होंने आकार छोटा कर दिया
    लोगों की मनोवैज्ञानिक अनुकूलन प्रक्रिया कुछ ऐसे ही काम करती है

    • दुनिया भर में यही हो रहा है। पैकेट वही है लेकिन अंदर की मात्रा कम हो गई है। Pringles का डिब्बा भी पतला और छोटा हो गया है
    • इस तरह की घटना को Shrinkflation कहा जाता है

  • Anthropic ने 4.7 में नया xhigh mode जोड़ा है
    max mode token usage बहुत बढ़ा सकता है और over-reasoning पैदा कर सकता है, इसलिए ज़्यादातर मामलों में xhigh की सिफारिश की जाती है
    official docs देखें

    • xhigh स्तर जोड़कर max को और दूर धकेल देना वैसा लगता है जैसे “this one goes to 11”

  • असली code के आधार पर Opus 4.7 में लगभग 30% token increase दिखा
    असली सवाल यह है कि “4.7, 4.6 की तुलना में कौन-सी नई capability देता है?”
    अभी फैसला करना जल्दी होगा, और अगर value हो तो लागत बढ़ना स्वीकार किया जा सकता है

    • चर्चा में दिलचस्प बात यह थी कि बहुत से लोग नए model के पीछे भागते हैं, लेकिन Sonnet 4.6 ही काफ़ी efficient साबित हो सकता है
      काम का दायरा छोटा रखने से review और management आसान हो जाते हैं, और छोटे diff के साथ जल्दी fix किया जा सकता है
      अगर Copilot का token consumption 7 गुना बढ़ जाए, तो उल्टा workflow टूटने लगेगा
    • हाल में 4.6 के performance degrade होने की शिकायतें बहुत हैं
    • पता नहीं 4.6 कितने समय तक बना रहेगा। enterprise में शायद थोड़ा ज़्यादा चले, लेकिन individual subscribers के लिए जल्द ही विकल्प गायब हो सकता है