SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-30

Claudeలో tokens అంటే ఏమిటి? Code session ఖర్చులు

Claudeలో token సుమారు 3.5 అక్షరాల పాఠ్యం. ఒక్క Claude Code turnకి 80,000 tokens ఎందుకు బిల్ అవుతాయో, idleగా ఐదు నిమిషాల తర్వాతి turn ఎందుకు 5 రెట్లు ఖర్చవుతుందో తెలుసుకోండి.

Claudeలో tokens అంటే ఏమిటి?

Token అనేది Claude చదివే, రాసే పాఠ్యపు ప్రాథమిక యూనిట్. ఇది ఒక పదంలోని భాగం, సాధారణంగా సుమారు 3.5 English అక్షరాల పరిమాణంలో ఉంటుంది. ఈ సంఖ్య Anthropic అధికారిక glossary నుంచి వచ్చింది. spaces మరియు punctuation ను లెక్కించినప్పుడు, ఒక్కో పదానికి ఒక token కంటే గణనీయంగా ఎక్కువ tokens వస్తాయి. అందువల్ల 1,000 పదాల గద్యానికి సాధారణంగా 1,300 కంటే ఎక్కువ tokens అవసరమవుతాయి. Codeలో ఒక్కో lineకు token వినియోగం ఎక్కువగా ఉంటుంది. braces, operators, underscores మరియు indentation వల్ల, Englishతో పోలిస్తే ప్రతి characterకు ఎక్కువ tokens ఏర్పడతాయి. కొన్ని వందల lines ఉన్న source fileకు సాధారణంగా కొన్ని వేల tokens అవసరమవుతాయి. Agent చదవాలని నిర్ణయించే 2,000-line file కోసం, కొత్త code రాయడం ప్రారంభించే ముందే ఐదు అంకెల సంఖ్యలో tokens అవసరం కావచ్చు.

Tokenizers విషయంలో రెండు అంశాలు తరచుగా గందరగోళానికి గురిచేస్తాయి. మొదటిది, tokenizer model-specific. July 2026 నాటికి Opus 4.7 మరియు తరువాతి versions, Sonnet 5, అలాగే Fable 5 కొత్త tokenizerను ఉపయోగిస్తున్నాయి. ఇదే పాఠ్యానికి ఇది పాత Claude models కంటే సుమారు 30% ఎక్కువ tokens ఉత్పత్తి చేస్తుంది. ఖచ్చితమైన పెరుగుదల contentపై ఆధారపడి మారుతుంది. Per-token prices పెరగకపోయినా, tokens ఆధారంగా చేసే బడ్జెట్ అంచనాలు దీనివల్ల మారతాయి. రెండవది, ప్రతి blog post సాధారణంగా ఉపయోగించే tiktoken అనేది OpenAI tokenizer. సాధారణ textలో ఇది Claude token countను సుమారు 15–20% తక్కువగా చూపిస్తుంది. Codeలో తేడా ఇంకా ఎక్కువగా ఉండవచ్చు. విశ్వసించదగిన ఏకైక count count_tokens endpoint నుంచే లభిస్తుంది. దీని గురించి దిగువన వివరించాం.

మీ coding session కు అయ్యే ఖర్చు ఎందుకు అంతగా ఉంటుంది

ప్రతి Claude bill, అది API invoice అయినా subscription limit అయినా, చివరికి ఒకే meter పై ఆధారపడి ఉంటుంది: లోపలికి వెళ్లే tokens, బయటకు వచ్చే tokens. Pricing page దీనిని సులభంగా చూపిస్తుంది: ప్రతి million input tokens కు ఇంత ధర, ప్రతి million output tokens కు అంత ధర. కానీ agentic coding session లో input meter మన అంచనాకన్నా చాలా వేగంగా ఎందుకు పెరుగుతుందో అది చెప్పదు. కారణం, ప్రతి turn సమయంలో మొత్తం conversation మళ్లీ పంపబడుతుంది. నేను పదిహేను సంవత్సరాలుగా metered infrastructure ను విక్రయిస్తున్నాను. చాలామంది customers తమ meter ను అసలు ఏది నడిపిస్తుందో నిజంగా చెప్పలేని పరిస్థితిని tokens విషయంలోనే మొదటిసారి చూశాను. ఈ meter-reading పాఠంలో agentic session లో input మరియు output గా ఏవి లెక్కించబడతాయి, resend loop ఎందుకు అంత ఖరీదైనది, prompt caching లెక్కను ఎలా మార్చుతుంది, మరియు సంఖ్యను నిజంగా మార్చగల నియంత్రణలు ఏవో వివరిస్తాను.

