Claude में 1M tokens की कीमत कितनी है?

Claude में 1M tokens की लागत कितनी है?

1M tokens का अर्थ one million tokens है। Claude API (application programming interface) की सभी कीमतें इसी इकाई में बताई जाती हैं। इसकी कोई एक निश्चित कीमत नहीं है, क्योंकि input और output की billing दरें अलग होती हैं और हर model की अपनी दरें होती हैं। August 2026 तक, Claude Haiku 4.5 पर one million input tokens की लागत $1 है, Claude Sonnet 5 पर $2 है और Claude Opus 5 पर $5 है।

Output महंगा हिस्सा है। हर वर्तमान model में output की दर input दर की पांच गुना है। इसलिए आपके bill पर headline figure से अधिक input और output का अनुपात प्रभाव डालता है। जो app लंबे documents भेजकर छोटे answers लौटाता है, उसका व्यवहार उस app से बहुत अलग होता है जो छोटे prompt से लंबे answers लिखता है।

यह पृष्ठ unit economics पर केंद्रित है: एक token की लागत कितनी है और build करने से पहले bill का अनुमान कैसे लगाएं। काम करते समय tokens वास्तव में कहां जाते हैं, यह जानने के लिए Claude Code session के अंदर tokens कहां जाते हैं पढ़ें।

1M टोकन कैसा दिखता है

टोकन उस टेक्स्ट का एक भाग है जिसे मॉडल पढ़ता या लिखता है। Anthropic के मोटे अनुमान के अनुसार, 4 अक्षरों पर लगभग 1 टोकन होता है, या अंग्रेज़ी में लगभग 0.75 शब्द। इसलिए 1M टोकन लगभग 750,000 शब्द, या सामान्य टेक्स्ट के लगभग 4 MB के बराबर होते हैं।

आम इनपुट के प्रकाशित अनुमान इस पैमाने को बेहतर ढंग से समझने में मदद करते हैं।

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

इन दरों पर, 1M टोकन लगभग 400 औसत वेब पेजों को एक बार पढ़ने, या उस आकार के आठ शोध-पत्रों के बराबर है। यह मध्यम आकार के किसी codebase पर एक बार काम करने, या एक व्यक्ति द्वारा एक महीने तक हल्के chat उपयोग के बराबर है।

इन सभी आंकड़ों को अनुमान मानें। Code, JSON और अंग्रेज़ी के अलावा अन्य भाषाओं के टेक्स्ट में एक टोकन में कम शब्द समा सकते हैं, इसलिए 0.75 का अनुपात आशावादी सीमा पर है। एक और बात गणना को बदलती है: Claude Opus 4.7 और उसके बाद के मॉडल, जिनमें Opus 5 और Sonnet 5 शामिल हैं, एक नया tokenizer उपयोग करते हैं। यह Sonnet 4.6 और उससे पहले के मॉडल की तुलना में समान टेक्स्ट के लिए लगभग 30 प्रतिशत अधिक टोकन बनाता है। Claude Haiku 4.5 पुराना tokenizer उपयोग करता है। इसलिए Haiku 4.5 पर मापी गई गणना समान input के लिए Sonnet 5 पर वास्तविक गणना से कम होगी। इसका अर्थ है कि इस सीमा के आर-पार प्रति-मिलियन मूल्य की सीधी तुलना उचित नहीं है। निर्णय लेने से पहले उसी prompt की गणना दोनों models के लिए करें।

Claude प्रति million tokens कितना शुल्क लेता है

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 के लिए 31 August 2026 तक शुरुआती मूल्य लागू है: input के लिए $2 और output के लिए $10। 1 September 2026 से मानक दर लागू होगी: input के लिए $3 और output के लिए $15। Claude Opus 5 की दर $5 और $25 है।

दरें बदल सकती हैं। इस पृष्ठ पर दिए गए प्रत्येक आंकड़े को August 2026 की तारीख वाला उदाहरण मानें। बजट को अंतिम रूप देने से पहले आधिकारिक मूल्य निर्धारण पृष्ठ पर वर्तमान आंकड़ों की पुष्टि करें।

Context length दर को नहीं बदलती। Claude 4.6 और उसके बाद के संस्करणों में पूरी 1M token context window पर मानक मूल्य लागू होता है। इसलिए 900,000 token वाला request प्रति token उतना ही खर्च होता है जितना 9,000 token वाला request। लंबा prompt अधिक महंगा होता है क्योंकि उसमें अधिक tokens होते हैं। Long-context के लिए कोई अलग दर लागू नहीं होती।

मूल्य बदलने पर भी सही रहने वाली गणना

