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 यांचे प्रमाण तुमच्या बिलावर अधिक परिणाम करते. एखादा app मोठी documents पाठवून लहान उत्तरे मिळवत असेल, तर त्याचा खर्च लहान prompt पासून मोठी उत्तरे तयार करणाऱ्या app पेक्षा वेगळा असेल.

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

1M tokens चे स्वरूप

Token म्हणजे model वाचतो किंवा लिहितो त्या मजकुराचा एक भाग. Anthropic च्या साधारण मार्गदर्शकानुसार 4 characters मागे 1 token येतो, किंवा इंग्रजीतील सुमारे 0.75 words येतात. त्यामुळे 1M tokens म्हणजे सुमारे 750,000 words, किंवा साध्या 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 वर केलेल्या एका pass इतके, किंवा एका व्यक्तीच्या एका महिन्याच्या मर्यादित chat वापराइतके आहे.

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

दशलक्ष टोकनसाठी 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 पर्यंत प्रारंभिक किंमत लागू आहे: input साठी $2 आणि output साठी $10. 1 September 2026 पासून standard दर लागू होईल: input साठी $3 आणि output साठी $15. Claude Opus 5 ची किंमत input साठी $5 आणि output साठी $25 आहे.

दर बदलू शकतात. या पृष्ठावरील प्रत्येक आकडा August 2026 मधील उदाहरण म्हणून घ्या. बजेटला अंतिम मान्यता देण्यापूर्वी अधिकृत किंमत पृष्ठावर सध्याचे आकडे तपासा.

Context length मुळे दर बदलत नाही. Claude 4.6 आणि त्यानंतरच्या आवृत्त्यांमध्ये पूर्ण 1M token context window साठी standard pricing लागू आहे. त्यामुळे 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 असे output मिळते. 4,300 input tokens पाठवून 400 output tokens मिळवणाऱ्या request ची Sonnet 5 वरील किंमत सुमारे 1.3 cents असते. दोन्ही rates तुमच्या code मध्ये एकाच ठिकाणी ठेवा. किंमत बदलल्यावर तुम्ही दोन ओळी संपादित करता आणि तुमच्या system मधील प्रत्येक estimate त्यानुसार बदलतो.

प्रत्यक्ष अॅपसाठी केलेला अंदाज

समर्थन सहाय्यकाचा विचार करा. त्याचा system prompt आणि उत्पादनाचे दस्तऐवजीकरण मिळून 4,000 tokens होतात. ते प्रत्येक विनंतीसोबत पाठवले जातात, कारण Messages API stateless आहे आणि कॉल्सदरम्यान model काहीही लक्षात ठेवत नाही. वापरकर्त्याच्या प्रश्नामुळे आणखी सुमारे 300 tokens जोडले जातात. उत्तर साधारण 400 tokensचे असते. त्यामुळे प्रत्येक विनंतीसाठी 4,300 input tokens आणि 400 output tokens लागतात.

एक million input tokensमधून या स्वरूपाच्या सुमारे 232 विनंत्या करता येतात. दररोज 1,000 विनंत्या असल्यास अॅप दररोज 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 विनंत्यांचा खर्च $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चा निर्णय, या प्रमाणातील trafficसाठी तुम्ही 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 च्या 1.25 पट असते, तर 1 hour lifetime साठी ती 2 पट असते. त्यामुळे 5 minute cache एका read नंतर स्वतःचा खर्च भरून काढते. कारण write साठी 0.25 अतिरिक्त किंमत लागते आणि प्रत्येक read मध्ये 0.9 ची बचत होते. 1 hour cache ला समतोल साधण्यासाठी दोन read आवश्यक असतात.

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

Prefix पुरेसा लांब असणे आवश्यक आहे. Cache करण्यासाठीची किमान लांबी Opus 5 वर 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 वर cache होत नाही, कारण 4,000 ही त्या model ची किमान मर्यादा 4,096 पेक्षा कमी आहे. दोन्ही counters 0 असल्यास काहीही cache झालेले नाही.

बॅच प्रक्रिया दर अर्धा करते

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