అన్నీ input: meter వాస్తవంగా లెక్కించేది ఇదే

Claude రాసే code కోసమే తాము చెల్లిస్తున్నామని చాలామంది భావిస్తారు. Agentic session లో అది చిన్న ఖర్చు మాత్రమే. తక్కువ rate ఉన్నప్పటికీ, చాలా ఎక్కువ పరిమాణంలో వచ్చే input tokens లో ఇవి ఉంటాయి:

  • 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 ఇప్పుడు full MCP tool definitions ను default గా defer చేస్తుంది. అందువల్ల tool ను మొదటిసారి ఉపయోగించే వరకు context లో tool names మాత్రమే ఉంటాయి. దీంతో ఖర్చు తగ్గుతుంది, కానీ పూర్తిగా తొలగిపోదు.
  • Agent చదివే ప్రతి file. Source file యొక్క Read మొత్తం file ను context లోకి ఉంచుతుంది. అది అక్కడే కొనసాగుతుంది.
  • ప్రతి tool result. Test runs, grep output, terminal spew, build logs, ఇవన్నీ input tokens గా తిరిగి వస్తాయి. 8,000 lines ముద్రించే failing test suite మీకు చిన్న పుస్తకానికి సమానమైన input tokens కోసం charge చేస్తుంది.
  • ఇప్పటివరకు జరిగిన మొత్తం conversation, ప్రతి turn లో మళ్లీ పంపబడుతుంది. దీనికి ప్రత్యేక section అవసరం.

ప్రతి అభ్యర్థనలో మొత్తం సందర్భాన్ని మళ్లీ పంపాల్సిన ఖర్చు

Claude API stateless గా ఉంటుంది. అభ్యర్థనల మధ్య ఇది మీ session ను గుర్తుంచుకోదు; ఏదీ గుర్తుంచుకోదు. అందువల్ల turn 2లో client, turn 1ను, దాని response ను, అలాగే మీ కొత్త message ను పంపుతుంది. turn 50లో turns 1 నుంచి 49 వరకు ఉన్నవి, చదివిన ప్రతి file, ప్రతి tool result, ప్రతి diff, అలాగే turn 50ను మళ్లీ పంపుతుంది. Model ప్రతిసారీ మొత్తం transcript ను మళ్లీ చదువుతుంది. మళ్లీ చదివిన ప్రతి token inputగా bill అవుతుంది.

దీని ప్రభావం ఏమిటంటే, session పొడవు పెరిగే కొద్దీ ప్రతి turn ఖర్చు సుమారుగా రేఖీయంగా పెరుగుతుంది. మొత్తం session ఖర్చు సుమారుగా వర్గానుపాతంగా పెరుగుతుంది. అదే ఒక-లైన్ ప్రశ్నకు turn 3లో అర సెంట్ ఖర్చు కావచ్చు. turn 60లో దానికి 20 రెట్లు ఖర్చు కావచ్చు, ఎందుకంటే ఆ ప్రశ్నతో పాటు 60 turnsకు సంబంధించిన మొత్తం సందర్భం కూడా పంపబడుతుంది. “నా bill ఎందుకు ఇంత ఎక్కువగా వచ్చింది?” అనే చాలా tickets కు ఇదే ప్రధాన కారణం. ఇది Claude ప్రత్యేకత కాదు. Stateful లాగా అనిపించే ప్రతి LLM product వెనుక కూడా resend loop కలిగిన stateless API ఉంటుంది.

Output: కనిపించేది మాత్రమే కాదు, కనిపించని ఆలోచన కూడా

