Claude tokens क्या हैं? Claude Code का token हिसाब

Claude में tokens क्या होते हैं?

Token उस text की इकाई है जिसे Claude पढ़ता और लिखता है। यह किसी word का एक fragment होता है। Anthropic की अपनी glossary के अनुसार, Claude Opus 4.7 से पहले के models में 1 token लगभग 3.5 English characters के बराबर होता है। Current tokenizer में यह अनुपात करीब 2.5 characters है, क्योंकि Anthropic वहां 1M tokens को लगभग 2.5M characters के बराबर मानता है। दोनों मामलों में spaces और punctuation शामिल करने पर प्रति word 1 से काफी अधिक tokens बनते हैं। इसलिए prose के 1,000 words में आसानी से 1,300 से अधिक tokens हो सकते हैं। Code में प्रति line tokens और अधिक होते हैं। Braces, operators, underscores और indentation, English text की तुलना में, प्रति character अधिक tokens में विभाजित होते हैं। कुछ सौ lines की source file में आम तौर पर कई हजार tokens होते हैं। यदि agent 2,000-line file पढ़ने का निर्णय लेता है, तो नई code की एक line लिखे जाने से पहले ही उस पर five-figure tokens खर्च हो सकते हैं।

Tokenizers के बारे में दो बातें अक्सर भ्रम पैदा करती हैं। पहली, tokenizer model-specific होते हैं। October 2026 तक Claude Opus 4.7 और इसके बाद के सभी models, जिनमें current Fable 5.1, Opus 5.5, Sonnet 5.5 और Haiku 5.5 शामिल हैं, एक नया tokenizer इस्तेमाल करते हैं। यह पहले के Claude models, जैसे Haiku 4.5, की तुलना में उसी text के लिए लगभग 30% अधिक tokens बनाता है। Exact increase content के अनुसार बदलता है। इससे tokens में बनाई गई कोई भी budget calculation बदल जाती है, भले ही per-token prices इसके कारण नहीं बढ़े हों। दूसरी, tiktoken वह library है जिसे हर blog post इस्तेमाल करता है, लेकिन यह Claude का नहीं, OpenAI का tokenizer है। इसलिए इसकी counts, Anthropic द्वारा bill की जाने वाली counts से मेल नहीं खाएंगी। भरोसेमंद count केवल count_tokens endpoint से मिलती है, जिसे नीचे बताया गया है.

आपका coding session जितना खर्चीला है, उसकी वजह

हर Claude bill, चाहे वह API invoice हो या subscription limit, मुख्य रूप से एक ही meter पर चलता है: आने वाले tokens और बाहर जाने वाले tokens। कुछ API tools अपनी अलग line जोड़ते हैं। उदाहरण के लिए, October 2026 तक web search की लागत 1,000 searches पर $10 है। इसके अतिरिक्त, उसके results से जुड़ने वाले tokens की लागत भी लगती है। लेकिन coding session में मुख्य रूप से token meter ही चलता है। Pricing page इसे सरल दिखाता है: प्रति million input tokens इतनी dollars और प्रति million output tokens इतनी dollars। इसमें यह स्पष्ट नहीं होता कि agentic coding session में meter का input पक्ष आपकी सहज धारणा से कहीं अधिक तेजी से बढ़ता है, क्योंकि हर turn पर पूरी conversation फिर से भेजी जाती है। मैंने पंद्रह वर्षों तक metered infrastructure बेचा है। Tokens पहला ऐसा meter है जिसे मैंने देखा है, जिसके बढ़ने का वास्तविक कारण अधिकांश customers बता ही नहीं सकते। यह meter पढ़ने का पाठ है: agentic session में input और output में क्या गिना जाता है, resend loop इतना महँगा क्यों है, prompt caching गणना को कैसे बदलता है, और कौन-से levers वास्तव में इस संख्या को बदलते हैं।

हर चीज़ input है: meter वास्तव में क्या गिनता है

लोग मानते हैं कि वे Claude द्वारा लिखे गए code के लिए भुगतान करते हैं। Agentic session में यह छोटी लागत होती है। Input tokens की दर कम होती है, लेकिन उनकी मात्रा बहुत अधिक होती है। इनमें शामिल हैं:

