Claude tokens म्हणजे काय? Code session चा खर्च

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

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

Tokenizers संदर्भात दोन गोष्टींमुळे अनेकांना गोंधळ होतो. पहिले म्हणजे ते model-specific असतात. July 2026 पर्यंत Opus 4.7 आणि त्यानंतरच्या आवृत्त्या, Sonnet 5 आणि Fable 5 हे आधीच्या Claude models च्या तुलनेत समान मजकुरासाठी साधारणपणे 30% अधिक tokens तयार करणारा नवीन tokenizer वापरतात. अचूक वाढ मजकुरानुसार बदलते. त्यामुळे per-token prices वाढले नसले तरी tokens मध्ये केलेले budget बदलते. दुसरे म्हणजे, प्रत्येक blog post मध्ये वापरली जाणारी tiktoken library ही OpenAI ची tokenizer आहे. ती सामान्य मजकुरासाठी Claude चे tokens साधारणपणे 15–20% ने कमी मोजते आणि code साठी हा फरक अधिक असतो. विश्वासार्ह count फक्त count_tokens endpoint देतो. त्याचे वर्णन खाली केले आहे.

तुमच्या coding session चा खर्च कशामुळे ठरतो

प्रत्येक Claude बिलाचा आधार, ते API invoice असो किंवा subscription limit, एका मापकावर असतो: आत जाणारे tokens आणि बाहेर येणारे tokens. Pricing page वर हे सोपे दिसते: प्रत्येक million input tokens साठी ठरावीक dollars आणि प्रत्येक million output tokens साठी त्याप्रमाणे शुल्क. मात्र agentic coding session मध्ये input बाजूचा मापक आपल्या अपेक्षेपेक्षा कितीतरी वेगाने वाढतो, हे त्यावरून कळत नाही. कारण प्रत्येक turn वेळी संपूर्ण conversation पुन्हा पाठवली जाते. मी पंधरा वर्षे metered infrastructure विकले आहे. बहुतेक customers कोणता घटक हा मापक इतक्या वेगाने वाढवत आहे हे खरोखर सांगू शकत नाहीत. म्हणून हा मापक वाचण्याचा धडा आहे: agentic session मध्ये input आणि output म्हणून काय मोजले जाते, resend loop इतका महाग का ठरतो, prompt caching मुळे गणित कसे बदलते आणि हा आकडा प्रत्यक्षात बदलणारे नियंत्रणबिंदू कोणते आहेत.

सगळेच input आहे: मीटर प्रत्यक्षात काय मोजतो

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

• System prompt. Claude Code च्या स्वतःच्या harness instructions, तसेच तुमच्या CLAUDE.md आणि memory files, session सुरू होताना लोड केल्या जातात आणि त्यानंतरच्या प्रत्येक request मध्ये उपस्थित राहतात.
• Tool definitions. Agent ज्या प्रत्येक tool ला call करू शकतो त्याचे schema. तुम्ही connect केलेला प्रत्येक MCP server या स्थिर 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 साठी छोट्या पुस्तकाइतक्या मजकुराचे billing होते.
• आतापर्यंतचा संपूर्ण conversation, प्रत्येक turn वर पुन्हा पाठवला जातो. यासाठी स्वतंत्र section आवश्यक आहे.

पुन्हा पाठवण्याचा खर्च कोणीही गृहित धरत नाही

Claude API stateless आहे. त्याला requests दरम्यान तुमचे session लक्षात राहत नाही; प्रत्यक्षात कोणत्याही गोष्टीला ते लक्षात राहत नाही. त्यामुळे turn 2 वर client turn 1, त्याचा response आणि तुमचा नवीन message पाठवतो. turn 50 वर तो turns 1 ते 49, वाचलेली प्रत्येक file, प्रत्येक tool result, प्रत्येक diff आणि turn 50 पुन्हा पाठवतो. प्रत्येक वेळी model संपूर्ण transcript पुन्हा वाचतो आणि या प्रत्येक पुन्हा-वाचलेल्या token साठी input शुल्क आकारले जाते.

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

