Opus 4.6 और Opus 4.7 के लिए टोकन लागत कैलकुलेटर

 (tokens.billchambers.me)
2 पॉइंट द्वारा GN⁺ 2026-04-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Opus 4.7 के नए tokenizer के कारण एक ही prompt को ज़्यादा tokens के रूप में गिना जाने की समस्या का विश्लेषण करने वाला कैलकुलेशन टूल
  • एक ही input, content type के अनुसार 1.0~1.35x tokens में map होता है, और शब्द बदले बिना भी प्रति request लागत बढ़ती है
  • वास्तविक गणना में Opus 4.7 में Opus 4.6 की तुलना में औसत request tokens और औसत request cost दोनों में +37.4% वृद्धि
  • वृद्धि की सीमा हाल की 50 entries के आधार पर न्यूनतम +19.0% से अधिकतम +86.2% तक, और +30% व +40% रेंज के मामले व्यापक रूप से वितरित
  • इस पेज पर conversation, system prompt, text पेस्ट करके Opus 4.7 vs 4.6 token count अंतर और मौजूदा कीमत के आधार पर लागत की ठोस तुलना देखी जा सकती है

यह टूल क्यों बनाया गया

  • Opus 4.7 रिलीज़ घोषणा में इसे Opus 4.6 का सीधा upgrade बताया गया था, लेकिन token usage को प्रभावित करने वाले दो बदलाव मौजूद हैं
    • अपडेट किए गए tokenizer की वजह से एक ही input, content type के अनुसार 1.0~1.35x tokens में map होता है
    • उच्च effort level पर, खासकर agentic environment के बाद के turns में, मॉडल ज़्यादा सोचता है, जिससे output tokens बढ़ते हैं
  • कठिन समस्याओं पर reliability बेहतर होती है, लेकिन इसका token-based cost structure पर सीधा असर पड़ता है

उपयोगकर्ताओं पर प्रभाव

  • एक ही prompt text होने पर भी Opus 4.7 में ज़्यादा tokens के रूप में count किया जाता है, इसलिए शब्द बदले बिना भी प्रति request लागत बढ़ती है
  • Tokenomics में कोई भी conversation, system prompt, text पेस्ट करके Opus 4.7 और 4.6 के token count अंतर को सीधे देखा जा सकता है
  • मौजूदा pricing के आधार पर ठोस लागत अंतर निकाला जाता है

कम्युनिटी औसत पेज

  • /leaderboard पेज पर टूल उपयोगकर्ताओं के anonymous comparison data को aggregate किया जाता है
  • अलग-अलग prompt types के अनुसार वास्तविक token वृद्धि दर का औसत real-world usage के आधार पर देखा जा सकता है

ध्यान देने योग्य बातें

  • prompt text स्टोर नहीं किया जाता: input को browser में parse करने के बाद server पर भेजा जाता है और फिर Anthropic token counting API को forward किया जाता है; prompt text को DB में स्टोर नहीं किया जाता, केवल anonymous token count metrics सेव किए जाते हैं
  • यह Anthropic का आधिकारिक product नहीं है: इसे Bill Chambers ने बनाया है और इसका Anthropic के साथ कोई affiliation, endorsement या sponsorship संबंध नहीं है
  • open source: पूरा source code GitHub(bllchmbrs/tokensmatter) पर उपलब्ध है, contributions और feedback का स्वागत है

कम्युनिटी औसत

  • anonymous रूप से submit किए गए वास्तविक usage request comparisons के आधार पर, Opus 4.6 की तुलना में Opus 4.7 के request tokens और request cost अंतर का aggregation
    • कुल 425 submissions के आधार पर संकलन
    • हाल की comparison list हाल की 50 entries को newest-first क्रम में दिखाती है
  • औसत request token परिवर्तन दर +37.4%
  • औसत request cost परिवर्तन दर +37.4%
  • औसत request size 369 / 495
    • मूल पाठ में इन दो संख्याओं की अतिरिक्त व्याख्या नहीं दी गई है

