Claude tokens म्हणजे काय? Claude Code token गणित

Claude मधील tokens म्हणजे काय?

Token हे Claude वाचतो आणि लिहितो त्या मजकुराचे एकक आहे. ते शब्दाचा एक छोटा भाग असतो. Claude Opus 4.7 पूर्वीच्या models साठी Anthropic च्या स्वतःच्या glossary नुसार एका token मध्ये साधारण 3.5 English characters असतात. सध्याच्या tokenizer मध्ये हे प्रमाण 2.5 characters च्या जवळ आहे, कारण Anthropic त्यामध्ये 1M tokens म्हणजे सुमारे 2.5M characters असे मोजते. कोणतेही प्रमाण घेतले तरी spaces आणि punctuation धरल्यावर प्रत्येक शब्दामागे एकापेक्षा अधिक tokens येतात. त्यामुळे prose मधील 1,000 शब्दांसाठी 1,300 पेक्षा बरेच अधिक tokens लागतात. Code मध्ये प्रत्येक line मागे token वापर अधिक असतो. Braces, operators, underscores आणि indentation यांमुळे English मजकुरापेक्षा प्रत्येक character मागे अधिक tokens तयार होतात. काहीशे lines असलेल्या source file मध्ये सामान्यतः अनेक हजार tokens असतात. Agent ने वाचण्याचे ठरवलेली 2,000 lines ची file नवीन code ची एकही line लिहिण्यापूर्वीच पाच अंकी token खर्च निर्माण करू शकते.

Tokenizers बाबत दोन गोष्टींमुळे अनेकांना गोंधळ होतो. पहिले म्हणजे tokenizer model-specific असतो. October 2026 पर्यंत Claude Opus 4.7 आणि त्यानंतरचे सर्व models, ज्यामध्ये सध्याचे Fable 5.1, Opus 5.5, Sonnet 5.5 आणि Haiku 5.5 यांचा समावेश आहे, earlier Claude models जसे Haiku 4.5 यांच्या तुलनेत त्याच मजकुरासाठी साधारण 30% अधिक tokens तयार करणारा नवीन tokenizer वापरतात. मजकुरानुसार अचूक वाढ बदलते. त्यामुळे per-token prices वाढले नसले तरी tokens मध्ये केलेले कोणतेही budget बदलते. दुसरे म्हणजे, tiktoken ही library प्रत्येक blog post मध्ये वापरली जाते, पण ती OpenAI ची tokenizer आहे; Claude ची नाही. त्यामुळे तिचे counts Anthropic च्या billing मधील counts शी जुळणार नाहीत. विश्वास ठेवता येईल अशी एकमेव मोजणी count_tokens endpoint देतो. त्याची माहिती खाली दिली आहे.

तुमच्या coding session ची किंमत अशी का ठरते

प्रत्येक Claude bill, तो API invoice असो किंवा subscription limit, मुख्यतः एका मापकावर चालतो: आत येणारे tokens आणि बाहेर जाणारे tokens. काही API tools स्वतःची स्वतंत्र शुल्क-ओळ जोडतात. उदाहरणार्थ, 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 मध्ये input बाजूचा meter अपेक्षेपेक्षा खूप वेगाने वाढतो, कारण प्रत्येक turn वेळी संपूर्ण conversation पुन्हा पाठवली जाते. मी पंधरा वर्षे metered infrastructure विकले आहे. ग्राहक कोणता घटक meter वाढवत आहे हे खरोखर सांगू शकत नाहीत, असा meter मला प्रथमच tokens मध्ये दिसला. या meter-reading धड्यात agentic session मध्ये input आणि output म्हणून काय मोजले जाते, resend loop इतका महाग का ठरतो, prompt caching मुळे गणित कसे बदलते आणि प्रत्यक्षात कोणते levers हा आकडा बदलतात हे स्पष्ट केले आहे.

सर्वकाही input आहे: meter प्रत्यक्षात काय मोजतो