आउटपुट: तुम्हाला दिसणारे आणि न दिसणारे विचार

सध्याच्या lineup मध्ये input च्या तुलनेत output tokens महाग आहेत ($5/$25 on Opus 4.8, $3/$15 sticker on Sonnet 5, $1/$5 on Haiku 4.5, as of July 2026). Output मध्ये Claude ने तयार केलेला मजकूर आणि code, तसेच thinking tokens समाविष्ट असतात: उत्तर देण्यापूर्वी model करत असलेले अंतर्गत reasoning. येथे दोन तथ्ये महत्त्वाची आहेत. Thinking साठी output rates प्रमाणे शुल्क आकारले जाते आणि ते max_tokens मध्ये मोजले जाते. stop_reason: "max_tokens" सह API response थांबणे आणि truncated answer मिळणे याचा अर्थ अनेकदा उत्तर तयार होण्यापूर्वी thinking ने budget वापरले असा असतो. तसेच सध्याच्या models मध्ये reasoning summary दाखवलीच जाईल असे नाही. Opus 4.8, Sonnet 5 आणि Fable 5 ती default ने दाखवत नाहीत. मात्र thinking झालेले असते आणि त्यासाठी शुल्क आकारले जाते. न दिसणारे म्हणजे विनामूल्य नाही.

Claude Code मध्ये extended thinking default ने enabled असते, कारण multi-step कामगिरीमध्ये त्याची मोजता येण्याजोगी सुधारणा होते. प्रत्येक request साठी default budget tens of thousands of tokens पर्यंत जाऊ शकते. सोप्या कामांसाठी ते कमी करता येते: /effort वापरून किंवा /model मध्ये effort level कमी करा, किंवा /config मध्ये thinking settings समायोजित करा. हा खरा cost lever आहे; केवळ गैरसमज नाही.

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

Prompt caching मुळे resend loop मुळे सर्वांचा खर्च अनियंत्रितपणे वाढत नाही. API तुमच्या prompt मधील स्थिर prefix, system prompt, tool definitions आणि conversation history cache करू शकते. पुढील request वर तो डेटा मूळ किमतीच्या काही अंशात दिला जातो. July 2026 पर्यंतचे multipliers असे आहेत: cache write साठी base input rate च्या 1.25× इतका खर्च होतो (1-hour variant साठी 2×), तर cache read साठी 0.1× खर्च होतो. Writes साठी अतिरिक्त शुल्क आहे; reads वर 90% सवलत आहे. एक read देखील 5-minute write साठी दिलेले अतिरिक्त शुल्क भरून काढण्यासाठी पुरेसे असते.

Claude Code caching तुमच्यासाठी व्यवस्थापित करते. निरोगी session मध्ये त्या मोठ्या resend पैकी जवळपास सर्व डेटा cache मधून दिला जातो. परंतु default cache शेवटच्या वापरापासून five minutes पर्यंतच टिकतो. कॉफीसाठी थोडे दूर गेलात, अपेक्षेपेक्षा उशीर झाला, परत येऊन message पाठवला, तर cache expired झालेला असतो. त्यामुळे संपूर्ण संकलित prefix 0.1× दराने read होण्याऐवजी 1.25× दराने पुन्हा write केला जातो. 150K-token session मध्ये असा एक cold turn डझनभर warm turns पेक्षा अधिक खर्चिक ठरतो. लक्षात ठेवण्यासारखा हा उलट परिणाम आहे: idle-then-resume पद्धतीचा खर्च continuous work पेक्षा जास्त होऊ शकतो, कारण TTL पेक्षा मोठे प्रत्येक idle gap तुमच्या पुढील turn ला स्वस्त read ऐवजी महागड्या re-write मध्ये बदलते. काम सलग stints मध्ये करा; दहा मिनिटांनी एक message अशा पद्धतीने मोठा session हळूहळू चालवू नका.

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