हाल के anonymous comparison examples

  • हाल की 50-entry तालिका में अधिकांश मामलों में Opus 4.7 request tokens वृद्धि और cost वृद्धि एक ही अनुपात में दर्ज हैं
    • उदाहरण 1: 6b5d3ebf submission, request 23 → 31, cost $0.000345 → $0.000465, परिवर्तन दर +34.8%
    • उदाहरण 2: 1363973a submission, request 99 → 130, cost $0.001485 → $0.001950, परिवर्तन दर +31.3%
    • उदाहरण 3: 17a9645e submission, request 16 → 20, cost $0.000240 → $0.000300, परिवर्तन दर +25.0%
  • छोटे requests में भी वृद्धि देखी गई
    • 10c3149a submission, request 8 → 14, cost $0.000120 → $0.000210, परिवर्तन दर +75.0%
    • 8f58e536 submission, request 8 → 13, cost $0.000120 → $0.000195, परिवर्तन दर +62.5%
    • 942f5d38 submission, request 12 → 19, cost $0.000180 → $0.000285, परिवर्तन दर +58.3%
  • मध्यम आकार के requests में भी इसी तरह की वृद्धि बार-बार दिखती है
    • 67f5f437 submission, request 188 → 275, cost $0.002820 → $0.004125, परिवर्तन दर +46.3%
    • 04249c86 submission, request 176 → 256, cost $0.002640 → $0.003840, परिवर्तन दर +45.5%
    • af25da70 submission, request 269 → 501, cost $0.004035 → $0.007515, परिवर्तन दर +86.2%
  • बड़े requests में भी ऐसा ही वृद्धि pattern दिखता है
    • c5d75d71 submission, request 2,263 → 3,282, cost $0.0339 → $0.0492, परिवर्तन दर +45.0%
    • 4db385b5 submission, request 1,592 → 2,205, cost $0.0239 → $0.0331, परिवर्तन दर +38.5%
    • 68375705 submission, request 4,449 → 6,434, cost $0.0667 → $0.0965, परिवर्तन दर +44.6%
  • कई submissions में समान संख्याएँ दोहराई गई हैं
    • request 175 → 221, cost $0.002625 → $0.003315, परिवर्तन दर +26.3% वाला मामला कई submission IDs में दोहराया गया
    • request 996 → 1,392, cost $0.0149 → $0.0209, परिवर्तन दर +39.8% वाला मामला कई submission IDs में दोहराया गया
    • request 43 → 61, cost $0.000645 → $0.000915, परिवर्तन दर +41.9% वाला मामला कई submission IDs में दोहराया गया

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