Claude ने लिहिलेल्या code साठी आपण पैसे देतो, असे लोक मानतात. Agentic session मध्ये तो खर्चाचा लहान भाग असतो. Input tokens चा दर कमी असतो, पण त्यांचे प्रमाण खूप जास्त असते. त्यात पुढील गोष्टी समाविष्ट असतात:

• The system prompt. Claude Code च्या स्वतःच्या harness instructions, तसेच तुमचे CLAUDE.md आणि memory files, session सुरू होताना load केले जातात आणि त्यानंतरच्या प्रत्येक request मध्ये उपस्थित राहतात.
• Tool definitions. Agent call करू शकणाऱ्या प्रत्येक tool चे schema. तुम्ही connect केलेला प्रत्येक MCP server या fixed overhead मध्ये भर घालतो. मात्र Claude Code आता default ने संपूर्ण MCP tool definitions पुढे ढकलतो. त्यामुळे tool प्रथम वापरेपर्यंत context मध्ये फक्त tool names राहतात. यामुळे खर्च कमी होतो, पण तो पूर्णपणे नाहीसा होत नाही.
• Agent ने read केलेली प्रत्येक file. Source file चा Read केल्यावर ती संपूर्ण file context मध्ये येते आणि तिथेच राहते.
• प्रत्येक tool result. Test runs, grep output, terminal spew, build logs, हे सर्व input tokens म्हणून परत येते. 8,000 lines छापणारा failing test suite म्हणजे एक छोटे पुस्तकच असते. October 2026 पासून Claude Code command output मधील अंदाजे 30,000 characters default ने inline पाठवतो. त्यापेक्षा मोठे output saved file आणि जास्तीत जास्त 2,000 characters च्या preview स्वरूपात येते. मात्र त्या मर्यादेपेक्षा कमी असलेले प्रत्येक output आणि saved file चे नंतर केलेले प्रत्येक read यांचे पूर्ण billing होते.
• आतापर्यंतचे संपूर्ण conversation, प्रत्येक turn वर पुन्हा पाठवले जाते. यासाठी स्वतंत्र section आवश्यक आहे.

पुन्हा पाठवण्याची किंमत कोणीही भरत नाही

Claude API स्टेटलेस आहे. दोन विनंत्यांमधील तुमचे session ते लक्षात ठेवत नाही; प्रत्यक्षात कोणतीही गोष्ट ते लक्षात ठेवत नाही. त्यामुळे turn 2 मध्ये client, turn 1 आणि त्यावरील response यांसोबत तुमचा नवीन message पाठवतो. turn 50 मध्ये turns 1 ते 49 मधील अजूनही context मध्ये असलेली सर्व माहिती पुन्हा पाठवली जाते. यात वाचलेली प्रत्येक file, tool result आणि compact न केलेला प्रत्येक diff यांचा समावेश असतो. त्यानंतर turn 50 जोडला जातो. (Compaction जुन्या history च्या जागी summary ठेवते. तसेच subagent ने वाचलेल्या files त्याच्या स्वतःच्या context मध्येच राहतात आणि फक्त त्याचा result परत येतो.) Model प्रत्येक वेळी retained transcript पुन्हा पूर्ण वाचतो. पुन्हा वाचलेल्या त्या प्रत्येक token साठी input म्हणून शुल्क आकारले जाते.

याचा परिणाम असा होतो की session जसजसे लांबते तसतशी प्रत्येक turn ची किंमत साधारणपणे रेषीय पद्धतीने वाढते. एकूण session cost साधारणपणे द्विघात पद्धतीने वाढतो. turn 3 वर अर्ध्या cent ची किंमत असलेला message turn 60 वर त्याच एका ओळीच्या प्रश्नासाठी वीसपट महाग होऊ शकतो. कारण त्यासोबत साठ turns चा संपूर्ण संदर्भ पाठवला जातो. “माझे bill इतके जास्त का आले?” या प्रकारच्या बहुतेक तक्रारींचे स्पष्टीकरण देणारी हीच सर्वात महत्त्वाची बाब आहे. हा Claude चा विशेष दोष नाही. Stateful वाटणारे प्रत्येक LLM product प्रत्यक्षात resend loop खाली चालणारे stateless API असते.