हर बिल में दो गुणा और एक जोड़ होता है।

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

इसे चलाने योग्य code के रूप में लिखें:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

यह 0.0126 प्रिंट करता है। 4,300 input tokens भेजने और 400 output tokens प्राप्त करने वाले request की Sonnet 5 पर लागत लगभग 1.3 cents होती है। दोनों rates को अपने code में एक ही स्थान पर रखें। मूल्य बदलने पर आप दो lines संपादित करते हैं, और आपके system का हर estimate उसी के अनुसार बदल जाता है।

वास्तविक ऐप के लिए एक उदाहरणात्मक अनुमान

एक support assistant पर विचार करें। इसका system prompt और product documentation मिलकर 4,000 tokens होते हैं। वे हर request के साथ भेजे जाते हैं, क्योंकि Messages API stateless है और model calls के बीच कुछ याद नहीं रखता। उपयोगकर्ता का प्रश्न लगभग 300 tokens जोड़ता है। उत्तर लगभग 400 tokens का होता है। इसलिए प्रत्येक request में 4,300 input और 400 output होते हैं।

1,000,000 input tokens से इस प्रकार की लगभग 232 requests की जा सकती हैं। प्रतिदिन 1,000 requests पर ऐप रोज़ 4.3 million input tokens खर्च करता है। इसलिए "1M tokens" का अर्थ 6 घंटे से कम का traffic है।

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Claude Opus 5 पर इस traffic की लागत प्रत्येक 1,000 requests के लिए $31.50 है। Sonnet 5 पर यह $12.60 है। Claude Haiku 4.5 पर जाने से लागत $6.30 हो जाती है। Sonnet 5 पर warm prompt cache के साथ लागत और कम होकर $5.40 रह जाती है।

एक महीने के traffic के लिए इसे 30 से गुणा करें। List rates पर Sonnet 5 की लागत लगभग $378 प्रति माह है। Warm cache के साथ उसी ऐप की लागत लगभग $162 प्रति माह है। इस volume पर आपके model का चुनाव और caching का निर्णय, दोनों उस किसी भी rate से अधिक महत्वपूर्ण हैं जिस पर आप बातचीत करके छूट प्राप्त कर सकते हैं। कौन-सा model चलाना है, यह अलग प्रश्न है। जो सबसे सस्ता model आपके evaluations में सफल हो, वही सही विकल्प है: Opus, Sonnet और Haiku के बीच चयन में इसकी उचित testing की विधि दी गई है।

Prompt caching दोहराए गए हिस्से की लागत घटाती है

वह 4,000 टोकन वाला prefix हर request में समान है, और हर बार उसके लिए पूरी input दर चुकानी पड़ती है। Prompt caching, संसाधित prefix को store करती है और उसे दोबारा उपयोग करने पर कम दर लागू करती है।

Cache read की लागत base input rate की 0.1 गुना होती है। 5 मिनट की lifetime के लिए cache लिखने की लागत base की 1.25 गुना होती है, जबकि 1 घंटे की lifetime के लिए यह 2 गुना होती है। इसलिए 5 मिनट वाला cache एक read के बाद अपनी लागत निकाल लेता है, क्योंकि लिखने पर 0.25 अतिरिक्त लागत आती है और प्रत्येक read पर 0.9 की बचत होती है। 1 घंटे वाले cache को बराबरी पर आने के लिए 2 read चाहिए।

इसे चालू करने का सबसे सरल तरीका एक single top-level field है:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

इसके बाद वापस आने वाला usage block पढ़ें:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

इन तीन input counters पर तीन अलग-अलग दरें लागू होती हैं और इनका योग आपकी वास्तविक input volume है: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens। केवल input_tokens पढ़कर किया गया cost estimate, caching चालू होने के बाद बहुत गलत होगा।

दो बातें cache को लाभदायक बनने से रोकती हैं, और दोनों बिना किसी error के विफल होती हैं।

prefix byte-identical होना चाहिए। Cache lookup prefix match का उपयोग करता है। इसलिए आपके system prompt के आरंभ में timestamp या user का name होने पर यह हर request में बदल जाता है। तब हर बार base input की 1.25 गुना लागत चुकानी पड़ती है और कभी read नहीं होता। इसका संकेत यह है कि cache_creation_input_tokens ऊंचा बना रहता है, जबकि cache_read_input_tokens 0 बना रहता है। cache_control को उस अंतिम block पर रखें जिसकी content सभी requests में समान है, और बदलने वाली सारी content उसके बाद रखें। अपनी tools definitions बदलने पर उनके नीचे का पूरा cache invalid हो जाता है, क्योंकि invalidation tools, फिर system, फिर messages के क्रम में नीचे तक चलता है।