• System prompt। Claude Code के अपने harness निर्देश, साथ ही आपके CLAUDE.md और memory files, session शुरू होने पर load होते हैं और उसके बाद हर request में मौजूद रहते हैं।
• Tool definitions। Agent जिन tools को call कर सकता है, उन सभी के schema। आपके द्वारा connect किया गया प्रत्येक MCP server इस fixed overhead को बढ़ाता है। हालांकि Claude Code अब default रूप से full MCP tool definitions को defer करता है। इसलिए किसी tool के पहली बार उपयोग होने तक context में केवल tool names रहते हैं। इससे लागत घटती है, लेकिन समाप्त नहीं होती।
• Agent द्वारा पढ़ी गई हर file। किसी source file का Read पूरे file को context में डालता है और वह वहीं बना रहता है।
• हर tool result। Test runs, grep output, terminal output और build logs, ये सभी input tokens के रूप में वापस आते हैं। यदि failing test suite 8,000 lines print करता है, तो वह एक छोटी book के बराबर है। October 2026 तक Claude Code default रूप से command output के लगभग 30,000 characters inline पास करता है। इससे लंबा output saved file और अधिकतम 2,000 characters के preview के रूप में आता है। लेकिन इस सीमा से कम का हर output और saved file को बाद में पढ़ना, दोनों की पूरी billing होती है।
• अब तक की पूरी conversation, जिसे हर turn पर फिर से भेजा जाता है। इसके लिए अलग section आवश्यक है।

Resend की कीमत कोई नहीं बताता

Claude API stateless है। यह requests के बीच आपका session याद नहीं रखता; वास्तव में कोई भी चीज़ ऐसा नहीं करती। इसलिए turn 2 पर client turn 1, उसका response और आपका नया message भेजता है। turn 50 पर यह turns 1 से 49 तक context में बची हर चीज़ फिर से भेजता है—हर पढ़ी गई file, हर tool result और हर diff जिसे compact नहीं किया गया है—और इसके साथ turn 50 भी भेजता है। (Compaction पुरानी history को summary से बदल देता है। किसी subagent द्वारा पढ़ी गई files उसके अपने context में रहती हैं और केवल उसका result वापस आता है।) Model हर बार retained transcript को फिर से पढ़ता है, और इन दोबारा पढ़े गए हर token का input के रूप में billing होती है।

इसका परिणाम यह है कि हर turn की cost session की length के साथ लगभग linear रूप से बढ़ती है, जबकि पूरे session की total cost लगभग quadratic रूप से बढ़ती है। turn 3 पर आधे cent की cost वाला message turn 60 पर उसी one-line question के लिए उससे 20 गुना महँगा हो सकता है, क्योंकि उसमें 60 turns का पूरा भार शामिल होता है। यही वह एक तथ्य है जो अधिकांश “मेरा bill इतना अधिक क्यों आया” tickets को समझाता है। यह Claude की कोई विशेष समस्या नहीं है; हर stateful जैसा महसूस होने वाला LLM product वास्तव में नीचे से stateless API होता है, जिसके पीछे resend loop चलता है।

आउटपुट: जो आप देखते हैं, और वह सोच भी जो दिखाई नहीं देती

आउटपुट tokens महंगे हैं। मौजूदा lineup में इनकी कीमत input rate से पाँच गुना है ($10/$50 on Fable 5.1, $4/$20 on Opus 5.5, $2/$10 on Sonnet 5.5, $0.10/$0.50 on Haiku 5.5 for prompts up to 100,000 tokens, as of October 2026)। आउटपुट में Claude द्वारा generate किया गया text और code, तथा thinking tokens शामिल होते हैं। ये वे internal reasoning tokens हैं, जिन्हें model उत्तर देने से पहले process करता है। दो बातें महत्वपूर्ण हैं। Thinking की billing output rates पर होती है और यह max_tokens में count होता है। stop_reason: "max_tokens" के साथ समाप्त होने वाली API response और truncated answer का अक्सर अर्थ होता है कि उत्तर पूरा होने से पहले thinking ने budget consume कर लिया। मौजूदा models में reasoning summary दिखाई भी नहीं दे सकती। API इसे Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5 और Opus 4.7 तक के पुराने models पर default रूप से omit करती है। फिर भी thinking हुई और उसकी billing भी हुई। Invisible का अर्थ free नहीं है।

