Claude मध्ये 1M tokens ची किंमत किती?

Claude मध्ये 1M tokens ची किंमत किती आहे?

1M tokens म्हणजे one million tokens. Claude API (application programming interface) ची प्रत्येक किंमत याच एककात दिली जाते. याची एकच निश्चित किंमत नाही. Input आणि output साठी वेगवेगळे दर लागू होतात आणि प्रत्येक model साठी या दोन्हींची स्वतंत्र जोडी असते. August 2026 पर्यंत, Claude Haiku 4.5 वर one million input tokens ची किंमत $1 आहे. Claude Sonnet 5 वर ती $2 आणि Claude Opus 5 वर $5 आहे.

Output हा अधिक महाग भाग आहे. सध्याच्या प्रत्येक model मध्ये output rate हा input rate च्या पाचपट आहे. त्यामुळे तुमच्या bill वर headline figure पेक्षा input आणि output यांचे प्रमाण अधिक परिणाम करते. एखादे अॅप मोठे documents पाठवून लहान उत्तरे परत करत असेल, तर त्याचा खर्च लहान prompt वरून मोठी उत्तरे तयार करणाऱ्या अॅपपेक्षा खूप वेगळा असेल.

या पृष्ठावर unit economics समजावले आहेत: एका token ची किंमत किती आहे आणि build करण्यापूर्वी bill चा अंदाज कसा घ्यायचा. काम करताना tokens प्रत्यक्षात कुठे वापरले जातात हे जाणून घेण्यासाठी Claude Code session मध्ये tokens कुठे वापरले जातात हे वाचा.

1M tokens म्हणजे किती मजकूर

Token म्हणजे model वाचतो किंवा लिहितो असा मजकुराचा एक भाग. Anthropic च्या अंदाजानुसार 4 characters साठी साधारणपणे 1 token लागतो, म्हणजे English मधील सुमारे 0.75 words. त्यामुळे 1 million tokens म्हणजे सुमारे 750,000 words किंवा साध्या मजकुराची अंदाजे 4 MB मात्रा.

सामान्य input साठी प्रकाशित केलेले अंदाज या प्रमाणाची अधिक स्पष्ट कल्पना देतात.