Output: तुम्हाला दिसणारे आणि न दिसणारे thinking

सध्याच्या lineup मध्ये input च्या तुलनेत output tokens चा दर पाचपट जास्त आहे ($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). Output मध्ये Claude ने तयार केलेला मजकूर आणि code, तसेच thinking tokens समाविष्ट असतात: उत्तर देण्यापूर्वी model करत असलेले अंतर्गत reasoning. येथे दोन बाबी महत्त्वाच्या आहेत. Thinking साठी output दराने शुल्क आकारले जाते आणि ते max_tokens मध्ये मोजले जाते. stop_reason: "max_tokens" सह API response मध्येच थांबला आणि उत्तर अपूर्ण राहिले, तर अनेकदा उत्तर तयार होण्यापूर्वी thinking ने budget वापरलेला असतो. तसेच सध्याच्या models मध्ये reasoning summary कदाचित दाखवली जात नाही. API मध्ये Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5 आणि Opus 4.7 पर्यंतच्या जुन्या models साठी ती default ने समाविष्ट नसते. मात्र thinking झालेले असते आणि त्याचे शुल्क आकारले जाते. दिसत नाही म्हणजे ते विनामूल्य नाही.

Claude Code मध्ये extended thinking default ने enabled असते, कारण multi-step कामगिरीत त्याचा मोजता येण्याजोगा फायदा होतो. प्रत्येक request साठी default budget दहा हजारांहून अधिक tokens पर्यंत जाऊ शकतो. सोप्या कामांसाठी ते कमी करता येते: /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 किंवा त्यापेक्षा कमी 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 न करता उत्तर मिळते. तुम्ही पाठवलेल्या कोणत्याही request वर thinking सुरू ठेवणारे models फक्त Opus 5.5 आणि Fable models आहेत. हा प्रत्यक्ष cost lever आहे; केवळ गैरसमज नाही.

Prompt caching मुळे गणित बदलते

Prompt caching मुळे resend loop सर्वांसाठी खर्चिक ठरत नाही. API तुमच्या prompt, system prompt, tool definitions आणि conversation history यांचा स्थिर prefix cache करू शकते. पुढील request वर तो prefix मूळ किमतीच्या काही अंशात उपलब्ध करून देता येतो. 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× खर्च होतो. Write साठी जास्त दर लागू होतो; read मुळे बहुतेक 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 व्यवस्थापित करते. Session सुरळीत असल्यास त्या मोठ्या resend पैकी जवळजवळ सर्व भाग cache मधून मिळतो. मात्र काही काळ वापर न झाल्यास cache expire होतो. October 2026 नुसार, subscription वापरताना आणि तुमच्या plan मधील included usage मध्ये असताना Claude Code तुमच्या मुख्य conversation साठी one-hour cache देते. API key, cloud provider किंवा usage credits वापरताना last use पासून five minutes cache मिळतो. त्या ठिकाणी promptCacheTtl setting वापरून one-hour cache मागवता येतो; त्यासाठी 2× write rate लागू होतो. Five-minute cache मध्ये तुम्ही दीर्घ coffee break साठी दूर जाता, परत येऊन message पाठवता आणि cache expire झालेला असतो. त्यामुळे संपूर्ण जमा झालेला prefix cache rate वर read न होता 1.25× दराने पुन्हा write केला जातो. 150K-token session मध्ये त्या एका cold turn मध्ये सर्व 150K tokens 1.25× दराने write होतात. Warm turn मध्ये ते 0.1× दराने read झाले असते. त्यामुळे prefix वर 12.5 पट फरक पडतो (Opus 5.5 आणि Sonnet 5.5 वर 25 पट, Fable 5.1 वर 50 पट). हा महत्त्वाचा आणि सहज लक्षात न येणारा निष्कर्ष आहे: थांबून पुन्हा सुरू करण्याची पद्धत continuous work पेक्षा महाग पडू शकते, कारण TTL पेक्षा जास्त प्रत्येक idle gap नंतर तुमचा पुढील turn स्वस्त read ऐवजी महाग re-write करतो. सलग कामाचे छोटे सत्र ठेवा. Five-minute cache वापरताना मोठ्या session मध्ये दर दहा मिनिटांनी एक message पाठवत राहू नका.