Claude Code extended thinking को default रूप से enable करता है, क्योंकि इससे multi-step work में मापने योग्य सुधार होता है। Default budget प्रत्येक request पर tens of thousands of tokens तक जा सकता है। सरल tasks में आप इसे कम कर सकते हैं। /effort के साथ या /model में effort level कम करें। जिन models में इसकी अनुमति है, उनमें /config से thinking बंद करें। October 2026 तक Claude Code Opus 5.5, Sonnet 5.5, Haiku 5.5 या Fable models पर thinking बंद नहीं कर सकता। इसलिए वहाँ effort ही नियंत्रण का माध्यम है। API इनमें से दो models पर अधिक विकल्प देती है। Haiku 5.5 high effort या उससे कम पर thinking: {"type": "disabled"} स्वीकार करता है। पुराना Opus 5 भी ऐसा ही करता है। पुराना Sonnet 5 हर effort level पर इसे स्वीकार करता है, जिसमें xhigh और max भी शामिल हैं। Sonnet 5.5 "disabled" अस्वीकार करता है और इसके बजाय thinking: {"type": "between_tools"} लेता है। low, medium या high effort पर इससे प्रारंभिक thinking कम हो जाती है। इसलिए tools के बिना request को पहले thinking किए बिना उत्तर मिल जाता है। केवल Opus 5.5 और Fable models आपके भेजे गए किसी भी input पर thinking बनाए रखते हैं। यह वास्तविक cost lever है, अंधविश्वास नहीं।

Prompt caching से गणित बदल जाता है

Prompt caching के कारण resend loop सबको दिवालिया नहीं करता। API आपके prompt, system prompt, tool definitions और conversation history के स्थिर prefix को cache कर सकता है। अगली request पर इसे लागत के एक छोटे अंश में serve किया जा सकता है। October 2026 तक multipliers ये हैं: cache write की लागत base input rate की 1.25× है (1-hour variant के लिए 2×), और cache read की लागत अधिकांश models पर 0.1×, Claude Opus 5.5 और Claude Sonnet 5.5 पर 0.05×, तथा Claude Fable 5.1 पर 0.025× है। Writes पर premium लगता है; reads अधिकांश models पर 90% की छूट, Opus 5.5 और Sonnet 5.5 पर 95% की छूट, तथा Fable 5.1 पर 97.5% की छूट देते हैं। (Sonnet 5.5 की read rate October 7, 2026 को 0.1× से घटाकर 0.05× की गई थी।) एक read ही 5-minute write premium की भरपाई से अधिक कर देता है।

Claude Code आपके लिए caching manage करता है। स्वस्थ session में उस बड़े resend का लगभग पूरा हिस्सा cache से serve होता है। लेकिन कुछ समय तक inactivity रहने पर cache expire हो जाता है। October 2026 तक Claude Code subscription पर आपकी plan की included usage के भीतर main conversation के लिए one-hour cache देता है। API key, cloud provider या usage credits से खर्च होने पर last use के बाद five minutes का cache मिलता है। वहाँ promptCacheTtl setting hour की अवधि मांग सकती है, लेकिन write rate 2× होगी। Five-minute cache में यदि आप लंबे समय तक coffee break पर चले जाते हैं, लौटकर message भेजते हैं, तो cache expire हो चुका होता है। पूरा accumulated prefix cache rate पर read होने के बजाय 1.25× पर फिर से write होता है। 150K-token session में एक cold turn सभी 150K tokens को 1.25× पर write करता है। Warm turn में वही tokens 0.1× पर read होते। इसलिए prefix पर 12.5-fold अंतर होता है (Opus 5.5 और Sonnet 5.5 पर 25-fold, Fable 5.1 पर 50-fold)। यही counterintuitive परिणाम ध्यान में रखना चाहिए: idle होकर फिर resume करने की लय continuous work से अधिक महँगी हो सकती है, क्योंकि TTL से अधिक लंबे हर idle gap के बाद अगला turn सस्ते read के बजाय महँगे re-write में बदल जाता है। काम को stints में करें। Five-minute cache पर बड़ी session को हर दस मिनट में एक message भेजकर धीरे-धीरे न चलाएँ।