[
  {
    "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 tokens म्हणजे सरासरी आकाराची सुमारे 400 web pages एकदा वाचणे किंवा त्या आकाराचे 8 research papers वाचणे. हे मध्यम आकाराच्या codebase वर एकदा प्रक्रिया करण्याइतके किंवा एका व्यक्तीच्या एका महिन्याच्या मर्यादित chat वापराइतके आहे.

हे सर्व केवळ अंदाज म्हणून घ्या. Code, JSON आणि English व्यतिरिक्त इतर भाषांमधील मजकुरात एका token मध्ये कमी words येतात. त्यामुळे 0.75 हे प्रमाण अधिक आशावादी टोकाचे आहे. Token count वर आणखी एक घटक परिणाम करतो: Claude Opus 4.7 आणि त्यानंतरच्या आवृत्त्या, ज्यात Opus 5 आणि Sonnet 5 समाविष्ट आहेत, नवीन tokenizer वापरतात. त्यामुळे Sonnet 4.6 आणि त्यापूर्वीच्या आवृत्त्यांच्या तुलनेत समान मजकुरासाठी ते साधारणपणे 30 percent अधिक tokens तयार करतात. Claude Haiku 4.5 जुना tokenizer वापरतो. त्यामुळे Haiku 4.5 वर मोजलेला count समान input साठी Sonnet 5 वरील count पेक्षा कमी असेल. याचा अर्थ त्या मर्यादेच्या दोन्ही बाजूंच्या models ची थेट price-per-million तुलना योग्य नाही. निर्णय घेण्यापूर्वी समान prompt दोन्ही models विरुद्ध मोजा.

Claude प्रति दशलक्ष 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 पर्यंत introductory pricing लागू आहे: input साठी $2 आणि output साठी $10. 1 September 2026 पासून standard rate लागू होईल: input साठी $3 आणि output साठी $15. Claude Opus 5 साठी input चे शुल्क $5 आणि output चे शुल्क $25 आहे. या दरांपेक्षाही अधिक महाग असलेले एक model आहे: Claude Fable 5 साठी input चे शुल्क $10 आणि output चे शुल्क $50 आहे. त्यामुळे हे दर देणे योग्य आहे का हे तुम्ही प्रत्यक्षात कोणती कामे त्यावर चालवता यावर अवलंबून असते.

दर बदलतात. या पानावरील प्रत्येक आकडा August 2026 दिनांकित उदाहरण म्हणून पहा. Budget निश्चित करण्यापूर्वी official pricing page वरील सध्याचे आकडे पडताळा.

हे दर Claude ची किंमत दर्शवतात; मात्र तुमच्या workload साठी तो स्वस्त पर्याय आहे का हे सांगत नाहीत. Claude आणि ChatGPT वर मोजलेल्या तीन कामांमध्ये प्रत्येक API कुठे अधिक फायदेशीर ठरतो हे दाखवले आहे.

Context length मुळे दर बदलत नाही. Claude 4.6 आणि त्यानंतरच्या आवृत्त्यांमध्ये पूर्ण 1M token context window साठी standard pricing लागू आहे. त्यामुळे 900,000 token च्या request साठी प्रत्येक token ची किंमत 9,000 token च्या request इतकीच असते. मोठ्या prompt मध्ये अधिक tokens असल्यामुळे त्याची किंमत अधिक असते. स्वतंत्र long-context rate लागू होत नाही.

किंमत बदलल्यानंतरही अचूक राहणारी गणना

प्रत्येक बिलासाठी दोन गुणाकार आणि एक बेरीज करावी लागते.

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 असते. दोन्ही दर तुमच्या code मध्ये एकाच ठिकाणी ठेवा. किंमत बदलल्यावर दोन ओळी संपादित करा. त्यानंतर तुमच्या system मधील प्रत्येक estimate त्यानुसार आपोआप बदलेल.

प्रत्यक्ष अॅपसाठी एक उदाहरणात्मक अंदाज

समर्थन सहाय्यकाचा विचार करा. त्याचा system prompt आणि product documentation मिळून 4,000 tokens होतात. Messages API stateless असल्यामुळे आणि model ला calls दरम्यान काहीही आठवत नसल्यामुळे, ते प्रत्येक request सोबत पाठवले जातात. वापरकर्त्याचा प्रश्न सुमारे 300 tokens वाढवतो. उत्तर सुमारे 400 tokensचे असते. त्यामुळे प्रत्येक request साठी 4,300 input आणि 400 output tokens लागतात.

1,000,000 input tokensमधून या स्वरूपाच्या सुमारे 232 requests करता येतात. दररोज 1,000 requests असल्यास अॅप दररोज 4.3 million input tokens वापरते. त्यामुळे "1M tokens" हा 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मध्ये चालते. तुमची model निवड आणि cachingचा निर्णय, या volumeवर तुम्ही negotiate करू शकणाऱ्या कोणत्याही rateपेक्षा अधिक प्रभावी ठरतात. कोणते model चालवायचे हा स्वतंत्र प्रश्न आहे. तुमच्या evaluationsमध्ये यशस्वी ठरणारे सर्वात स्वस्त model निवडा: Opus, Sonnet आणि Haiku यांच्यात निवड कशी करावी यामध्ये त्याची योग्य चाचणी कशी करायची ते दिले आहे.

Prompt caching मुळे पुनरावृत्ती होणारा भाग कमी खर्चात प्रक्रिया करता येतो

तो 4,000 token चा prefix प्रत्येक request मध्ये समान आहे. प्रत्येक वेळी त्यासाठी input ची पूर्ण किंमत द्यावी लागते. Prompt caching प्रक्रिया केलेला prefix साठवते आणि तो पुन्हा वापरताना कमी दर आकारते.

Cache read साठी base input rate च्या 0.1 पट खर्च येतो. 5 minute lifetime साठी cache लिहिण्याचा खर्च base rate च्या 1.25 पट असतो, तर 1 hour lifetime साठी तो 2 पट असतो. त्यामुळे 5 minute cache एका read नंतरच स्वतःचा खर्च भरून काढतो. Write साठी अतिरिक्त 0.25 खर्च येतो, तर प्रत्येक read मध्ये 0.9 ची बचत होते. 1 hour cache ला समसमान खर्च होण्यासाठी दोन reads आवश्यक असतात.

ते सुरू करण्याचा सर्वात सोपा मार्ग म्हणजे एकच 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 चे नाव असल्यास प्रत्येक request मध्ये prefix बदलतो. अशा वेळी प्रत्येक वेळी base input rate च्या 1.25 पट खर्च होतो आणि एकदाही cache read होत नाही. याचे लक्षण म्हणजे cache_creation_input_tokens जास्त राहणे आणि cache_read_input_tokens 0 राहणे. सर्व request मध्ये समान असलेल्या शेवटच्या block वर cache_control ठेवा आणि बदलणारा सर्व मजकूर त्यानंतर ठेवा. तुमच्या tools definitions मध्ये बदल केल्यास त्याखालील संपूर्ण cache invalid होतो, कारण invalidation चा क्रम tools, त्यानंतर system आणि त्यानंतर messages असा असतो.

Prefix पुरेसा मोठा असणे आवश्यक आहे. Opus 5 वर cache करता येणारी किमान लांबी 512 tokens आहे, Sonnet 5 वर 1,024 आणि Haiku 4.5 वर 4,096 tokens आहे. त्यापेक्षा लहान prompt cache केला जात नाही आणि कोणतीही error परत केली जात नाही. वरील उदाहरणातील 4,000 token चा prefix Sonnet 5 वर cache होतो, पण Haiku 4.5 वर cache होत नाही, कारण 4,000 ही त्या model ची किमान मर्यादा पूर्ण करत नाही. दोन्ही counters 0 असल्यास काहीही cache झालेले नाही.

बॅच प्रक्रियेमुळे दर निम्मा होतो

Batch API विनंत्यांवर asynchronous पद्धतीने प्रक्रिया करते आणि input तसेच output या दोन्हींसाठी 50 percent कमी शुल्क आकारते. वरील उदाहरणात 1,000 विनंत्यांसाठीचा $12.60 खर्च $6.30 इतका होतो. हा discount prompt caching सोबत लागू होतो. त्यामुळे bulk काम चालवण्याचा cached batch job हा सर्वात कमी खर्चाचा मार्ग ठरतो.

यासाठी latency वाढते. त्यामुळे एखादी व्यक्ती परिणामाची वाट पाहत असेल अशा कामांसाठी batch योग्य नाही. मात्र overnight classification आणि document backfills साठी ते उपयुक्त आहे.

एका संभाषणातील chat खर्च का वाढतो

API कोणतीही स्थिती जतन करत नाही. त्यामुळे प्रत्येक turn वेळी तुमचा client संपूर्ण संभाषण पुन्हा पाठवतो. म्हणून एका chat मधील 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 feature चा खर्च transcript वरून दिसतो त्यापेक्षा जास्त असतो. तसेच दीर्घ threads मध्ये स्थिर prefix cache करणे किंवा जुन्या turns चा सारांश तयार करणे खर्च वाचवते. Tool calls वर loop करणाऱ्या agent मध्येही हाच नमुना दिसतो, आणि तो अधिक खर्चिक असतो: प्रत्येक tool result history मध्ये राहतो आणि नंतरच्या प्रत्येक turn वेळी पुन्हा पाठवला जातो. तुम्ही स्वतः चालवत असलेल्या agent साठी कठोर spending limit लावणे येथे विशेष महत्त्वाचे आहे, कारण ही वाढ आपोआप होते आणि तिच्यावर कोणी लक्ष ठेवत नसते.

अंदाज करण्यापूर्वी tokens ची संख्या मोजा

शब्दांच्या संख्येवरून tokens ची संख्या काढणे थांबवा. 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 message request प्रमाणेच body स्वीकारतो. त्यामुळे images आणि PDFs यांची संख्याही योग्यरीत्या मोजली जाते. दोन बाबी लक्षात ठेवा. ही संख्या estimate असते आणि billed figure पेक्षा थोडी वेगळी असू शकते. तसेच ती तुम्ही दिलेल्या model च्या tokenizer ने मोजली जाते. त्यामुळे प्रत्यक्ष वापरणार असलेला model द्या.

Output tokens ची संख्या आधी मोजता येत नाही, कारण ते अद्याप अस्तित्वात नसतात. max_tokens ने त्यांची कमाल संख्या मर्यादित करा. त्यानंतर live traffic वरील usage.output_tokens मधून वास्तविक distribution मोजा.

बिलमध्ये आणखी काय समाविष्ट होते

बिलमधील बहुतांश खर्च tokens चा असतो. काही घटक tokens नसतात आणि त्यांच्यामुळे अनेकांना अनपेक्षित खर्च दिसतो.

• प्रत्येक request मध्ये tool definitions input tokens मध्ये रूपांतरित होतात. तुमचे स्वतःचे schemas जोडण्यापूर्वीच, tool use system prompt मुळे Opus 5 वर 286 ते 406 tokens वाढतात. दहा विस्तृत tool descriptions मुळे लहान prompt चा आकार दुप्पट होऊ शकतो.
• Web search साठी प्रत्येक 1,000 searches मागे $10 आकारले जातात. याशिवाय, results context मध्ये समाविष्ट झाल्यावर वापरल्या जाणाऱ्या tokens चा खर्च वेगळा असतो.
• Web fetch साठी स्वतंत्र शुल्क नाही. मात्र fetch केलेले page input tokens मध्ये रूपांतरित होते. 100 kB documentation page मध्ये साधारण 25,000 tokens असतात.
• Claude 4.6 आणि त्यानंतरच्या आवृत्त्यांमध्ये inference_geo वापरून US-only inference मागितल्यास प्रत्येक token category वर 1.1 multiplier लागू होतो. Cache reads आणि cache writes यांचाही त्यात समावेश होतो.

API खरेदी करणे योग्य आहे की नाही हे तुमच्या वापराच्या प्रमाणावर अवलंबून असते. एखाद्या plan ची usage ceiling गाठल्यावर हा प्रश्न सहसा निर्माण होतो. मर्यादेतून बाहेर पडण्याचे मार्ग window संपेपर्यंत प्रतीक्षा करण्यापासून ते ते काम metered API calls वर हलवण्यापर्यंत असतात. वापराचे प्रमाण एका विशिष्ट पातळीपेक्षा कमी असल्यास flat monthly plan थेट अधिक फायदेशीर ठरतो. Claude subscription च्या तुलनेत API या तुलनेचे वास्तविक आकडे देतो.

FAQ

Claude मध्ये 1M tokens ची किंमत किती आहे?

हे model आणि tokens input आहेत की output यावर अवलंबून असते. August 2026 नुसार Claude Haiku 4.5 मध्ये 1M input tokens ची किंमत $1 आहे, introductory pricing अंतर्गत Claude Sonnet 5 मध्ये $2 आहे आणि Claude Opus 5 मध्ये $5 आहे. या प्रत्येक model मध्ये output ची किंमत input दराच्या पाचपट आहे. 1 September 2026 रोजी Sonnet 5 साठी input ची किंमत $3 आणि output ची किंमत $15 होईल. दर बदलू शकतात. त्यामुळे budget मध्ये एखादी रक्कम निश्चित करण्यापूर्वी अधिकृत pricing page वर दरांची खात्री करा.

1M tokens म्हणजे 1M words इतकेच आहेत का?

नाही. English मध्ये एक token म्हणजे साधारण 4 characters किंवा सुमारे 0.75 words असतात. त्यामुळे 1M tokens म्हणजे सुमारे 750,000 words होतात. हे प्रमाण केवळ अंदाजासाठी आहे. Code, JSON आणि English व्यतिरिक्त इतर languages मध्ये प्रत्येक word साठी अधिक tokens लागतात. Claude Opus 4.7 आणि त्यानंतरच्या आवृत्त्यांमध्ये नवीन tokenizer वापरला जातो. त्यामुळे Claude Sonnet 4.6 आणि त्यापूर्वीच्या आवृत्त्यांच्या तुलनेत समान text साठी साधारण 30 percent अधिक tokens तयार होतात. म्हणून वेगवेगळ्या model generations मधील counts थेट वापरता येत नाहीत. तुम्ही चालवणार असलेला model देऊन विनामूल्य /v1/messages/count_tokens endpoint वापरून मोजणी करा.

Prompt caching मुळे नेहमी खर्च वाचतो का?

नाही. 5 minute cache write साठी base input rate च्या 1.25 पट शुल्क लागते. त्यामुळे लिहिलेला आणि पुन्हा कधीही वाचला न गेलेला prefix तो थेट पाठवण्यापेक्षा 25 percent महाग पडतो. पहिल्या read पासून त्याचा खर्च भरून निघतो. हे दोन प्रकारे अपयशी ठरते आणि दोन्ही वेळा कोणतीही सूचना मिळत नाही. Requests दरम्यान cached prefix बदलल्यास lookup कधीही जुळत नाही, कारण exact prefix match आवश्यक असतो. Prefix model च्या minimum cacheable length पेक्षा लहान असल्यास काहीही cache केले जात नाही आणि कोणताही error परत केला जात नाही. ही मर्यादा Sonnet 5 वर 1,024 tokens आणि Haiku 4.5 वर 4,096 tokens आहे. cache_creation_input_tokens आणि cache_read_input_tokens दोन्ही 0 दाखवत असल्यास cache कोणतेही काम करत नाही.

माझ्या message count पेक्षा bill वेगाने का वाढले?

कारण प्रत्येक turn वेळी संपूर्ण conversation पुन्हा पाठवली जाते. Messages API कोणतीही state ठेवत नाही. त्यामुळे chat मधील turn 20 मध्ये आधीचे सर्व 19 turns पुन्हा input म्हणून पाठवले जातात. प्रत्येक turn मध्ये सरासरी 500 tokens असल्यास, transcript ची लांबी केवळ 10,000 tokens असली तरी 20 turn च्या conversation मध्ये सुमारे 105,000 input tokens पाठवले जातात. Agent loops मध्येही हेच घडते, कारण प्रत्येक tool result history मध्ये राहतो. स्थिर prefix cache करा किंवा जुन्या turns चे summarise करून ते request मधून काढून टाका.