| सामान्य input tokens, जिन्हें cache write/read के रूप में नहीं गिना गया है। |
| Output tokens | $25 / MTok | Claude के जवाब में generated tokens। |
| Prompt cache write, 5 मिनट TTL | $6.25 / MTok | reusable prompt cache पहली बार लिखने पर, 5 मिनट TTL के साथ। |
| Prompt cache write, 1 घंटा TTL | $10 / MTok | reusable prompt cache पहली बार लिखने पर, 1 घंटे TTL के साथ। |
| Cache read / hit | $0.50 / MTok | पहले से cached content पढ़ने यानी cache hit पर। |
सीधा निष्कर्ष: total tokens को एक average rate से multiply करना सुरक्षित तरीका नहीं है। अगर आपकी app में prompt caching है, तो input, output, cache write और cache read को अलग-अलग line items की तरह रखें।
Basic formula:
cost = input_tokens ÷ 10,00,000 × 5 + output_tokens ÷ 10,00,000 × 25
उदाहरण के लिए, किसी request में 2,00,000 input tokens और 20,000 output tokens हैं, तो बिना cache के खर्च होगा: $1.00 + $0.50 = $1.50
Cache के साथ formula को थोड़ा विस्तार देना होगा:
cost = base_input_tokens ÷ 10,00,000 × 5 + output_tokens ÷ 10,00,000 × 25 + cache_write_5m_tokens ÷ 10,00,000 × 6.25 + cache_write_1h_tokens ÷ 10,00,000 × 10 + cache_read_input_tokens ÷ 10,00,000 × 0.50
अगर आप सिर्फ 5 मिनट या सिर्फ 1 घंटे वाली TTL इस्तेमाल कर रहे हैं, तो उसी cache write component को रखें। Anthropic के streaming examples में usage के अंदर input_tokens, output_tokens, cache_creation_input_tokens और cache_read_input_tokens जैसे fields दिखते हैं; pricing docs भी cache write और cache hit को अलग-अलग rate देती हैं।
API cost का अनुमान लगाने के लिए Hindi/English शब्दों की गिनती या character count पर भरोसा न करें। Anthropic का /v1/messages/count_tokens endpoint message भेजने से पहले token count निकालने के लिए बना है। Documentation के अनुसार यह Messages API जैसी structured input स्वीकार करता है, जिसमें system prompts, tools, images और PDFs तक शामिल हो सकते हैं, और response में total input tokens देता है। सभी active models token counting support करते हैं।
व्यावहारिक तरीका यह है: जो payload असल में Messages API को भेजना है, वही payload पहले count_tokens को भेजें। इसमें system prompt, user/assistant messages, tool definitions, images या PDF blocks सब शामिल करें। इससे model call करने से पहले input token cost का बेहतर अंदाजा मिलता है और product में budget limit या warning लगाना आसान होता है।
usage से करेंRequest complete होने के बाद output text की length देखकर अनुमान लगाने के बजाय response के usage fields log करें। Anthropic के Messages API examples में response usage के अंदर input_tokens और output_tokens जैसे fields दिखते हैं; streaming docs cache-related fields जैसे cache_creation_input_tokens और cache_read_input_tokens भी दिखाती हैं।
Streaming इस्तेमाल कर रहे हैं तो एक आम गलती से बचें: Anthropic docs के अनुसार message_delta event में आने वाले usage token counts cumulative होते हैं, यानी हर event का नया increment नहीं। अगर आप हर delta को जोड़ते चले गए, तो वही tokens बार-बार count हो सकते हैं।
Per-request logs real-time monitoring के लिए अच्छे हैं, लेकिन team billing, workspace-level split या लंबे समय की cost analysis के लिए Anthropic का Usage & Cost Admin API ज्यादा उपयुक्त है। Official docs के अनुसार यह API organization के historical API usage और cost data तक programmatic, granular access देता है, और usage report को model, workspace तथा service tier जैसे dimensions से तोड़ा जा सकता है।
इसका practical अर्थ है: app-side logs से per-request guardrails और alerts बनाएं, लेकिन official reconciliation के लिए Usage & Cost Admin API के historical usage/cost data को आधार बनाएं।
Opus 4.7 में नया tokenizer आया है। Anthropic docs के अनुसार text processing में यह previous models की तुलना में लगभग 1x से 1.35x tokens इस्तेमाल कर सकता है, यानी content के हिसाब से लगभग 35% तक अधिक tokens; इसी वजह से /v1/messages/count_tokens Opus 4.7 और Opus 4.6 के लिए अलग token numbers लौटा सकता है।
इसलिए $5 input और $25 output प्रति MTok की sticker price वही दिखने पर भी आपका वास्तविक bill वैसा ही रहेगा, यह मान लेना ठीक नहीं। अगर आप Opus 4.6 या उससे पुराने Claude model से Opus 4.7 पर जा रहे हैं, तो high-traffic prompts, लंबे context वाले workflows, tool definitions वाले payloads और सबसे महंगे production flows को फिर से /v1/messages/count_tokens पर चलाएं। इसके बाद alerts, rate limits और cost caps update करें।
claude-opus-4-7 ही इस्तेमाल हो रहा है, यह confirm करें।/v1/messages/count_tokens चलाएं।input_tokens, output_tokens, cache write और cache read को अलग-अलग store करें; सिर्फ total token count न रखें।message_delta.usage cumulative है, इसलिए हर event को जोड़कर double-counting न करें।संक्षेप में: Claude Opus 4.7 की basic API rate याद रखना आसान है—input $5/MTok और output $25/MTok। लेकिन सही बिलिंग के लिए request से पहले count_tokens, request के बाद usage, और cost model में prompt caching व नए tokenizer—तीनों को साथ रखना जरूरी है।