यदि आप अपने VPS पर application से API call कर रहे हैं, तो इनमें से कुछ भी अपने-आप नहीं होता। आपको cache_control से opt in करना पड़ता है। इसमें होने वाली सामान्य self-inflicted गलती यह है कि system prompt में timestamp या request ID interpolate कर दी जाती है। इससे हर request पर prefix bytes बदल जाते हैं और caching चुपचाप disable हो जाती है। इसका संकेत यह है कि एक जैसी दिखने वाली calls में usage.cache_read_input_tokens लगातार zero पर रहता है।

फ़ॉर्मूला, एक उदाहरण के साथ

जो लोग यह कहते हैं कि "एक session की लागत $X होती है", उनकी बात को आधार न मानें। Sessions की लागत में 100 गुना तक अंतर हो सकता है। मान्य बात यह formula है:

turn cost = (uncached input        x base input price)
          + (cache writes          x 1.25 x base input price)
          + (cache reads           x read multiplier x base input price)
          + (output incl. thinking x output price)

read multiplier = 0.10 on most models, 0.05 on Opus 5.5 and Sonnet 5.5, 0.025 on Fable 5.1
session cost = sum over all turns

Claude Opus 4.8 पर worked example। यह अब legacy model है, लेकिन अभी भी उपलब्ध है और October 2026 तक इसकी कीमत input tokens के लिए $5 प्रति million और output tokens के लिए $25 प्रति million है। किसी session के बीच का एक turn, जिसमें कुल context के 80,000 tokens हैं: 75,000 cache से पढ़े गए, 3,000 नए tokens cache में लिखे गए, 2,000 uncached fresh input tokens हैं और thinking सहित 1,500 output tokens हैं।

• Cache reads: 75,000 × $0.50/M = $0.0375
• Cache writes: 3,000 × $6.25/M = $0.019
• Uncached input: 2,000 × $5/M = $0.010
• Output: 1,500 × $25/M = $0.0375

इस turn की लागत लगभग $0.10 है; ऐसे 50 turns की लागत लगभग $5 होगी। अब cache expire होने के बाद उसी turn को देखें: 78,000 cacheable tokens को $6.25/M की दर से फिर से लिखना होगा। इसमें वही 2,000 uncached tokens $5/M की दर से जोड़ने पर output से पहले लागत लगभग $0.50 होती है। यह पूरे warm turn की लागत से लगभग पांच गुना है, जबकि काम समान है। एक ही संख्या में caching का पूरा प्रभाव दिख जाता है। मौजूदा Claude Opus 5.5 ($4/$20, जिसमें cache reads की दर 0.05× है) पर वही warm turn लगभग $0.07 का पड़ेगा (reads $0.015, writes $0.015, uncached input $0.008, output $0.030)। Cold version की लागत output से पहले $0.40 होगी, यानी warm turn से लगभग छह गुना अधिक। Vendors की तुलना करने का ईमानदार तरीका भी यही चार lines हैं, क्योंकि sticker rates cache reads और thinking को पूरी तरह अनदेखा करते हैं। इन्हें तीन वास्तविक jobs पर चलाने से पता चलता है कि Claude का bill OpenAI वाले bill से अधिक या कम कहाँ आता है।

यदि आप किसी एक turn के बजाय स्वयं billing unit को समझना चाहते हैं, तो एक million tokens pages, files और dollars में कितने होते हैं यह वही arithmetic एक स्तर ऊपर लागू करता है। Prediction के बजाय calibration के लिए: October 2026 तक Anthropic द्वारा प्रकाशित enterprise Claude Code deployments के आंकड़ों के अनुसार, औसत लागत प्रति developer प्रति active day लगभग $13 और प्रति month $150 से $250 है। 90% users की दैनिक लागत $30 से कम रहती है। आपकी वास्तविक लागत model choice, session hygiene और codebase size पर निर्भर करती है। इसी कारण नीचे दिए गए levers महत्वपूर्ण हैं।