prefix पर्याप्त लंबा होना चाहिए। Opus 5 पर cacheable length न्यूनतम 512 tokens, Sonnet 5 पर 1,024 tokens और Haiku 4.5 पर 4,096 tokens है। इससे छोटा prompt cache नहीं होता और कोई error वापस नहीं मिलता। ऊपर दिए गए उदाहरण का 4,000 token वाला prefix Sonnet 5 पर cache होता है, लेकिन Haiku 4.5 पर नहीं, क्योंकि 4,000 उस model की न्यूनतम सीमा से कम है। जब दोनों counters 0 दिखाते हैं, तो कुछ भी cache नहीं हुआ।

बैच प्रोसेसिंग दर को आधा कर देती है

Batch API अनुरोधों को इनपुट और आउटपुट, दोनों पर 50 प्रतिशत की छूट के साथ एसिंक्रोनस रूप से प्रोसेस करती है। ऊपर दिए गए उदाहरण में, इससे 1,000 अनुरोधों की लागत $12.60 से घटकर $6.30 हो जाती है। यह छूट prompt caching के साथ जुड़ती है, इसलिए bulk work चलाने के लिए cached batch job सबसे कम लागत वाला तरीका है।

इसमें आपको latency छोड़नी पड़ती है। इसलिए Batch उन कार्यों के लिए सही नहीं है जिनके परिणाम के लिए कोई व्यक्ति बैठकर प्रतीक्षा कर रहा हो। यह overnight classification और document backfills के लिए उपयुक्त है।

एक बातचीत के भीतर चैट की लागत क्यों बढ़ती है

क्योंकि API कोई स्थिति बनाए नहीं रखता, आपका client हर turn पर पूरी बातचीत फिर से भेजता है। इसलिए एक ही चैट में token का उपयोग उसकी लंबाई के वर्ग के साथ बढ़ता है, सीधी रेखा में नहीं।

मान लें कि प्रत्येक turn में औसतन 500 tokens होते हैं। Turn 1 में 500 input tokens भेजे जाते हैं। Turn 2 में 1,000। Turn 20 में 10,000। इसे n(n+1)/2 के अनुसार जोड़ने पर 20 turn की बातचीत में लगभग 105,000 input tokens भेजे जा चुके होते हैं, जबकि transcript स्वयं केवल 10,000 tokens लंबा होता है।

इसी कारण किसी chat सुविधा की लागत उसके transcript से अधिक होती है। इसी कारण लंबे threads में स्थिर prefix को cache करना या पुराने turns का सारांश बनाना लागत को उचित ठहराता है। जो agent tool calls पर loop करता है, उसका पैटर्न भी यही होता है, और स्थिति इससे भी खराब होती है: प्रत्येक tool result history में बना रहता है और बाद के हर turn पर फिर से भेजा जाता है। अपने चलाए गए agent पर कड़ी spending limit लगाना यहां सबसे महत्वपूर्ण है, क्योंकि यह वृद्धि स्वचालित होती है और इसकी निगरानी कोई नहीं कर रहा होता।

अनुमान लगाने से पहले tokens की गिनती करें

Word count से token count निकालना बंद करें। API इन्हें आपके लिए बिना किसी शुल्क के गिनती है। इसके लिए message creation से अलग rate limit होती है।

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

Response में एक field होती है:

{ "input_tokens": 14 }

इसमें अपना वास्तविक system prompt और tool definitions, साथ में एक प्रतिनिधि user message, भेजें। फिर प्राप्त संख्या को ऊपर दिए गए cost function में रखें। Endpoint वही body स्वीकार करता है जो message request स्वीकार करती है। इसलिए images और PDFs की भी सही गिनती होती है। दो सावधानियां महत्वपूर्ण हैं। यह count एक estimate है और billed figure से थोड़ा अलग हो सकता है। इसे आपके द्वारा भेजे गए model के tokenizer से मापा जाता है। इसलिए वही model भेजें जिसे आप वास्तव में चलाएंगे।

Output tokens की पहले से गिनती नहीं की जा सकती, क्योंकि वे अभी मौजूद नहीं होते। उन्हें max_tokens से सीमित करें। फिर live traffic पर usage.output_tokens से वास्तविक distribution मापें।

बिल में और क्या शामिल होता है

बिल का अधिकांश हिस्सा tokens का होता है। कुछ मदें tokens नहीं होतीं और वे लोगों को आश्चर्यचकित करती हैं।