Output tokens అత్యంత ఖరీదైనవి. ప్రస్తుత lineup లో ఇవి input rate కంటే ఐదు రెట్లు ఖర్చవుతాయి ($5/$25 on Opus 4.8, $3/$15 sticker on Sonnet 5, $1/$5 on Haiku 4.5, as of July 2026). Claude రూపొందించే text మరియు code రెండూ output లోకి వస్తాయి. అలాగే thinking tokens కూడా ఇందులో ఉంటాయి. సమాధానం ఇవ్వడానికి ముందు model చేసే అంతర్గత reasoning ను thinking tokens అంటారు. ఇక్కడ రెండు విషయాలు ముఖ్యమైనవి. Thinking కు output rates ప్రకారం billing జరుగుతుంది. ఇది max_tokens పరిమితిలో లెక్కించబడుతుంది. stop_reason: "max_tokens" తో API response ఆగిపోతే, సమాధానం మధ్యలోనే truncated కావచ్చు. దీనికి కారణం సమాధానం రూపొందించకముందే thinking budget మొత్తం వినియోగించబడటం కావచ్చు. ప్రస్తుత models లో reasoning summary కనిపించకపోవచ్చు. Opus 4.8, Sonnet 5, మరియు Fable 5 దీనిని default గా చూపించవు. అయినప్పటికీ thinking జరుగుతుంది, దానికి billing కూడా జరుగుతుంది. కనిపించకపోవడం అంటే ఉచితం అని కాదు.

Claude Code extended thinking ను default గా enable చేస్తుంది. Multi-step పనుల్లో ఇది కొలిచేంతగా మెరుగైన ఫలితాలను ఇస్తుంది. ప్రతి request కు default budget పదివేలకుపైగా tokens వరకు వెళ్లవచ్చు. సరళమైన పనుల కోసం దీన్ని తగ్గించవచ్చు. /effort ద్వారా లేదా /model లో effort level తగ్గించండి. లేదా /config లో thinking settings మార్చండి. ఇది ఊహ కాదు. ఖర్చును నియంత్రించడానికి ఉపయోగపడే నిజమైన మార్గం.

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% discount ఉంటుంది. ఒక్క read చాలు; అది 5-minute write premium కంటే ఎక్కువ ఖర్చును తిరిగి ఆదా చేస్తుంది.

Claude Code మీ తరఫున caching ను నిర్వహిస్తుంది. ఆరోగ్యకరమైన session లో ఆ భారీ resend లో దాదాపు మొత్తం cache నుంచే అందుతుంది. అయితే default cache చివరిసారి ఉపయోగించినప్పటి నుంచి five minutes మాత్రమే ఉంటుంది. ఎక్కువసేపు coffee break తీసుకుని, తిరిగి వచ్చి message పంపితే cache గడువు ముగిసిపోయి ఉంటుంది. అప్పుడు మొత్తం సేకరించిన prefix ను 0.1× వద్ద read చేయకుండా 1.25× వద్ద మళ్లీ write చేయాలి. 150K-token session లో ఒక్క cold turn ఖర్చు డజనుకు పైగా warm turns కంటే ఎక్కువగా ఉంటుంది. గుర్తుంచుకోవాల్సిన విరుద్ధమైన ఫలితం ఇది: కొంతసేపు idle గా ఉండి, తరువాత resume చేసే పద్ధతి నిరంతర పనికంటే ఎక్కువ ఖర్చవచ్చు, ఎందుకంటే TTL దాటిన ప్రతి idle gap మీ తదుపరి turn ను చవకైన read నుంచి ఖరీదైన re-write గా మారుస్తుంది. పనిని విడతలుగా చేయండి; ప్రతి పది నిమిషాలకు ఒక message చొప్పున భారీ session కు క్రమంగా messages పంపవద్దు.

మీ స్వంత VPS లోని అప్లికేషన్ నుంచి API ను call చేస్తే, ఇవేవీ ఉచితంగా లభించవు. సాధారణంగా మనమే సృష్టించుకునే సమస్య ఏమిటంటే system prompt లో timestamp లేదా request ID ను interpolate చేయడం. దీనివల్ల ప్రతి request లో prefix bytes మారతాయి, caching నిశ్శబ్దంగా నిలిచిపోతుంది. ఒకేలా కనిపించే calls అన్నింటిలో usage.cache_read_input_tokens సున్నా వద్ద ఉండటం దీనికి సూచన.

ఉదాహరణతో సూత్రం