अपना उपयोग देखना

Claude Code में command /usage है (/cost अभी भी काम करता है, यह एक alias है)। सबसे ऊपर मौजूद Session block वर्तमान session के token statistics और स्थानीय रूप से गणना किया गया cost estimate दिखाता है। Subscription plans पर यही screen आपके plan-limit bars भी दिखाती है और हाल के उपयोग को skills, subagents, plugins और अलग-अलग MCP servers से जोड़कर उसका विवरण देती है। हाल के versions में Session block में Prompt cache (main) line भी होती है। इसमें cache से serve किए गए input का अनुपात, cache misses और इस समय cache warm है या नहीं, दिखता है। API accounts के लिए authoritative billing source Claude Console का usage page है; CLI figure केवल एक estimate है। /context एक colored grid दिखाता है, जिसमें context window में क्या जगह ले रहा है, system prompt, tools, MCP definitions, files और history दिखाई देते हैं। यह bloated CLAUDE.md या बहुत अधिक संदेश भेजने वाले MCP server का पता लगाने का सबसे तेज तरीका है। Fullscreen mode में per-item breakdown संक्षिप्त हो जाता है। all देने पर यह breakdown विस्तृत हो जाता है।

API से मिलने वाला हर response ठीक-ठीक बताता है कि क्या हुआ:

response = client.messages.create(model="claude-sonnet-5-5", max_tokens=2048,
                                  messages=messages)
u = response.usage
total_prompt = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
print(f"uncached={u.input_tokens} written={u.cache_creation_input_tokens} "
      f"read={u.cache_read_input_tokens} output={u.output_tokens}")

ध्यान रखें कि input_tokens केवल uncached remainder है। वास्तविक prompt size इन तीनों input fields के योग के बराबर होता है। एक घंटे तक चलने वाला agent यदि input_tokens: 4000 दिखा रहा है, तो इसका अर्थ यह नहीं कि वह सस्ता है; बाकी 200,000 tokens cache से serve किए गए थे। Request भेजने से पहले अनुमान लगाने के लिए token-counting endpoint का उपयोग करें। इसे call करना free है, यह अपनी अलग rate limit पर चलता है और आपके द्वारा बताए गए model के tokenizer से count करता है। परिणाम को निकटतम estimate मानें; billing वास्तविक request पर आधारित होती है:

count = client.messages.count_tokens(model="claude-sonnet-5-5",
                                     messages=[{"role": "user", "content": big_file}])
print(count.input_tokens)

ऊपर बताए गए कारण से कभी भी tiktoken न करें।

सदस्यता योजनाएँ बनाम pay-as-you-go

इस गाइड की कार्यप्रणाली हर जगह समान है; केवल billing का तरीका अलग है। API key के साथ Anthropic pay-as-you-go billing करता है और प्रकाशित दरों के अनुसार प्रति token शुल्क लेता है। ऊपर दी गई हर संख्या वास्तविक खर्च दर्शाती है। यह meter अधिकांश लोगों की अपेक्षा से पहले शुरू हो जाता है, क्योंकि fallback के लिए कोई free tier नहीं है। केवल signup के समय मिलने वाला छोटा credit और कुछ ऐसे endpoints हैं जिन पर कोई शुल्क नहीं लगता। यही वह सुविधा है जो card दर्ज करने से पहले नए API account को वास्तव में मिलती है। 7 October, 2026 से एक अपवाद है: Max या Team subscription। इन plans में अब Claude Platform पर आपके अपने apps और agents के लिए monthly API credits शामिल हैं। Max 5x पर $100 प्रति माह, Max 20x पर $200 प्रति माह, और Team पर प्रत्येक Standard seat के लिए $20 तथा प्रत्येक Premium seat के लिए $100 मिलता है। यह credit pooled है और इसकी अधिकतम सीमा $500 है। इन्हें प्राप्त करने के लिए Console organization link करें। उपयोग न किए गए credits प्रत्येक billing cycle के अंत में expire हो जाते हैं। ये interactive Claude Code को cover नहीं करते।