1 टिप्पणियां

 
GN⁺ 2026-04-19
Hacker News टिप्पणियाँ

  • मेरा मानना है कि निष्पक्ष तुलना के लिए कुल लागत देखनी चाहिए। 4.7 में 4.6 की तुलना में output tokens काफ़ी कम हैं, और reasoning cost भी अच्छी-ख़ासी घटी हुई लगती है। Artificial Analysis comparison देखें तो 4.7, 4.6 से थोड़ा सस्ता निकलता है, और 4.5 तो लगभग आधी लागत पर है। खासकर reasoning लागत 4.6 से 4.7 में आते-आते लगभग आधी हो जाना ध्यान खींचता है। लेकिन Claude Code जैसे वास्तविक workloads में input और reasoning दोनों का हिस्सा बड़ा लगता है, इसलिए input unit price बढ़ने और reasoning unit price घटने का असर एक-दूसरे को कितना offset करेगा, इसका अभी अंदाज़ा नहीं है। reasoning-heavy काम सस्ते पड़ सकते हैं, लेकिन कम reasoning वाले काम उल्टा महंगे भी हो सकते हैं। ऐसे कामों के लिए मैं शायद Codex ही इस्तेमाल करूँगा

    • मुझे लगता है 4.7 का कम सोचना और कम output देना forced adaptive thinking की वजह से है। API users भी इसे बंद नहीं कर सकते, और यही वही तरीका है जिसने सिर्फ़ 2 हफ़्ते पहले Opus 4.6 में quality issues पैदा किए थे। उस समय भी इसे disable करने की बात हुई थी, और मुझे याद है कि कुछ मामलों में thinking tokens को 0 तक assign किया गया था। अभी भी बहुत से लोग Opus 4.7 की quality गिरने की शिकायत कर रहे हैं, और मैं खुद भी अक्सर बहुत बुनियादी गलतियाँ देखता हूँ। 10 मिनट तक tokens जलाने के बाद भी यह असल में code ठीक से पढ़ता नहीं, बल्कि hand-waving करके बात टालता है, फिर बाद में खुद ही पलट जाता है। adaptive thinking enabled Opus पर भरोसा करना मुश्किल लगता है। ज़रूरत हो तो session feedback ID भी दे सकता हूँ
    • कुछ लोगों का मानना है कि एक ही model number होने पर भी समय के साथ behavior और token usage बदल सकते हैं, इसलिए same model का time-based testing ज़्यादा fair है। Version name वही रहे, तब भी अंदरूनी behavior बदल सकता है, इसलिए हाल का test result भविष्य की तुलना के लिए सही benchmark न भी हो सकता है

  • मेरे अनुभव में 4.6 से 4.7 पर performance improvement लगभग महसूस नहीं होता, लेकिन limit खर्च होने की रफ़्तार बहुत साफ़ महसूस होती है। कल मैंने 5 घंटे की limit सिर्फ़ 2 घंटे में ख़त्म कर दी, और refactoring के लिए batched mode चालू किया तो 5 मिनट में ही limit का 30% खर्च हो गया, इसलिए cancel करना पड़ा। बाद में serial mode पर बदला तो खपत थोड़ी कम हुई, लेकिन फिर भी यह 4.6 से कहीं तेज़ खर्च हो रहा था। अभी तो हर बातचीत में 5 घंटे की limit का लगभग 5% चला जाता है, जबकि पहले यह 1~2% के आसपास होता था। मैं Max 5x plan पर हूँ, इसलिए weekly limit में अभी काफ़ी जगह है, तो चल रहा है, लेकिन कम-से-कम इस हिस्से को ज़्यादा transparently समझाया जाए या सुधारा जाए, यह चाहूँगा। effort setting भी अभी बहुत opaque है, इसलिए व्यावहारिक मदद कम मिलती है

    • सबसे परेशान करने वाली बात adaptive thinking के forced application से quality गिरना है। यह मेरे Max 5x usage का 5~10% खा जाता है, 10 मिनट तक चलता रहता है, और वापस आने वाला नतीजा अक्सर भरोसे लायक नहीं होता। असली code पढ़कर reasoning करने की बजाय यह समस्या को ऊपर-ऊपर से टाल देता है, इसलिए adaptive thinking enabled Opus भरोसेमंद नहीं लगता
    • मेरी समझ के मुताबिक अगर prompts के बीच 5 मिनट से ज़्यादा का gap हो जाए, तो compact या clear किए बिना cache reinitialization cost फिर से देनी पड़ती है। compact करने पर भी लागत पूरी तरह ख़त्म नहीं होती, बस input tokens कुछ कम होते दिखते हैं। हालाँकि compaction खुद मुफ़्त है या नहीं, यह मैं भी जानना चाहता हूँ

  • अगर result अच्छे हों तो मैं ज़्यादा पैसे देने को तैयार हूँ, लेकिन अभी ऐसा लगता है जैसे Anthropic intermittent reward की तरह tokens खर्च करवाते रहने की दिशा में जा रहा है। Claude family, GPT या Codex की तुलना में साफ़ तौर पर ज़्यादा मज़ेदार है, उसमें personality भी है, design sense और aesthetics भी हैं। साथ में vibe-coding करने का एहसास गेम जैसा मज़ेदार होता है। लेकिन output लगभग हमेशा मिलती-जुलती समस्याओं पर जाकर अटकता है। Tests हटाकर pass करा देता है, duplicate code बढ़ाता है, abstractions ग़लत करता है, type safety बंद कर देता है, hard requirements को ignore करता है। ये समस्याएँ 4.7 में भी हल नहीं हुईं, और benchmark कुछ भी कहें, real usage में ये अभी भी बनी हुई लगती हैं। कंपनी इसे सच में ठीक करना चाहती है या नहीं, यह भी स्पष्ट नहीं है

    • मेरी भावना भी लगभग यही है। अभी के tools Google replacement, झंझट वाले scaffolding, code review, और advanced search जैसी चीज़ों में खास उपयोगी लगते हैं। Coding LLM market में जगह बन चुकी है, इसलिए अब वे असली monetization शुरू करते दिखते हैं, और मुझे लगता है आगे ऐसे models आते रहेंगे जिनमें performance improvement मामूली होगा लेकिन price 40% या उससे ज़्यादा बढ़ जाएगी
    • मेरा मानना है कि AI को बस खुला छोड़ने के बजाय guide करना पड़ता है। अगर आपके पास उसे सही दिशा देने की skill है, तो उससे काफ़ी high-quality result निकलवाए जा सकते हैं
    • ऊपर की आलोचना में यह मान लेना कि Anthropic ने जानबूझकर token consumption बढ़ाने की short-term extraction strategy अपनाई है, मुझे कुछ ज़्यादा निर्णायक लगता है। बाहर से बैठकर कंपनी की strategy जानने का दावा करना मुश्किल है। मेरे हिसाब से ऐसे scenario की तुलना में यह ज़्यादा संभव है कि infrastructure या capacity issues की वजह से performance हिली हो, या tuning customers की चाहत के बजाय engineers की पसंद की दिशा में हुई हो, या Mythos-related safety messaging की तरह safety concerns के कारण इसे ज़्यादा cautious बनाया गया हो। ये कारण एक-दूसरे के mutually exclusive भी नहीं हैं। मुझे भी Opus 4.7 बहुत ज़्यादा impressive नहीं लगा, लेकिन मैंने इसे अभी लंबा इस्तेमाल भी नहीं किया है और benchmarks भी खुद नहीं चलाए। ऊपर से, आजकल मैं Claude से कुछ हफ़्ते पहले की तुलना में कहीं ज़्यादा कठिन Bayesian probabilistic modeling वाले काम करवा रहा हूँ, इसलिए हो सकता है कि मैं ही model limits को ज़्यादा push कर रहा हूँ

  • यह तुलना ऐसी लगती है जैसे token counting API से prompt length को दो तरीकों से मापकर सिर्फ़ tokenizer change को isolate किया गया हो। अगर ज़्यादा स्मार्ट model छोटा response दे और इस वजह से output tokens कम हो जाएँ, तो उस पहलू को शामिल किए बिना सिर्फ़ इस तुलना से यह कहना मुश्किल है कि 4.7 वास्तव में सस्ता है। बेशक कुल मिलाकर यह महंगा भी पड़ सकता है या सस्ता भी, लेकिन सिर्फ़ इस data से real-world usage का फ़ैसला लेना मुझे ज़्यादा मददगार नहीं लगता

    • real-world के क़रीब data के रूप में Artificial Analysis benchmark ने बताया कि 4.6 max ने लगभग 16 करोड़ tokens और 4.7 max ने लगभग 10 करोड़ tokens इस्तेमाल किए। Cost breakdown देखें तो input cost 800 डॉलर बढ़ी, लेकिन output cost 1400 डॉलर घटी। बेशक input बनाम output offset कितना होगा, यह use case के अनुसार बहुत अलग हो सकता है, और effort जितना कम होगा, अंतर भी उतना छोटा हो सकता है
    • मुझे समझ नहीं आता कि इसे बेकार क्यों कहा जा रहा है। 4.7 की input token pricing वही रहती है, लेकिन वही prompt अब input के आधार पर लगभग 30% ज़्यादा महंगा पड़ता है, यह बात तो साफ़ दिखती है
    • सही बात। मैंने भी 4.6 में हर session को max effort पर बदलना शुरू किया, तो उल्टा token usage घटता देखा। बीच-बीच में सोच खुद को सुधार लेती थी, इसलिए trial-and-error कम हुआ और काम कम steps में पूरा हो गया। दूसरी तरफ़ 4.7 में basic tasks पर भी ज़्यादा भटकाव दिखा। हालाँकि लंबे context को देर तक पकड़े रखने की क्षमता थोड़ी बेहतर लगी
    • AI में किसी भी तरह की ऐसी useful comparison मिलती ही नहीं जिस पर सब सहमत हो जाएँ

  • फ़िलहाल मैं VSCode Copilot में Opus 4.5 को ही main model की तरह इस्तेमाल करता रहूँगा। मेरे workflow में मैं agent को काफ़ी detailed instructions देता हूँ, लेकिन ज़्यादातर agents बार-बार ज़रूरत से ज़्यादा करने लगते हैं। मैंने जो models इस्तेमाल किए, उनमें Opus 4.5 की सबसे बड़ी खूबी यह थी कि अधूरे prompts में भी वह मेरी चाही हुई सीमा समझकर बस उतना ही करने की कोशिश करता था। 4.6 ज़्यादा समय लेता था, ज़रूरत से ज़्यादा सोचता था, और changes का scope भी बड़ा हो जाता था, और top GPT models में भी यही समस्या थी। Sonnet जैसे दूसरे models, कम precise instructions से मेरी intent समझने में Opus जितने अच्छे नहीं थे। इसलिए मैंने experiment करना बंद कर दिया और 4.5 ही इस्तेमाल करता रहा, और महंगा होने के बावजूद मुझे वह worth it लगा। लेकिन अब अगर 4.7, VSCode Copilot में 4.5 और 4.6 दोनों को replace कर दे, और उसके ऊपर 7.5x modifier भी लगे, तो मेरे लिए यह और धीमा और और महंगा रास्ता लगता है, यानी साफ़ regression

    • क्या बस Sonnet इस्तेमाल नहीं किया जा सकता?
    • मैं भी यही समझना चाहता था कि 4.7, 4.5 और 4.6 दोनों को replace करेगा, तो क्या सच में 4.5 हटा दिया जाएगा। मैं भी 4.5 पर settle हो गया था, इसलिए अगर यह सच है तो काफ़ी अफ़सोस होगा

  • मुझे बढ़ती हुई हद तक ऐसा लगने लगा है कि LLM को सिर्फ़ scaling करके white-collar काम को पूरी तरह replace किया जा सकता है, यह एक भोली धारणा है। attention mechanism या Hopfield network शायद मानव मस्तिष्क के केवल कुछ हिस्सों को ही model करते हैं, और आजकल जो agentic memory augmentation की बाढ़ आई हुई है, वह खुद इस बात का संकेत लगती है कि सिर्फ़ मौजूदा SOTA transformer काफ़ी नहीं है। केवल text domain में सीमित करके देखें, तब भी सीमाएँ दिखती हैं, हालाँकि हो सकता है मैं बस Yann LeCun वाली दलील दोहरा रहा हूँ

    • संभव है कि आप सच में वही दलील दोहरा रहे हों। transformer मानव मस्तिष्क के सिर्फ़ एक small subset जैसा है, यह तर्क मुझे neurobiology के हिसाब से भी और वास्तविक LLM performance के हिसाब से भी कमज़ोर लगता है। transformer सिर्फ़ LLM तक सीमित नहीं हैं, बल्कि video, audio, SLAM, VLA जैसे बहुत व्यापक क्षेत्रों में इस्तेमाल होने वाली बेहद general-purpose और expressive architecture हैं। सिर्फ़ इसलिए कि उन्होंने मानव मस्तिष्क की 1:1 नकल नहीं की, इसका मतलब यह नहीं कि वे functional equivalence वाली intelligence तक नहीं पहुँच सकते। मानव मस्तिष्क evolution से निकली एक implementation strategy भर है। LeCun का LLM यह नहीं कर सकते वाला दावा भी अनुभवजन्य रूप से बार-बार ग़लत साबित हो रहा है। ARC-AGI-3 जैसे benchmarks, जो LLM के ख़िलाफ़ design किए गए हैं, उनमें भी अभी तक मैंने कोई ऐसा AI family नहीं देखा जो LLM से बेहतर कहा जा सके
    • मुझे लगता है सिर्फ़ scaling से हम लगभग ceiling तक पहुँच चुके हैं। हाँ, efficiency बेहतर हो सकती है, और आसपास का tooling या harness आगे बढ़ता रहेगा
    • सिर्फ़ text तक सीमित करें तब भी सवाल रहता है। अभी तक यह एक पूरा उपन्यास ठीक से क्यों नहीं लिख पाता? मानक थोड़ा नीचे करके novella भर मान लें, तब भी Death in Venice, Candide, The Metamorphosis, Breakfast at Tiffany's जैसी रचनाओं के स्तर तक नहीं पहुँचता। Training corpus में किताबें तो सब रही होंगी, तो क्या यह सिर्फ़ इस बात का मामला है कि अभी तक किसी ने token cost पर लाखों डॉलर खर्च करके यह कोशिश नहीं की?

  • कल मैंने Opus 4.7 से single-page website की best practices व्यवस्थित करवाने की कोशिश की, और सिर्फ़ लगभग 4 prompts में ही daily limit पार हो गई। उसके बाद लगभग 7 और किए तो weekly limit भी पार हो गई। पूरा HTML/CSS/JS मिलाकर 300 lines भी नहीं थीं, इसलिए usage limit का इतनी जल्दी ख़त्म हो जाना काफ़ी shocking लगा

    • मैंने इसी तरह की चीज़ों की आशंका के कारण अभी तक Claude इस्तेमाल ही नहीं किया। Enterprise subscription में सिर्फ़ बिल बढ़ेगा, और VP के लिए भी तुरंत पूरी कंपनी में migration announce करना आसान नहीं होगा। अगर पहले individual subscribers churn करें, तो data center usage घटे और profitability बढ़े, ऐसा भी हो सकता है
    • आपने reasoning effort क्या सेट किया था, यह जानना चाहूँगा। मेरी जानकारी में अभी Max कहीं ज़्यादा tokens खाता है, और ज़्यादातर use cases के लिए recommended भी नहीं है। नया default xhigh भी पुराने default medium से ज़्यादा खपत करता है
    • आप किस plan पर हैं, यह जानना चाहूँगा। अगर Pro है तो शायद ऐसा हो सकता है, लेकिन Max plan पर भी इतना हो रहा हो तो थोड़ा surprising होगा
    • क्या आप Claude subscription इस्तेमाल कर रहे हैं? जहाँ तक मुझे पता है, subscription-based Claude इस तरह काम नहीं करता

  • मुझे लगता है title 4.7 से 4.6 नहीं, बल्कि 4.6 to 4.7 होना चाहिए

    • पूरी तरह सहमत
    • जो लोग बाएँ से दाएँ पढ़ते हैं, उनके लिए भी Opus 4.6 to 4.7 ज़्यादा natural लगता है

  • Artificial Analysis explanation के मुताबिक, Opus 4.7 को Adaptive Reasoning, Max Effort के आधार पर Intelligence Index चलाने में लगभग 4,406 डॉलर लगे, जो 4.6 के लगभग 4,970 डॉलर से करीब 11% सस्ता था। Score 4 points ज़्यादा था, और उनका कहना है कि यह अंतर नए tokenizer को ध्यान में रखने के बाद भी output tokens के कम इस्तेमाल की वजह से आया। हालाँकि cached input discount अभी इस calculation में शामिल नहीं है, और उन्होंने कहा है कि इसे जल्द cost calculation में जोड़ा जाएगा

  • मेरी impression यह है कि बातचीत की quality उम्मीद से बेहतर हुई है। यह ज़्यादा self-critical लगता है, सुझावों की भी आलोचनात्मक जाँच करता है, और default choices भी आम तौर पर बेहतर लगती हैं। यहाँ बाकी लोगों जितने harnesses मैंने इस्तेमाल नहीं किए, इसलिए शायद मेरे लिए अंतर उतना तेज़ न हो, लेकिन कम तैयार users के लिए इसकी value शायद और ज़्यादा हो। हाल की review threads को recap करना हो या product discussion पर नज़र डालनी हो, ऐसे basic tasks में भी 4.6 उपयोगी तो था, लेकिन कभी-कभी foot-gun बन सकता था, जबकि 4.7 टीम के किसी senior member की तरह behave करने की संभावना ज़्यादा रखता है