“ఒక 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 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 నుంచి చదివినవి, 3,000 కొత్తగా cache కు రాసినవి, 2,000 cache చేయని తాజా input tokens, 1,500 thinking తో కలిపిన 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 గడువు ముగిసిన తర్వాత అదే turn ను చూడండి: మొత్తం 80,000 tokens ను $6.25/M రేటుతో మళ్లీ రాయడానికి output కు ముందు $0.50 ఖర్చవుతుంది. ఇది cache అందుబాటులో ఉన్న పూర్తి turn కంటే సుమారు ఐదు రెట్లు ఎక్కువ, పని మాత్రం అదే. Caching ప్రభావాన్ని ఒకే సంఖ్యలో చూపించే మొత్తం విషయం ఇదే. Vendors ను నిజాయితీగా పోల్చడానికి కూడా ఈ నాలుగు పంక్తులే సరైన పద్ధతి. Sticker rates లో cache reads మరియు thinking ఖర్చులు పూర్తిగా కనిపించవు. ఈ లెక్కను మూడు నిజమైన jobs పై అమలు చేస్తే Claude బిల్లు OpenAI బిల్లు కంటే ఎక్కడ ఎక్కువ లేదా తక్కువగా ఉంటుందో తెలుస్తుంది.

ఒక turn కంటే billing unit మొత్తాన్ని అర్థం చేసుకోవాలనుకుంటే, ఒక million tokens కు pages, files మరియు dollars పరంగా ఎంత ఖర్చవుతుందో ఇదే లెక్కను ఒక స్థాయి పైకి తీసుకెళ్తుంది. అంచనా కోసం కాదు, పరిమాణాన్ని అర్థం చేసుకోవడానికి: Anthropic ప్రచురించిన enterprise Claude Code deployment గణాంకాల ప్రకారం, July 2026 నాటికి ఒక developer కు active day కు సగటున సుమారు $13, నెలకు $150–250 ఖర్చవుతుంది. Users లో 90% మంది రోజుకు $30 కంటే తక్కువ ఖర్చు చేస్తారు. మీ వాస్తవ ఖర్చు model ఎంపిక, session hygiene మరియు codebase పరిమాణంపై ఆధారపడి ఉంటుంది. అందుకే దిగువన ఉన్న నియంత్రణలు ముఖ్యమైనవి.

మీ వినియోగాన్ని స్వయంగా చూడటం

Claude Code లో ఆదేశం /usage (/cost కూడా పనిచేస్తుంది; ఇది alias). పైభాగంలోని Session విభాగంలో ప్రస్తుత session కు సంబంధించిన token గణాంకాలు మరియు స్థానికంగా లెక్కించిన ఖర్చు అంచనా కనిపిస్తాయి. Subscription plans లో ఇదే స్క్రీన్ మీ plan-limit bars ను, అలాగే skills, subagents, plugins మరియు individual MCP servers కు ఇటీవలి వినియోగాన్ని కేటాయించిన వివరాలను చూపిస్తుంది. API accounts కు అధికారిక billing వివరాల కోసం Claude Console లోని usage page నే ప్రామాణిక ఆధారంగా తీసుకోవాలి; CLI చూపించే సంఖ్య అంచనా మాత్రమే. /context రంగులతో కూడిన grid ను చూపిస్తుంది. అందులో context window లో ఏమి స్థలం ఆక్రమించిందో, system prompt, tools, MCP definitions, files మరియు history కనిపిస్తాయి. పెద్దదైన CLAUDE.md లేదా ఎక్కువ సందేశాలు పంపే MCP server ను గుర్తించడానికి ఇది వేగవంతమైన మార్గం. ప్రతి అంశానికి సంబంధించిన పూర్తి వివరాలను విస్తరించడానికి all ను పంపండి.

API నుంచి వచ్చే ప్రతి response లో ఖచ్చితంగా ఏమి జరిగిందో తెలుస్తుంది:

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}")

