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 चा दर input दराच्या पाचपट आहे. त्यामुळे headline figure पेक्षा input आणि output यांचे प्रमाण तुमच्या बिलावर अधिक परिणाम करते. लांब documents पाठवून लहान उत्तरे देणारे app आणि छोट्या prompt वरून लांब उत्तरे लिहिणारे app यांचा खर्च खूप वेगळा असतो.

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

1M tokens कसे दिसतात

token म्हणजे model वाचतो किंवा लिहितो तो मजकुराचा एक भाग. Anthropic च्या साधारण मार्गदर्शकानुसार प्रत्येक 4 characters मागे 1 token असतो, म्हणजे इंग्रजीतील सुमारे 0.75 words. त्यामुळे 1M tokens म्हणजे अंदाजे 750,000 words किंवा plain text चे साधारण 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 व्यतिरिक्त इतर भाषांमधील text मध्ये एका token मध्ये कमी words येतात. त्यामुळे 0.75 हे प्रमाण आशावादी टोकाचे आहे. आणखी एक घटक count बदलतो: Opus 5 आणि Sonnet 5 यांसह Claude Opus 4.7 आणि त्यानंतरच्या versions मध्ये नवीन tokenizer वापरला जातो. तो Sonnet 4.6 आणि त्याआधीच्या versions पेक्षा त्याच text साठी साधारण 30 percent अधिक tokens तयार करतो. Claude Haiku 4.5 मध्ये जुना tokenizer वापरला जातो. त्यामुळे Haiku 4.5 वर मोजलेला count समान input साठी Sonnet 5 वरील count पेक्षा कमी असेल. याचा अर्थ या दोन्ही tokenizer versions च्या सीमारेषेवर थेट price-per-million तुलना योग्य नाही. निर्णय घेण्यापूर्वी तोच prompt दोन्ही models विरुद्ध मोजा.

दशलक्ष tokens मागे Claude चे शुल्क

[
  {
    "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 रोजी तयार केलेले उदाहरण समजा. बजेट निश्चित करण्यापूर्वी अधिकृत pricing page वर सध्याचे आकडे पडताळा.

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

ही गणना चालवता येणाऱ्या कोडच्या स्वरूपात:

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 परत मिळवणाऱ्या विनंतीची किंमत Sonnet 5 वर सुमारे 1.3 cents असते. दोन्ही दर तुमच्या कोडमध्ये एकाच ठिकाणी ठेवा. किंमत बदलल्यावर दोन ओळी संपादित करा. त्यानंतर तुमच्या प्रणालीतील प्रत्येक अंदाज त्यानुसार बदलेल.

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

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

1M 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 दरमहा आहे. या प्रमाणातील traffic साठी तुमची model निवड आणि caching चा निर्णय, तुम्ही negotiate करू शकणाऱ्या कोणत्याही दरापेक्षा अधिक महत्त्वाचे आहेत. कोणते model वापरायचे हा स्वतंत्र प्रश्न आहे. तुमच्या evaluations मध्ये यशस्वी ठरणारे सर्वात स्वस्त model निवडा: Opus, Sonnet आणि Haiku यांच्यात निवड हे योग्य प्रकारे चाचणी कशी करायची ते स्पष्ट करते.

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

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

Cache read साठी base input rate च्या 0.1 पट खर्च येतो. 5 minute lifetime साठी cache लिहिण्याचा खर्च base च्या 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 वाचून केलेला खर्चाचा अंदाज caching सुरू झाल्यानंतर मोठ्या प्रमाणात चुकीचा ठरेल.

दोन गोष्टी cache ला खर्च भरून काढू देत नाहीत आणि दोन्ही प्रकरणांत कोणतीही error नोंदवली जात नाही.

Prefix byte-identical असणे आवश्यक आहे. Cache lookup हा prefix match वर आधारित असतो. त्यामुळे system prompt च्या सुरुवातीला timestamp किंवा user's name ठेवल्यास तो प्रत्येक विनंतीमध्ये बदलतो. त्यानंतर प्रत्येक वेळी base input च्या 1.25 पट खर्च येतो आणि एकदाही read होत नाही. याचे लक्षण म्हणजे cache_creation_input_tokens उच्च राहते, तर cache_read_input_tokens 0 राहते. विनंत्यांमध्ये ज्याचा content समान असतो त्या शेवटच्या block वर cache_control ठेवा आणि बदलणारा सर्व content त्यानंतर ठेवा. तुमच्या 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 सोबत लागू होतो. त्यामुळे मोठ्या प्रमाणातील कामासाठी 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 साठी कठोर खर्च मर्यादा लागू करणे येथे सर्वाधिक महत्त्वाचे आहे, कारण ही वाढ आपोआप होते आणि तिचे निरीक्षण कोणी करत नसते.

अंदाज लावण्यापूर्वी 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 पेक्षा थोडी वेगळी असू शकते. तसेच मोजणी तुम्ही pass केलेल्या model च्या tokenizer ने केली जाते. म्हणून प्रत्यक्षात चालवणार असलेला model pass करा.

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 इतकेच आहेत का?

नाही. एक token म्हणजे English मधील साधारण 4 characters किंवा सुमारे 0.75 words असतात. त्यामुळे 1M tokens म्हणजे साधारण 750,000 words असतात. हा ratio केवळ अंदाजासाठी आहे. 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 पुन्हा कधीही read केला नाही, तर तो साध्या पद्धतीने पाठवण्यापेक्षा 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 चा सारांश तयार करून ते request मधून काढून टाका.