तुम्ही तुमच्या स्वतःच्या VPS वरील application मधून API call करत असल्यास यापैकी काहीही आपोआप होत नाही. cache_control वापरून तुम्हाला caching opt in करावे लागते. स्वतः निर्माण केलेली सामान्य चूक म्हणजे system prompt मध्ये timestamp किंवा request ID interpolate करणे. त्यामुळे प्रत्येक request वेळी prefix bytes बदलतात आणि caching शांतपणे disabled होते. सारख्या दिसणाऱ्या calls मध्ये usage.cache_read_input_tokens सतत zero असणे हे त्याचे लक्षण आहे.

सूत्र आणि उदाहरण

“एका session ची किंमत $X असते” असे ठामपणे सांगणाऱ्यांकडे दुर्लक्ष करा. Sessions च्या किंमतीत दोन orders of magnitude इतका फरक असू शकतो. लागू होणारे सूत्र हे आहे:

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 वरील उदाहरण पाहू. हे आता legacy model आहे, पण अद्याप उपलब्ध आहे. October 2026 पर्यंत त्याची किंमत प्रति million input tokens $5 आणि प्रति million output tokens $25 आहे. Session च्या मध्यातील एका turn मध्ये एकूण context मधील 80,000 tokens आहेत: त्यापैकी 75,000 cache मधून read केलेले, 3,000 नव्याने write केलेले, 2,000 uncached fresh input आणि 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 दराने पुन्हा write करावे लागतात. त्यात त्याच 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 चे बिल OpenAI च्या बिलापेक्षा कुठे जास्त किंवा कमी येते हे दिसते.