Claude subscription (Pro, Max, Team और legacy seat-based Enterprise plans) पर Claude Code का usage इसके बजाय आपके plan में शामिल allowance से घटता है। October 2026 तक यह shared rolling five-hour session window और weekly window है। यह allowance models और claude.ai chat के बीच साझा होता है। /usage dollar figure केवल जानकारी के लिए है, bill नहीं। October 2026 तक दो अपवाद हैं। वर्तमान usage-based Enterprise seats में कोई usage शामिल नहीं है, इसलिए हर token पर standard API rates के अनुसार billing होती है। Pro, standard Team seats या standard legacy Enterprise seats में Fable models allowance में शामिल नहीं हैं। वहाँ वे pay-as-you-go usage credits पर चलते हैं।

कोई window पूरी तरह उपयोग हो जाने पर आपको reset time के साथ "You've hit your session limit" या "You've hit your weekly limit" दिखाई देगा। /model से model बदलने पर access वापस नहीं मिलेगा, क्योंकि windows सभी models के बीच साझा होती हैं। ये windows उस account से जुड़ी होती हैं जिसमें आप काम कर रहे हैं, न कि उस client से जिसमें आप उस समय मौजूद हैं। इसलिए यह जानना उपयोगी है कि Linux पर मूल रूप से क्या चलता है और कौन-सा plan किस surface को cover करता है। आपने वास्तव में कौन-सी window समाप्त की है, इससे तय होता है कि कितना इंतजार करना होगा और इस बीच क्या करना उपयोगी होगा। इसलिए बीच में limit आने पर आपके विकल्प क्या हैं यह जानना उपयोगी है। Plans में वैकल्पिक रूप से usage credits enable किए जा सकते हैं। इन्हें /usage-credits से manage करके ceiling के बाद usage खरीदा जा सकता है।

मैं जानबूझकर plan quotas नहीं दे रहा हूँ। इस पूरे विषय में ये सबसे तेजी से बदलने वाली संख्याएँ हैं। इसलिए claude.com/pricing और अपने /usage bars देखें। Subscription पर भी token mechanics महत्वपूर्ण रहती है। अनावश्यक usage आपकी window को उसी तरह खर्च करता है जैसे वह dollars खर्च करता। Subscription वाले हिस्से के लिए देखें: आपके usage के लिए कौन-सा Claude plan उपयुक्त है.

वास्तव में काम करने वाले उपाय

• Agent द्वारा पढ़ी जाने वाली सामग्री का दायरा सीमित करें। "auth.py में validation bug ठीक करें" कहने पर एक file पढ़ी जाती है; "इस codebase को बेहतर बनाएँ" कहने पर चालीस files पढ़ी जाती हैं। CLAUDE.md को संक्षिप्त रखें। यह हर session में load होता है, इसलिए इसमें केवल आवश्यक बातें रखें और workflow-विशिष्ट instructions को उन skills में रखें जो आवश्यकता होने पर load हों।
• स्पष्ट और संक्षिप्त रखें। असंबंधित tasks के बीच /clear करें। इसके बाद पुराना context हर अगले message के साथ दोबारा भेजा और फिर से charge किया जाता है। एक लंबे task के दौरान /compact Focus on the failing tests and the diff history को संक्षेप में रखता है और आपको quadratic curve से दूर रखता है।
• Model का आकार काम के अनुसार चुनें। अधिकांश coding के लिए Sonnet पर्याप्त है और October 2026 तक इसकी कीमत प्रति million tokens $2/$10 है। अब यह introductory price नहीं, बल्कि standard price है: Sonnet 5.5 की कीमत $2/$10 है और Sonnet 5 में भी $2/$10 ही रहा, क्योंकि 1 September की नियोजित बढ़ोतरी $3/$15 रद्द कर दी गई। इसकी तुलना Opus 5.5 के $4/$20 से करें। Haiku 5.5 की कीमत $0.10/$0.50 है; 100,000 tokens तक के prompts के लिए यह दर लागू है और उसके ऊपर $0.50/$2.50 है। Log triage जैसे mechanical subagent work के लिए यह सही tool है। दूसरी ओर Fable 5.1 की कीमत $10/$50 है। Fable 5 की भी यही दर है और meter के दोनों पक्षों पर यह Opus 5.5 से ढाई गुना महंगा है। इसलिए routine work के लिए इसे selected छोड़ने से पहले यह जानना उपयोगी है कि कौन से jobs वास्तव में उस दर को उचित ठहराते हैं। /model session के बीच model बदलता है।
• Verbose output को पहले filter करें। Claude के output देखने से पहले test run को केवल failures तक सीमित करने वाला hook 20,000 tokens के tool result को 300 tokens में बदल देता है। उस turn को भविष्य में दोबारा भेजे जाने पर भी यह हर बार यही बचत करता है।
• Interactive न होने वाले काम को batch करें। अपने API pipelines में classification, bulk review और nightly jobs के लिए Batches API asynchronous delivery के बदले वही models 50% कम कीमत पर चलाता है।
• Cache clock का ध्यान रखें। लगातार काम करने वाले stints में काम करें। VPS पर tmux में detached Claude Code session idle रहने पर कोई लागत नहीं आती। Tokens केवल turn चलने पर खर्च होते हैं। लेकिन cache TTL से अधिक idle रहने पर warm cache समाप्त हो जाता है और अगले turn में context को फिर से लिखने की लागत लगती है।