input_tokens అనేది cache లో లేని మిగిలిన భాగం మాత్రమే. నిజమైన prompt పరిమాణం మూడు input fields మొత్తానికి సమానం. ఒక గంట పాటు నడిచిన agent input_tokens: 4000 చూపిస్తే, అది తక్కువ ఖర్చు అని అర్థం కాదు; మిగిలిన 200,000 tokens cache నుంచి అందించబడ్డాయి. పంపే ముందు అంచనా వేయడానికి token-counting endpoint ను ఉపయోగించండి. దాన్ని ఉపయోగించడానికి రుసుము లేదు. ఇది ప్రత్యేక rate limit పై పనిచేస్తుంది. మీరు పేర్కొన్న model కు సంబంధించిన tokenizer తో ఇది లెక్కిస్తుంది. ఫలితాన్ని దగ్గర అంచనాగా పరిగణించండి; billing నిజమైన request ఆధారంగా ఉంటుంది:

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

పై కారణం వల్ల ఎప్పుడూ tiktoken చేయవద్దు.

సబ్‌స్క్రిప్షన్ ప్లాన్‌లు వర్సెస్ pay-as-you-go

ఈ guide లోని విధానం అన్ని సందర్భాల్లో ఒకేలా ఉంటుంది; మారేది billing విధానం మాత్రమే. API key తో Anthropic pay-as-you-go విధానంలో, ప్రతి token కు ప్రచురించిన రేట్ల ప్రకారం charge చేస్తుంది; పై పేర్కొన్న ప్రతి సంఖ్య వాస్తవ ఖర్చును సూచిస్తుంది. చాలా మంది ఊహించినదానికంటే ఈ meter త్వరగా ప్రారంభమవుతుంది, ఎందుకంటే ఆధారపడటానికి free tier లేదు. Signup సమయంలో లభించే చిన్న credit మరియు ఎటువంటి charge లేని కొద్దిపాటి endpoints మాత్రమే ఉంటాయి. Card ను account కు జోడించే ముందు కొత్త API account కు వాస్తవంగా ఏమి లభిస్తుందో ఇక్కడ చూడండి.

Claude subscription (Pro, Max, Team, Enterprise) లో, Claude Code usage మీ plan లో చేర్చిన allowance నుంచి తగ్గుతుంది. July 2026 నాటికి ఇది models మరియు claude.ai chat మధ్య shared గా ఉండే rolling five-hour session window, అలాగే weekly window ను కలిగి ఉంటుంది. /usage dollar figure సమాచారం కోసం మాత్రమే; అది bill కాదు. ఒక window పూర్తిగా వినియోగిస్తే reset సమయంతో "మీ session limit ను చేరుకున్నారు" లేదా "మీ weekly limit ను చేరుకున్నారు" అనే సందేశం కనిపిస్తుంది. /model తో model మార్చినా access తిరిగి రాదు, ఎందుకంటే ఈ windows అన్ని models మధ్య shared గా ఉంటాయి. మీరు ఉపయోగిస్తున్న client పై కాకుండా account పై ఈ windows ఆధారపడతాయి. అందువల్ల Linux లో ఏవి native గా నడుస్తాయి, ఏ surface కు ఏ plan వర్తిస్తుంది అనే విషయాన్ని తెలుసుకోవాలంటే ఇక్కడ చూడండి.