यासाठी latency मध्ये तडजोड करावी लागते. त्यामुळे एखादी व्यक्ती बसून निकालाची वाट पाहत असेल अशा कोणत्याही कामासाठी batch योग्य नाही. ते रात्रभर चालणाऱ्या classification आणि document backfills साठी योग्य आहे.

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

API कोणतीही स्थिती जतन करत नाही. त्यामुळे तुमचा client प्रत्येक turn वेळी संपूर्ण संभाषण पुन्हा पाठवतो. म्हणून, एका chat मधील token वापर त्याच्या लांबीच्या वर्गानुसार वाढतो; तो सरळ प्रमाणात वाढत नाही.

सरासरी 500 tokens असलेले turns गृहीत धरा. Turn 1 मध्ये 500 input tokens पाठवले जातात. Turn 2 मध्ये 1,000. Turn 20 मध्ये 10,000. यांची बेरीज n(n+1)/2 नुसार केल्यास, 20 turns असलेल्या संभाषणात सुमारे 105,000 input tokens पाठवले जातात; मात्र transcript स्वतः फक्त 10,000 tokens इतका असतो.

म्हणूनच chat feature चा खर्च त्याच्या transcript वरून दिसणाऱ्या खर्चापेक्षा जास्त असतो. दीर्घ threads मध्ये स्थिर prefix चे caching करणे किंवा जुन्या turns चा सारांश तयार करणे खर्च कमी करते. Tool calls वर loop करणाऱ्या agent मध्येही हीच रचना असते, आणि ती आणखी खर्चिक असते: प्रत्येक tool result history मध्ये राहतो आणि त्यानंतरच्या प्रत्येक turn वेळी पुन्हा पाठवला जातो. तुम्ही स्वतः चालवता त्या agent साठी कठोर खर्चमर्यादा ठरवणे येथे सर्वाधिक महत्त्वाचे आहे, कारण ही वाढ आपोआप होते आणि तिच्यावर लक्ष ठेवणारे कोणीही नसते.

अंदाज करण्यापूर्वी टोकन मोजा

शब्दसंख्येवरून टोकनची संख्या काढणे थांबवा. API तुमच्यासाठी ही संख्या विनामूल्य मोजते. यासाठी संदेश तयार करण्यापेक्षा स्वतंत्र 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"
    }]
  }'

प्रतिसादामध्ये एक field असते:

{ "input_tokens": 14 }

तुमचा प्रत्यक्ष system prompt आणि tool definitions, तसेच प्रतिनिधिक user message, यामध्ये द्या. त्यानंतर ही संख्या वरील cost function मध्ये वापरा. या endpoint साठी message request प्रमाणेच body वापरली जाते. त्यामुळे images आणि PDFs यांचीही अचूक गणना होते. दोन बाबी लक्षात ठेवा. ही संख्या अंदाजे असते आणि billed figure पेक्षा थोडी वेगळी असू शकते. तसेच, मोजणी तुम्ही पाठवलेल्या model च्या tokenizer ने केली जाते. त्यामुळे प्रत्यक्ष वापरणार असलेला model पाठवा.

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

बिलावर आणखी काय आकारले जाते

बहुतेक बिल token मुळे बनते. काही घटक token नसतात आणि ते अनेकांना अनपेक्षित वाटतात.

• प्रत्येक 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 आणि writes यांचाही त्यात समावेश होतो.

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

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 आहे. या प्रत्येक 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 असतात. त्यामुळे one million tokens म्हणजे अंदाजे 750,000 words असतात. हे प्रमाण केवळ मार्गदर्शक आहे. Code, JSON आणि English व्यतिरिक्त इतर languages मध्ये प्रत्येक word साठी अधिक tokens लागतात. Claude Opus 4.7 आणि त्यानंतरच्या versions मध्ये नवीन tokenizer वापरला जातो. त्यामुळे Claude Sonnet 4.6 आणि त्यापूर्वीच्या versions मधील समान text पेक्षा साधारण 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 जुळत नाही, कारण तो 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 काहीही करत नाही.

माझ्या messages ची संख्या वाढली त्यापेक्षा 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 मध्ये राहतो. Stable prefix cache करा किंवा जुन्या turns चा सारांश तयार करून ते request मधून काढून टाका.