फॉर्म्युला, प्रत्यक्ष उदाहरणासह

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

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

session cost = sum over all turns

Claude Opus 4.8 वरील प्रत्यक्ष उदाहरण पाहू. July 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 पाहू: संपूर्ण 80,000 tokens $6.25/M दराने पुन्हा write करावे लागतात. Output धरून घेण्यापूर्वीच किंमत $0.50 होते. म्हणजेच समान कामासाठी पूर्ण warm turn च्या सुमारे पाचपट किंमत. एका संख्येत caching चे संपूर्ण महत्त्व स्पष्ट होते. Vendors ची तुलना करण्याचा प्रामाणिक मार्गही या चार ओळीच आहेत. कारण sticker rates मध्ये cache reads आणि thinking यांचा पूर्ण विचार केलेला नसतो. ही गणना तीन प्रत्यक्ष jobs वर केल्यास Claude चे बिल OpenAI च्या बिलापेक्षा कुठे जास्त किंवा कमी येते हे दिसते.

एका turn ऐवजी billing unit ची प्रत्यक्ष कल्पना हवी असल्यास, एक million tokens चे pages, files आणि dollars मध्ये रूपांतर किती होते हेच गणित एका पातळीवर मोठ्या प्रमाणात दाखवते. अंदाज बांधण्यासाठी नव्हे, तर संदर्भासाठी: July 2026 पर्यंत Anthropic ने प्रकाशित केलेल्या enterprise Claude Code deployments च्या आकडेवारीनुसार, सक्रिय दिवसाला प्रति developer सरासरी सुमारे $13 आणि दरमहा $150–250 खर्च येतो. 90% users चा दैनंदिन खर्च $30 पेक्षा कमी राहतो. तुमचा प्रत्यक्ष खर्च model choice, session hygiene आणि codebase size यांवर अवलंबून असतो. त्यामुळे खालील levers महत्त्वाचे ठरतात.

Seeing your own usage