एका turn ऐवजी billing unit ची प्रत्यक्ष कल्पना हवी असल्यास, एक million tokens चे pages, files आणि dollars मध्ये रूपांतर किती होते हेच गणित एक पातळी वर नेऊन दाखवते. अंदाज बांधण्यासाठी नव्हे, तर calibration साठी: October 2026 पर्यंत Anthropic ने प्रकाशित केलेल्या enterprise Claude Code deployments च्या आकडेवारीनुसार, active day मागे प्रत्येक developer साठी सरासरी सुमारे $13, दरमहा $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 मध्ये याच स्क्रीनवर plan-limit bars तसेच अलीकडील वापर skills, subagents, plugins आणि स्वतंत्र MCP servers यांना कसा श्रेय दिला आहे याचा तपशील दिसतो. अलीकडील versions मध्ये Session block मध्ये Prompt cache (main) line देखील असते. त्यात input पैकी cache मधून दिलेला हिस्सा, cache misses आणि सध्या cache warm आहे का हे दिसते. API accounts साठी अधिकृत billing जाणून घेण्यासाठी Claude Console मधील usage page हा अंतिम स्रोत आहे; CLI मधील आकडा estimate असतो. **/context** context window मध्ये [[claude-code-context-management|काय समाविष्ट आहे]] याचा रंगीत grid दाखवते: system prompt, tools, MCP definitions, files आणि history. मोठा CLAUDE.md किंवा अतिप्रमाणात संदेश पाठवणारा MCP server शोधण्याचा हा सर्वात जलद मार्ग आहे. Fullscreen mode मध्ये प्रत्येक घटकाचा breakdown संकुचित होतो; all` दिल्यास तो विस्तारतो.

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 हा फक्त cache न केलेला उरलेला भाग आहे. खरा prompt size हा तिन्ही input fields ची बेरीज असतो. एखादा agent एक तास चालून input_tokens: 4000 दाखवत असेल, तर तो स्वस्त आहे असे समजू नका; इतर 200,000 tokens cache मधून दिले गेलेले असतात. Request पाठवण्यापूर्वी अंदाज घेण्यासाठी token-counting endpoint वापरा. त्यासाठी call करण्याचे शुल्क नाही. तो स्वतंत्र rate limit वर चालतो आणि तुम्ही निर्दिष्ट केलेल्या model च्या tokenizer ने मोजणी करतो. हा परिणाम जवळचा estimate मानावा; billing प्रत्यक्ष request वर आधारित असते:

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

वरील कारणामुळे कधीही tiktoken करू नका.

Subscription plans विरुद्ध pay-as-you-go

या मार्गदर्शिकेतील प्रक्रिया सर्व ठिकाणी सारखीच आहे; फरक फक्त बिलिंगमध्ये आहे. API key वापरल्यास Anthropic प्रकाशित दरांनुसार प्रत्येक token साठी pay-as-you-go पद्धतीने शुल्क आकारते. त्यामुळे वर दिलेली प्रत्येक संख्या प्रत्यक्ष खर्च दर्शवते. हा मीटर बहुतेकांना अपेक्षेपेक्षा लवकर सुरू होतो, कारण वापरण्यासाठी free tier उपलब्ध नाही. त्याऐवजी signup वेळी मिळणारे छोटे credit आणि शुल्क नसलेले काही endpoints एवढेच उपलब्ध असतात. कार्डची माहिती नोंदवण्यापूर्वी नवीन API account ला प्रत्यक्षात काय मिळते, हे येथे पाहा.

October 7, 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 मिळतात. हे credits एकत्रित असतात आणि त्यांची कमाल मर्यादा $500 असते. Console organization link करून हे credits claim करता येतात. न वापरलेले credits प्रत्येक billing cycle च्या शेवटी कालबाह्य होतात. हे credits interactive Claude Code साठी लागू होत नाहीत.

Claude subscription (Pro, Max, Team आणि जुन्या seat-based Enterprise plans) वापरताना Claude Code चा वापर त्याऐवजी तुमच्या plan मध्ये समाविष्ट असलेल्या allowance मधून वजा होतो. October 2026 नुसार यामध्ये rolling five-hour session window आणि weekly window असतो. हे windows models आणि claude.ai chat यांच्यामध्ये सामायिक असतात. /usage डॉलरची रक्कम माहितीपुरती आहे; ती bill म्हणून आकारली जात नाही.

October 2026 नुसार आणखी दोन अपवाद आहेत. सध्याच्या usage-based Enterprise seats मध्ये कोणताही usage समाविष्ट नाही. त्यामुळे प्रत्येक token साठी standard API rates नुसार शुल्क आकारले जाते. तसेच Pro, standard Team seats किंवा standard legacy Enterprise seats यांच्या allowance मध्ये Fable models समाविष्ट नाहीत. या plans मध्ये Fable models 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 तुम्ही ज्या client मध्ये काम करत आहात त्याऐवजी account शी संबंधित असतात. त्यामुळे Linux वर कोणत्या गोष्टी native पद्धतीने चालतात आणि प्रत्येक surface साठी कोणता plan लागू होतो, हे येथे जाणून घेणे उपयुक्त ठरेल.

तुम्ही प्रत्यक्षात कोणते window पूर्ण वापरले आहे, यावर प्रतीक्षा किती काळ करावी लागेल आणि तोपर्यंत काय करणे योग्य ठरेल हे ठरते. त्यामुळे कामाच्या मध्यावर limit आल्यास उपलब्ध पर्याय माहीत असणे उपयुक्त आहे.

Plans मध्ये usage credits ऐच्छिकरित्या enable करता येतात. /usage-credits वापरून कमाल मर्यादेपुढील usage खरेदी करता येतो. मी plans मधील quotas मुद्दाम देत नाही, कारण या विषयातील ही सर्वात वेगाने बदलणारी आकडेवारी आहे. त्याऐवजी claude.com/pricing आणि तुमच्या स्वतःच्या /usage bars तपासा.

Subscription वापरत असतानाही token ची प्रक्रिया महत्त्वाची असते. अनावश्यकपणे खर्चिक session तुमचे window अगदी त्याच प्रकारे वापरते, ज्या प्रकारे ते dollars खर्च करेल. Subscription संदर्भात तुमच्या usage साठी कोणता Claude plan योग्य आहे ते पाहा.

प्रत्यक्ष परिणाम देणारे उपाय

• Agent वाचत असलेली व्याप्ती मर्यादित करा. "auth.py मधील validation bug दुरुस्त करा" असे सांगितल्यास एक फाइल वाचली जाते; "या codebase मध्ये सुधारणा करा" असे सांगितल्यास चाळीस फाइल्स वाचल्या जातात. CLAUDE.md संक्षिप्त ठेवा. ते प्रत्येक session मध्ये load केले जाते. त्यामुळे त्यात फक्त आवश्यक सूचना ठेवा आणि workflow-विशिष्ट सूचना गरजेनुसार load होणाऱ्या skills मध्ये हलवा.
• स्पष्ट आणि संक्षिप्त ठेवा. असंबंधित task दरम्यान /clear केल्यास जुना context प्रत्येक पुढील message सोबत पुन्हा पाठवला जातो आणि त्याचे पुन्हा billing होते. एका दीर्घ task मध्ये /compact Focus on the failing tests and the diff इतिहासाचा सारांश संक्षिप्त ठेवतो आणि quadratic curve पासून तुम्हाला दूर ठेवतो.
• मॉडेलची योग्य क्षमता निवडा. बहुतेक coding कामे Sonnet हाताळतो आणि October 2026 पर्यंत त्याची किंमत प्रति million tokens $2/$10 आहे. ही आता introductory किंमत नसून standard price आहे: Sonnet 5.5 ची किंमत $2/$10 आहे आणि planned September 1 price rise to $3/$15 रद्द झाल्यानंतर Sonnet 5 नेही $2/$10 हीच किंमत ठेवली. त्याच्या तुलनेत Opus 5.5 ची किंमत $4/$20 आहे. Haiku 5.5 ची किंमत $0.10/$0.50 आहे; 100,000 tokens पर्यंतच्या prompts साठी ही किंमत लागू आहे आणि त्यापुढे $0.50/$2.50 आहे. त्यामुळे log triage सारख्या mechanical subagent कामांसाठी ते योग्य tool आहे. दुसऱ्या टोकाला Fable 5.1 ची किंमत $10/$50 आहे. Fable 5 साठीही हाच दर आहे आणि meter च्या दोन्ही बाजूंवर तो Opus 5.5 पेक्षा two and a half times महाग आहे. त्यामुळे routine कामांसाठी तो selected ठेवण्यापूर्वी कोणती कामे प्रत्यक्षात हा दर योग्य ठरवतात हे जाणून घेणे उपयुक्त आहे. /model session च्या मध्यात मॉडेल बदलतो.
• Verbose output आधीच filter करा. Claude ला test run दाखवण्यापूर्वी failures पर्यंत output कमी करणारा hook tool result मधील 20,000 tokens चे 300 tokens मध्ये रूपांतर करतो. त्या turn चे प्रत्येक पुढील resend झाल्यावरही तो हाच परिणाम देतो.
• Interactive नसलेली कामे batch मध्ये चालवा. तुमच्या API pipelines, classification, bulk review आणि nightly jobs साठी Batches API asynchronous delivery च्या बदल्यात तीच models 50% discount मध्ये चालवतो.
• Cache clock लक्षात ठेवा. सलग stints मध्ये काम करा. VPS वरील tmux मधील detached Claude Code session idle असताना कोणताही खर्च होत नाही. Turn चालवल्यावरच tokens वापरले जातात. मात्र cache TTL पेक्षा जास्त idle time झाल्यास warm cache उपलब्ध राहत नाही आणि पुढील turn मध्ये context पुन्हा लिहिण्याचा खर्च होतो.

FAQ

Claude Code सत्रात किती tokens वापरले जातात?

यासाठी निश्चित संख्या नाही. Files आणि history जमा झाल्यानंतर सत्राच्या मध्यातील एका turn मध्ये सामान्यतः tens of thousands of prompt tokens असतात. कार्यरत सत्रात एकूण tokensची संख्या millions पर्यंत जाते. त्यांपैकी बहुतेक tokens cache मधून दिले जातात आणि modelनुसार त्यांची किंमत base rateच्या one-tenth किंवा त्याहून कमी असते. तुलना करण्यासाठी, October 2026 पर्यंत Anthropicने प्रकाशित केलेल्या enterprise आकडेवारीनुसार active dayमागे प्रत्येक developerसाठी सरासरी किंमत सुमारे $13 आहे आणि 90% usersची किंमत $30 पेक्षा कमी आहे. तुमच्या स्वतःच्या सत्रात /usage चालवा; पाच मिनिटे त्याचे निरीक्षण करणे कोणत्याही प्रकाशित सरासरीपेक्षा अधिक उपयुक्त आहे.

मला ते दिसत नसतानाही thinking tokensसाठी पैसे आकारले जातात का?

होय. Thinking tokensना output tokens म्हणून, म्हणजेच अधिक महाग दराने, बिल केले जाते आणि ते max_tokens मध्ये मोजले जातात. सध्याचे models interfaceमध्ये reasoning summary दाखवत नसले तरी त्यांच्यासाठी शुल्क आकारतात. दृश्यमान उत्तर पूर्ण होण्यापूर्वी response stop_reason: "max_tokens" सह थांबला, तर budgetचा वापर बहुधा thinkingने केला आहे. खोल reasoningची आवश्यकता नसलेल्या tasksसाठी Claude Codeमध्ये /effort वापरून effort level कमी करा.

दीर्घ Claude Code सत्रात प्रत्येक messageची किंमत का वाढते?

कारण API stateless आहे. प्रत्येक turnमध्ये contextमध्ये अजून असलेले संपूर्ण conversation, वाचलेली प्रत्येक file, प्रत्येक tool result आणि compact न केलेला मागील प्रत्येक exchange पुन्हा पाठवला जातो आणि त्यासाठी input म्हणून बिल आकारले जाते. त्यामुळे turn 50 मध्ये turns 1 ते 49 हे freight म्हणून समाविष्ट असतात. बहुतेक modelsमध्ये prompt cachingमुळे पुन्हा येणारा prefix base input priceच्या one-tenth दराने दिला जातो. Opus 5.5 आणि Sonnet 5.5 साठी हा दर 5% आणि Fable 5.1 साठी 2.5% आहे. परंतु prefix स्वतः सतत मोठा होत राहतो. तसेच cache TTLपेक्षा जास्त idle gap असल्यास पुढील turn पूर्ण किमतीने पुन्हा लिहावा लागतो. /compact history लहान करते; /clear ती reset करते.

माझा Claude token वापर आणि खर्च कसा तपासू?

Claude Codeमध्ये /usage session token statistics, स्थानिक cost estimate आणि subscriptionsवरील plan-limit bars दाखवते (/cost हे alias आहे). /context windowमध्ये काय भरत आहे ते दाखवते. अधिकृत API billingसाठी Claude Consoleमधील usage page वापरा. तुमच्या स्वतःच्या codeमध्ये response.usage वाचा. input_tokens, cache_creation_input_tokens आणि cache_read_input_tokens यांची बेरीज केल्यास promptचा खरा size मिळतो. आधीच अंदाज घेण्यासाठी count_tokens endpoint वापरा; tiktoken कधीही वापरू नका.