మీరు వాస్తవంగా ఏ window ను పూర్తిగా వినియోగించారో దానిపైనే వేచి ఉండాల్సిన సమయం మరియు ఆ సమయంలో చేయడం ప్రయోజనకరమైన పని ఆధారపడి ఉంటాయి. అందువల్ల task మధ్యలో limit చేరుకున్నప్పుడు మీకు ఉన్న ఎంపికలను తెలుసుకోవడం ఉపయోగకరం. Ceiling దాటిన తర్వాత usage కొనుగోలు చేయడానికి plans లో usage credits ను ఐచ్ఛికంగా enable చేయవచ్చు. వీటిని /usage-credits తో నిర్వహిస్తారు. ఈ అంశంలో అత్యంత వేగంగా మారే సంఖ్యలు plan 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-specific సూచనలను అవసరమైనప్పుడు load అయ్యే skills లోకి తరలించండి.
  • స్పష్టంగా, సంక్షిప్తంగా ఉంచండి. సంబంధం లేని tasks మధ్య /clear ను ఉపయోగించండి. లేకపోతే పాత context ప్రతి తదుపరి message లో మళ్లీ పంపబడుతుంది, దానికి మళ్లీ billing జరుగుతుంది. ఒకే దీర్ఘ task లో /compact Focus on the failing tests and the diff చరిత్రను సంక్షిప్తం చేస్తుంది. దీంతో quadratic curve లోకి వెళ్లకుండా ఉండవచ్చు.
  • సరైన పరిమాణంలోని model ను ఎంచుకోండి. Sonnet చాలా coding పనులను నిర్వహిస్తుంది. July 2026 నాటి introductory pricing ప్రకారం దీని ధర ప్రతి million tokens కు $2/$10 (sticker ధర $3/$15; Opus ధర $5/$25). Log triage వంటి mechanical subagent పనులకు ప్రతి million tokens కు $1/$5 ధర కలిగిన Haiku సరైన సాధనం. మరో చివరలో Fable 5 ఉంది. దీని ధర $10/$50, అంటే meter లోని రెండు భాగాల్లోనూ Opus కంటే రెండింతలు. అందువల్ల routine పనులకు దాన్ని ఎంచి ఉంచే ముందు ఏ పనులకు నిజంగా ఆ ధర సమర్థనీయమో తెలుసుకోండి. /model ను session మధ్యలో మార్చవచ్చు.
  • విస్తృత 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 ను పరిగణనలోకి తీసుకోండి. నిరంతర సమయ భాగాల్లో పని చేయండి. 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లో మొత్తం tokens సంఖ్య millionsకు చేరవచ్చు. వీటిలో ఎక్కువ భాగం cache నుంచి అందించబడుతుంది, కాబట్టి base rateలో పదో వంతు మాత్రమే ఖర్చవుతుంది. అంచనా కోసం, July 2026 నాటికి Anthropic ప్రచురించిన enterprise గణాంకాల ప్రకారం, active dayకు developerకు సగటు ఖర్చు సుమారు $13గా ఉంది. Usersలో 90% మంది $30 కంటే తక్కువ ఖర్చు చేశారు. మీ స్వంత sessionలో /usage ను అమలు చేయండి. ఐదు నిమిషాలు దాన్ని monitor చేయడం, ప్రచురించిన ఏ సగటుకన్నా ఉపయోగకరం.

నేను చూడలేకపోయినా thinking tokensకు డబ్బు చెల్లించాలా?

అవును. Thinking tokensను output tokensగా, అధిక రేటుతో bill చేస్తారు. అవి max_tokens పరిమితిలోకి కూడా లెక్కించబడతాయి. ప్రస్తుత modelsలో interface reasoning summaryని displayలో చూపించకపోయినా, thinking tokensకు billing జరుగుతుంది. Visible answer పూర్తయ్యేలోపు response stop_reason: "max_tokens" తో truncated అయితే, budgetలో ఎక్కువ భాగం thinkingకు ఉపయోగించబడి ఉండవచ్చు. లోతైన reasoning అవసరం లేని tasks కోసం Claude Codeలో /effort తో effort levelను తగ్గించండి.

దీర్ఘమైన Claude Code sessionలో ఒక్కో messageకు ఖర్చు ఎందుకు పెరుగుతుంది?

API statelessగా ఉంటుంది. ప్రతి turnలో మొత్తం conversation, చదివిన ప్రతి file, ప్రతి tool result, అలాగే మునుపటి exchanges అన్నీ billed inputగా మళ్లీ పంపబడతాయి. అందువల్ల turn 50లో turns 1 నుంచి 49 వరకు ఉన్న మొత్తం సమాచారం కూడా ఉంటుంది. Prompt cachingలో repeated prefixను base input priceలో సుమారు పదో వంతు ధరకు అందిస్తారు. అయితే prefix పరిమాణం నిరంతరం పెరుగుతుంది. Cache TTLకు మించిన idle gap ఉంటే, తదుపరి turn full-price re-writeగా మారుతుంది. /compact history పరిమాణాన్ని తగ్గిస్తుంది. /clear historyను reset చేస్తుంది.

నా Claude token usage మరియు costను ఎలా తనిఖీ చేయాలి?

Claude Codeలో /usage session token statistics, local cost estimate, అలాగే subscriptionsలో plan-limit barsను చూపిస్తుంది. /cost దీనికి alias. Windowను ఏవి నింపుతున్నాయో /context చూపిస్తుంది. Authoritative 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 ను ఎప్పుడూ ఉపయోగించవద్దు.