In Claude Code, the command is /usage (/cost still works, it's an alias). The Session block at the top shows token statistics and a locally computed cost estimate for the current session; on subscription plans the same screen shows your plan-limit bars and a breakdown attributing recent usage to skills, subagents, plugins, and individual MCP servers. For authoritative billing on API accounts, the usage page in the Claude Console is the source of truth, the CLI figure is an estimate. /context draws a colored grid of what's occupying the context window, system prompt, tools, MCP definitions, files, history, and is the fastest way to spot a bloated CLAUDE.md or a chatty MCP server; pass all to expand the full per-item breakdown.

From the API, every response tells you exactly what happened:

response = client.messages.create(model="claude-sonnet-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}")

Note that input_tokens is only the uncached remainder, the true prompt size is the sum of all three input fields. An agent that ran for an hour showing input_tokens: 4000 isn't cheap; the other 200,000 tokens were served from cache. To estimate before you send, use the token-counting endpoint, it's free to call, sits on its own rate limit, and counts with the tokenizer of whichever model you name (treat the result as a close estimate; billing reflects the real request):

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

Never tiktoken, for the reason above.

सदस्यता योजना विरुद्ध वापरानुसार शुल्क

या मार्गदर्शकातील कार्यपद्धती सर्वत्र समान आहे; फक्त शुल्क आकारण्याची पद्धत वेगळी आहे. API key वापरल्यास Anthropic प्रकाशित दरांनुसार प्रत्येक token साठी pay-as-you-go पद्धतीने शुल्क आकारते. वर दिलेली प्रत्येक संख्या प्रत्यक्ष खर्च दर्शवते. बहुतेकांना अपेक्षा असते त्यापेक्षा हे मीटर लवकर सुरू होते, कारण fallback म्हणून कोणताही free tier नाही. Signup वेळी मिळणारे थोडे credit आणि कोणतेही शुल्क नसलेले काही endpoints एवढीच सवलत असते. Card on file करण्यापूर्वी नवीन API account ला प्रत्यक्षात काय मिळते, हे येथे पाहा. Claude subscription (Pro, Max, Team, Enterprise) मध्ये Claude Code चा वापर त्याऐवजी तुमच्या योजनेतील समाविष्ट मर्यादेतून वजा होतो. July 2026 पर्यंत ही मर्यादा rolling five-hour session window आणि weekly window अशी आहे. ही मर्यादा models आणि claude.ai chat यांच्यात सामायिक असते. त्यामुळे /usage dollar figure ही माहितीपुरती असते; ते बिल नसते. एखादी window पूर्णपणे वापरली गेल्यास reset time सह "तुम्ही तुमची session limit गाठली आहे" किंवा "तुम्ही तुमची weekly limit गाठली आहे" असा संदेश दिसेल. /model वापरून model बदलल्याने access पुन्हा मिळणार नाही, कारण या windows सर्व models मध्ये सामायिक असतात. तुम्ही वापरत असलेल्या client ऐवजी या windows account शी संबंधित असतात. Linux वर कोणत्या गोष्टी native पद्धतीने चालतात आणि प्रत्येक surface साठी कोणती योजना लागू होते, हे अजून तपासत असाल तर येथे पाहा. प्रत्यक्षात तुम्ही कोणती window पूर्णपणे वापरली आहे, यावर प्रतीक्षा किती असेल आणि तोपर्यंत काय करणे उपयुक्त ठरेल हे ठरते. त्यामुळे task सुरू असताना limit गाठल्यावर तुमचे पर्याय कोणते आहेत हे जाणून घेणे उपयुक्त ठरते. कमाल मर्यादेपेक्षा जास्त वापरासाठी usage credits सक्षम करता येतात आणि ते /usage-credits वापरून व्यवस्थापित करता येतात. या योजनांच्या quotas मी मुद्दाम येथे देत नाही. या संपूर्ण विषयातील ही सर्वात वेगाने बदलणारी आकडेवारी आहे. त्याऐवजी claude.com/pricing आणि तुमच्या स्वतःच्या /usage bars तपासा. Subscription असतानाही token वापराची कार्यपद्धती महत्त्वाचीच असते. अनावश्यक वापरामुळे तुमची window जशी dollar खर्च झाली असती तशीच वेगाने संपते. Subscription संबंधी माहितीसाठी तुमच्या वापरासाठी कोणती Claude योजना योग्य आहे ते पाहा.

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

• Agent वाचत असलेल्या मजकुराची व्याप्ती मर्यादित ठेवा. "auth.py मधील validation bug दुरुस्त करा" म्हटल्यास एक फाइल वाचली जाते; "या codebase मध्ये सुधारणा करा" म्हटल्यास चाळीस फाइल्स वाचल्या जातात. CLAUDE.md लहान ठेवा, कारण ते प्रत्येक session मध्ये load होते. त्यात फक्त आवश्यक सूचना ठेवा आणि workflow-specific सूचना मागणीनुसार load होणाऱ्या skills मध्ये हलवा.
• स्पष्ट आणि संक्षिप्त ठेवा. असंबंधित कामांदरम्यान /clear करा. अन्यथा जुना context प्रत्येक पुढील message सोबत पुन्हा पाठवला जातो आणि त्यासाठी पुन्हा शुल्क आकारले जाते. एका लांब task मध्ये /compact Focus on the failing tests and the diff history संक्षेपित करते आणि तुम्हाला quadratic curve पासून दूर ठेवते.
• मॉडेलचा योग्य आकार निवडा. बहुतेक coding कामांसाठी Sonnet पुरेसे आहे आणि July 2026 पर्यंत introductory pricing मध्ये त्याची किंमत प्रति million tokens $2/$10 आहे ($3/$15 sticker pricing; Opus ची किंमत $5/$25 आहे). यांत्रिक subagent कामांसाठी, जसे log triage, $1/$5 किंमतीचे Haiku योग्य साधन आहे. दुसऱ्या टोकाला Fable 5 ची किंमत $10/$50 आहे. Meter च्या दोन्ही बाजूंवर ते Opus पेक्षा दुप्पट महाग आहे. त्यामुळे routine कामासाठी ते निवडण्यापूर्वी कोणती कामे प्रत्यक्षात हा दर योग्य ठरवतात हे जाणून घेणे उपयुक्त आहे. /model session च्या मध्यात मॉडेल बदलते.
• Verbose output आधीच filter करा. Claude ला test run दाखवण्यापूर्वी failures पर्यंत त्याचा output मर्यादित करणारा hook tool result मधील 20,000 tokens चे 300 tokens मध्ये रूपांतर करतो. त्या turn चे output भविष्यात पुन्हा पाठवले गेले तरी ही बचत प्रत्येक वेळी होते.
• Interactive नसलेली कामे batch मध्ये चालवा. तुमच्या स्वतःच्या API pipelines, classification, bulk review आणि nightly jobs साठी Batches API asynchronous delivery स्वीकारल्याच्या बदल्यात तीच models 50% सवलतीत चालवते.
• Cache clock लक्षात ठेवा. सलग कालखंडात काम करा. VPS वरील tmux मधील detached Claude Code session idle असताना कोणताही खर्च होत नाही. Turn चालवल्यावरच tokens खर्च होतात. मात्र idle वेळेमुळे warm cache उपलब्ध राहत नाही आणि पुढील turn मध्ये context पुन्हा लिहिण्याचा खर्च होतो.

FAQ

Claude Code मधील coding session मध्ये किती tokens वापरले जातात?

यासाठी निश्चित संख्या नाही. files आणि history जमा झाल्यावर एका session मधील turn मध्ये सामान्यतः हजारो prompt tokens येतात. पूर्ण working session मध्ये ही संख्या millions पर्यंत जाते. यातील बहुतांश tokens cache मधून मिळतात आणि त्यांची किंमत base rate च्या एक-दशांश इतकी असते. तुलना करण्यासाठी, July 2026 पर्यंत Anthropic ने प्रकाशित केलेल्या enterprise आकडेवारीनुसार प्रत्येक सक्रिय दिवशी प्रत्येक developer साठी सरासरी खर्च सुमारे $13 आहे आणि 90% users चा खर्च $30 पेक्षा कमी आहे. तुमच्या स्वतःच्या session मध्ये /usage चालवा; पाच मिनिटे त्याचे निरीक्षण करणे कोणत्याही प्रकाशित सरासरीपेक्षा अधिक उपयुक्त ठरेल.

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

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

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

कारण API stateless आहे. प्रत्येक turn मध्ये संपूर्ण conversation, प्रत्येक file read, tool result आणि मागील exchange पुन्हा input म्हणून पाठवला जातो आणि त्यासाठी billing होते. त्यामुळे turn 50 मध्ये turns 1 ते 49 मधील सर्व content समाविष्ट असते. Prompt caching मुळे repeated prefix ची किंमत base input price च्या सुमारे एक-दशांश इतकी होते. परंतु prefix सतत वाढत राहतो. तसेच cache TTL पेक्षा जास्त idle gap असल्यास पुढील turn साठी संपूर्ण content पुन्हा full-price दराने पाठवावे लागते. /compact मुळे history लहान होते; /clear ती पुन्हा सुरू करते.

माझा Claude token usage आणि cost कसा तपासू?

Claude Code मध्ये /usage session मधील token statistics, स्थानिक cost estimate आणि subscriptions मधील plan-limit bars दाखवते. /cost हा त्याचा alias आहे. Window मध्ये कोणता content जागा घेत आहे हे /context दाखवते. अधिकृत 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 वापरू नका.