FAQ

Claude Code में एक coding session कितने tokens का उपयोग करता है?

इसकी कोई निश्चित संख्या नहीं है। Files और history जमा होने के बाद session के बीच का एक turn आम तौर पर tens of thousands prompt tokens तक पहुँच जाता है, और एक working session millions तक पहुँच सकता है। इनमें से अधिकांश tokens cache से serve होते हैं, जिनकी लागत base rate की दसवीं हिस्से या उससे भी कम होती है, यह model पर निर्भर करता है। तुलना के लिए, October 2026 तक Anthropic के प्रकाशित enterprise आँकड़ों में प्रति active day प्रति developer औसत लागत लगभग $13 है और 90% users की लागत $30 से कम है। अपने session में /usage चलाएँ; इसे पाँच मिनट monitor करना किसी भी प्रकाशित average से अधिक उपयोगी है।

क्या thinking tokens दिखाई न देने पर भी उनकी लागत लगती है?

हाँ। Thinking tokens को output tokens के रूप में bill किया जाता है और इनकी महँगी दर लागू होती है। ये max_tokens में भी गिने जाते हैं। वर्तमान models इनकी billing तब भी करते हैं, जब interface reasoning summary को display में नहीं दिखाता। यदि visible answer पूरा होने से पहले response stop_reason: "max_tokens" के साथ truncate हो जाता है, तो संभव है कि thinking ने budget का उपयोग कर लिया हो। Claude Code में उन tasks के लिए, जिन्हें गहरी reasoning की आवश्यकता नहीं है, /effort के साथ effort level कम करें।

Claude Code का लंबा session प्रति message अधिक महँगा क्यों हो जाता है?

क्योंकि API stateless है। हर turn में context में मौजूद conversation, पढ़ी गई हर file, tool result और compact न की गई पिछली exchange को input के रूप में फिर भेजा जाता है। इसलिए turn 50 में turns 1 से 49 तक का पूरा content शामिल होता है। अधिकांश models में prompt caching repeated prefix को base input price की दसवीं हिस्से की दर पर serve करता है। Opus 5.5 और Sonnet 5.5 में यह 5% और Fable 5.1 में 2.5% है। फिर भी prefix लगातार बढ़ता रहता है। Cache TTL से अधिक idle gap होने पर अगला turn full-price rewrite में बदल जाता है। /compact history को छोटा करता है। /clear इसे reset करता है।

मैं अपने Claude token usage और cost की जाँच कैसे करूँ?

Claude Code में /usage session token statistics, local cost estimate और subscriptions पर plan-limit bars दिखाता है। /cost इसका alias है। /context दिखाता है कि window में कौन-सी सामग्री स्थान भर रही है। Authoritative API billing के लिए Claude Console में usage page का उपयोग करें। अपने code में response.usage पढ़ें। input_tokens, cache_creation_input_tokens और cache_read_input_tokens का योग वास्तविक prompt size देता है। पहले से estimate करने के लिए count_tokens endpoint का उपयोग करें, tiktoken का नहीं।