• हर request पर tool definitions input tokens में बदल जाती हैं। केवल tool use system prompt ही Opus 5 पर 286 से 406 tokens जोड़ता है, आपके अपने schemas को शामिल किए बिना। दस विस्तृत tool descriptions छोटे prompt का आकार दोगुना कर सकते हैं।
• Web search के लिए प्रति 1,000 searches पर $10 शुल्क लिया जाता है। इसके अतिरिक्त, results के context में आने पर उनके द्वारा उपयोग किए गए tokens का भी शुल्क लगता है।
• Web fetch का अपना कोई शुल्क नहीं है, लेकिन fetched page input tokens में बदल जाता है। 100 kB का documentation page लगभग 25,000 tokens का होता है।
• Claude 4.6 और उसके बाद के versions पर inference_geo के साथ केवल US में inference का अनुरोध करने पर हर token category पर 1.1 multiplier लागू होता है। इसमें cache reads और writes भी शामिल हैं।

API खरीदना आपके लिए सही है या नहीं, यह आपके volume पर निर्भर करता है। उपयोग का स्तर एक निश्चित सीमा से कम होने पर flat monthly plan स्पष्ट रूप से बेहतर होता है, और Claude subscription की तुलना API से वास्तविक numbers के साथ यह तुलना करता है।

FAQ

Claude में 1M tokens की लागत कितनी है?

यह model पर निर्भर करता है और इस पर भी कि tokens input हैं या output। August 2026 तक, Claude Haiku 4.5 पर one million input tokens की लागत $1 है, introductory pricing के तहत Claude Sonnet 5 पर $2 है, और Claude Opus 5 पर $5 है। इन सभी models पर output की लागत input दर से पांच गुना है। 1 September 2026 को Sonnet 5 की दर input के लिए $3 और output के लिए $15 हो जाएगी। दरें बदलती रहती हैं। बजट में कोई राशि तय करने से पहले official pricing page पर इसकी पुष्टि करें।

क्या 1M tokens, 1M words के बराबर हैं?

नहीं। एक token में English के लगभग 4 characters होते हैं, या लगभग 0.75 words होते हैं। इसलिए one million tokens में लगभग 750,000 words होते हैं। यह अनुपात केवल एक अनुमान है। Code, JSON और English के अलावा अन्य languages में प्रति word अधिक tokens लगते हैं। Claude Opus 4.7 और उसके बाद के versions में नया tokenizer भी उपयोग होता है। समान text के लिए यह Claude Sonnet 4.6 और उससे पहले के versions की तुलना में लगभग 30 percent अधिक tokens बनाता है। इसलिए अलग-अलग model generations के बीच counts सीधे लागू नहीं किए जा सकते। जिस model को चलाने की योजना है, उसे पास करके free /v1/messages/count_tokens endpoint से माप करें।

क्या prompt caching से हमेशा पैसे बचते हैं?

नहीं। 5 minute cache write की लागत base input rate की 1.25 गुना होती है। इसलिए ऐसा prefix जिसे लिखा जाए लेकिन कभी पढ़ा न जाए, उसे सामान्य रूप से भेजने की तुलना में 25 percent अधिक लागत आती है। पहली read से इसकी लागत वसूल हो जाती है। यह दो तरीकों से विफल होता है और दोनों में कोई स्पष्ट संकेत नहीं मिलता। यदि requests के बीच cached prefix बदल जाता है, तो lookup कभी match नहीं होता, क्योंकि यह exact prefix match होता है। यदि prefix model की minimum cacheable length से छोटा है, जो Sonnet 5 पर 1,024 tokens और Haiku 4.5 पर 4,096 है, तो कुछ भी cache नहीं होता और कोई error वापस नहीं मिलता। जब cache_creation_input_tokens और cache_read_input_tokens दोनों का मान 0 हो, तो cache कोई काम नहीं कर रहा है।

मेरे bill की राशि message count से अधिक तेज़ी से क्यों बढ़ी?

क्योंकि हर turn पर पूरी conversation फिर से भेजी जाती है। Messages API कोई state नहीं रखता। इसलिए chat के turn 20 में पहले के सभी 19 turns फिर से input के रूप में शामिल होते हैं। यदि प्रत्येक turn में औसतन 500 tokens हों, तो 20 turn की conversation लगभग 105,000 input tokens भेजती है, जबकि transcript की लंबाई केवल 10,000 tokens होती है। Agent loops भी इसी तरह काम करते हैं, क्योंकि हर tool result history में बना रहता है। Stable prefix को cache करें, या पुराने turns का summary बनाकर उन्हें request से हटा दें।