Claudeలో 1M tokens ధర ఎంత? లెక్కించే విధానం

Claudeలో 1M tokens ఖర్చు ఎంత?

1M tokens అంటే one million tokens. ప్రతి Claude API (application programming interface) ధరను ఇదే యూనిట్ ఆధారంగా పేర్కొంటారు. దీనికి ఒకే ధర ఉండదు, ఎందుకంటే input మరియు outputలకు వేర్వేరు రేట్లతో billing జరుగుతుంది. ప్రతి modelకు input మరియు output కోసం వేర్వేరు రేట్లు ఉంటాయి. August 2026 నాటికి, Claude Haiku 4.5లో one million input tokens ధర $1, Claude Sonnet 5లో $2, Claude Opus 5లో $5.

Output ఖరీదైన భాగం. ప్రస్తుత ప్రతి modelలో output rate, input rate కంటే ఐదు రెట్లు ఎక్కువగా ఉంటుంది. అందువల్ల మీ billపై headline figure కంటే input మరియు outputల మధ్య నిష్పత్తి ఎక్కువ ప్రభావం చూపుతుంది. పొడవైన documents పంపి, చిన్న సమాధానాలు తిరిగి ఇచ్చే app ప్రవర్తన, చిన్న prompt నుంచి పొడవైన సమాధానాలు రాసే app ప్రవర్తనతో చాలా భిన్నంగా ఉంటుంది.

ఈ పేజీ unit economics గురించి వివరిస్తుంది: ఒక tokenకు ఎంత ఖర్చవుతుంది, మీరు build చేయడానికి ముందు billను ఎలా అంచనా వేయాలి. మీరు పని చేస్తున్నప్పుడు tokens వాస్తవంగా ఎక్కడ ఉపయోగించబడతాయో తెలుసుకోవడానికి Claude Code sessionలో tokens ఎక్కడ ఉపయోగించబడతాయి చదవండి.

1M tokens ఎలా ఉంటాయి

Token అనేది model చదివే లేదా రాసే text భాగం. Anthropic ఇచ్చే సుమారు అంచనా ప్రకారం, 4 characters కు 1 token ఉంటుంది. English లో ఇది సుమారు 0.75 words కు సమానం. అందువల్ల one million tokens అంటే సుమారు 750,000 words లేదా దాదాపు 4 MB plain text.

సాధారణ inputs కోసం ప్రచురించిన అంచనాలు ఈ పరిమాణాన్ని మరింత స్పష్టంగా చూపిస్తాయి.

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

ఆ రేట్ల ప్రకారం, 1M tokens ను సుమారు 400 average web pages ను ఒక్కసారి చదవడానికి లేదా ఆ పరిమాణంలోని ఎనిమిది research papers కు ఉపయోగించవచ్చు. ఇది మధ్యస్థ పరిమాణంలోని codebase పై ఒక pass కు లేదా ఒక వ్యక్తి నెలరోజుల స్వల్ప chat వినియోగానికి సమానం.

ఇవన్నీ అంచనాలుగానే పరిగణించాలి. Code, JSON మరియు English కాకుండా ఇతర భాషల్లోని text ఒక token లో తక్కువ words ను కలిగి ఉంటాయి. అందువల్ల 0.75 నిష్పత్తి ఆశావహమైన గరిష్ఠ అంచనా. Count ను ప్రభావితం చేసే మరో అంశం ఉంది: Opus 5 మరియు Sonnet 5 లను కలిగి ఉన్న Claude Opus 4.7 మరియు తరువాతి versions, Sonnet 4.6 మరియు అంతకుముందు versions కంటే అదే text కు సుమారు 30 percent ఎక్కువ tokens ఉత్పత్తి చేసే కొత్త tokenizer ను ఉపయోగిస్తాయి. Claude Haiku 4.5 పాత tokenizer ను ఉపయోగిస్తుంది. కాబట్టి Haiku 4.5 పై మీరు కొలిచిన count, అదే input కు Sonnet 5 పై ఉండే count కంటే తక్కువగా ఉంటుంది. దీనివల్ల ఆ boundary కు ఇరువైపులా నేరుగా price-per-million పోలిక చేయడం న్యాయసమ్మతం కాదు. నిర్ణయం తీసుకునే ముందు అదే prompt ను రెండు models పై count చేయండి.

Claude ప్రతి మిలియన్ టోకెన్లకు వసూలు చేసే రుసుము

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 కు 31 August 2026 వరకు ప్రారంభ ధరలు అమల్లో ఉంటాయి: input కు $2, output కు $10. 1 September 2026 నుంచి ప్రామాణిక రుసుము అమల్లోకి వస్తుంది: input కు $3, output కు $15. Claude Opus 5 ధర input కు $5, output కు $25. ఈ ధరల పట్టికను మించేది ఒకే model: Claude Fable 5 ధర input కు $10, output కు $50. అందువల్ల ఆ ధరలు చెల్లించడం విలువైనదేనా అనేది మీరు దానికి అప్పగించే పనులపై ఆధారపడి ఉంటుంది.

ధరలు మారవచ్చు. ఈ పేజీలోని ప్రతి సంఖ్యను August 2026 నాటి ఉదాహరణగా పరిగణించండి. బడ్జెట్‌ను ఖరారు చేసే ముందు ప్రస్తుత సంఖ్యలను అధికారిక pricing page లో నిర్ధారించండి.

Context length ధరను మార్చదు. Claude 4.6 మరియు తరువాతి versions లో పూర్తి 1M token context window కు ప్రామాణిక ధరలే వర్తిస్తాయి. అందువల్ల 900,000 token request కు, 9,000 token request కు ప్రతి token పై ఒకే ధర ఉంటుంది. Long prompt కు ఎక్కువ tokens ఉన్నందున ఎక్కువ ఖర్చవుతుంది. దీనికి ప్రత్యేక long-context రుసుము ఉండదు.

ధర మారినప్పటికీ పనిచేసే లెక్క

ప్రతి బిల్లు రెండు గుణకారాలు మరియు ఒక కూడికతో రూపొందుతుంది.

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

దీన్ని మీరు అమలు చేయగల code రూపంలో ఇలా రాయవచ్చు:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

ఇది 0.0126 ను ముద్రిస్తుంది. 4,300 input tokens పంపి, 400 output tokens పొందే request కు Sonnet 5 లో సుమారు 1.3 cents ఖర్చవుతుంది. మీ code లో ఈ రెండు రేట్లను ఒకే చోట ఉంచండి. ధర మారినప్పుడు రెండు lines ను సవరించండి. అప్పుడు మీ system లోని ప్రతి estimate కూడా దానికి అనుగుణంగా మారుతుంది.

నిజమైన అప్లికేషన్‌కు ఒక అంచనా

ఒక support assistant ను తీసుకుందాం. దాని system prompt మరియు product documentation కలిపి 4,000 tokens అవుతాయి. Messages API stateless గా ఉండటం, calls మధ్య model కు ఏదీ గుర్తుండకపోవడం వల్ల అవి ప్రతి request తోనూ పంపబడతాయి. ఒక user question కు సుమారు 300 tokens జత అవుతాయి. ఒక answer సుమారు 400 tokens ఉంటుంది. అందువల్ల ప్రతి request కు 4,300 input tokens మరియు 400 output tokens ఉంటాయి.

ఒక million input tokens తో ఈ విధమైన సుమారు 232 requests చేయవచ్చు. రోజుకు 1,000 requests ఉంటే, అప్లికేషన్ రోజుకు 4.3 million input tokens వినియోగిస్తుంది. కాబట్టి "1M tokens" ట్రాఫిక్ ఆరు గంటలలోపే అయిపోతుంది.

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Claude Opus 5 లో ఈ ట్రాఫిక్‌కు ప్రతి 1,000 requests కు $31.50 ఖర్చవుతుంది. Sonnet 5 లో ఇది $12.60. Claude Haiku 4.5 కు తగ్గిస్తే ఖర్చు $6.30 అవుతుంది. Sonnet 5 లో warm prompt cache ఉపయోగిస్తే ఖర్చు ఇంకా తగ్గి $5.40 అవుతుంది.

ఇలాంటి ఒక నెల ట్రాఫిక్ కోసం ఈ మొత్తాన్ని 30తో గుణించండి. list rates ప్రకారం Sonnet 5 కు నెలకు సుమారు $378 ఖర్చవుతుంది. warm cache తో అదే అప్లికేషన్‌కు సుమారు $162 ఖర్చవుతుంది. ఈ పరిమాణంలో మీరు చర్చించి పొందగలిగే ఏ rate కంటే మీ model ఎంపిక మరియు caching నిర్ణయం ఒక్కొక్కటి ఎక్కువ ప్రభావం చూపుతాయి. ఏ model ను ఉపయోగించాలి అనేది వేరే ప్రశ్న. మీ evaluations లో ఉత్తీర్ణత సాధించే అతి తక్కువ ఖర్చు model నే ఎంచుకోవాలి: Opus, Sonnet మరియు Haiku మధ్య ఎంపిక దీన్ని సరిగ్గా ఎలా పరీక్షించాలో వివరిస్తుంది.

ప్రాంప్ట్ caching పునరావృత భాగం ఖర్చును తగ్గిస్తుంది

ఆ 4,000 token prefix ప్రతి అభ్యర్థనలోనూ ఒకేలా ఉంటుంది. దాని కోసం ప్రతి సారి మొత్తం input ధర చెల్లించాలి. Prompt caching ప్రాసెస్ చేసిన prefix ను నిల్వ చేసి, దాన్ని మళ్లీ ఉపయోగించినప్పుడు తగ్గింపు రేటును వసూలు చేస్తుంది.

Cache read కు base input rate లో 0.1 రెట్లు ఖర్చవుతుంది. 5 నిమిషాల lifetime కోసం cache రాయడానికి base rate లో 1.25 రెట్లు, 1 గంట lifetime కోసం 2 రెట్లు ఖర్చవుతుంది. అందువల్ల 5 నిమిషాల cache ను ఒకసారి చదివిన వెంటనే దాని ఖర్చు తిరిగి వస్తుంది. ఎందుకంటే రాయడానికి అదనంగా 0.25 ఖర్చవుతుంది, ప్రతి read ద్వారా 0.9 ఆదా అవుతుంది. 1 గంట cache సమాన స్థితికి రావడానికి రెండు reads అవసరం.

దీన్ని ప్రారంభించడానికి సరళమైన మార్గం ఒకే top-level field ఉపయోగించడం:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

తిరిగి వచ్చే usage block ను పరిశీలించండి:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

ఈ మూడు input counters కు మూడు వేర్వేరు రేట్లతో బిల్లింగ్ జరుగుతుంది. ఇవి కలిపి మీ వాస్తవ input volume ను ఇస్తాయి: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Caching ప్రారంభమైన తర్వాత input_tokens ను మాత్రమే చదివే cost estimate చాలా తప్పుగా ఉంటుంది.

Cache ద్వారా ఖర్చు తిరిగి రాకుండా చేసే రెండు కారణాలు ఉన్నాయి. రెండింటిలోనూ ఎటువంటి error కనిపించదు.

Prefix byte-identical గా ఉండాలి. Cache lookup prefix match పై ఆధారపడుతుంది. అందువల్ల మీ system prompt ప్రారంభంలో timestamp లేదా user పేరు ఉంటే, అది ప్రతి అభ్యర్థనలో మారుతుంది. అప్పుడు ప్రతి సారి base input ధరకు 1.25 రెట్లు చెల్లించాలి. ఒక్కసారి కూడా read జరగదు. cache_creation_input_tokens విలువ ఎక్కువగా ఉండి, cache_read_input_tokens 0గా ఉండటం దీని లక్షణం. అభ్యర్థనల మధ్య content ఒకేలా ఉండే చివరి block పై cache_control ను ఉంచండి. మారే ప్రతిదాన్ని దాని తర్వాత ఉంచండి. మీ tools definitions ను మార్చితే వాటి దిగువనున్న మొత్తం cache invalid అవుతుంది. ఎందుకంటే invalidation క్రమం tools, తరువాత system, తరువాత messages గా కిందికి అమలవుతుంది.

Prefix తగినంత పొడవుగా ఉండాలి. కనీస cacheable length Opus 5లో 512 tokens, Sonnet 5లో 1,024 tokens, Haiku 4.5లో 4,096 tokens. Prompt దీన్నికంటే చిన్నగా ఉంటే cache చేయబడదు. ఎటువంటి error కూడా తిరిగి ఇవ్వబడదు. పై ఉదాహరణలోని 4,000 token prefix Sonnet 5లో cache అవుతుంది. Haiku 4.5లో cache కాదు, ఎందుకంటే 4,000 ఆ model నిర్దేశించిన కనిష్ఠ పరిమితికంటే తక్కువ. రెండు counters కూడా 0గా ఉంటే, ఏదీ cache కాలేదు.

బ్యాచ్ ప్రాసెసింగ్ రేటును సగానికి తగ్గిస్తుంది

Batch API అభ్యర్థనలను asynchronous గా ప్రాసెస్ చేస్తుంది. Input మరియు output రెండింటిపై 50 percent తగ్గింపు వర్తిస్తుంది. పై ఉదాహరణలో, 1,000 అభ్యర్థనలకు అయ్యే $12.60 ఖర్చు $6.30 కు తగ్గుతుంది. ఈ తగ్గింపు prompt caching తో కలిపి వర్తిస్తుంది. అందువల్ల bulk పనిని అమలు చేయడానికి cached batch job అత్యంత తక్కువ ఖర్చు మార్గం.

దీనికి బదులుగా తగ్గేది latency. కాబట్టి వ్యక్తి కూర్చొని ఫలితం కోసం వేచి ఉండే పనులకు batch సరిపోదు. ఇది రాత్రివేళ classification మరియు document backfills కు అనుకూలంగా ఉంటుంది.

ఒకే సంభాషణలో chat ఖర్చులు ఎందుకు పెరుగుతాయి

API ఎలాంటి state ను నిల్వ చేయదు. అందువల్ల ప్రతి turnలో మీ client మొత్తం conversation ను మళ్లీ పంపుతుంది. కాబట్టి ఒకే chatలో token వినియోగం conversation పొడవుతో సరళంగా కాకుండా, దాని వర్గంతో పెరుగుతుంది.

ఒక్కో turnకు సగటున 500 tokens ఉన్నాయని అనుకుందాం. Turn 1లో 500 input tokens పంపబడతాయి. Turn 2లో 1,000 పంపబడతాయి. Turn 20లో 10,000 పంపబడతాయి. దీన్ని n(n+1)/2 సూత్రంతో కలిపితే, 20 turnల conversation సుమారు 105,000 input tokens పంపినట్లు అవుతుంది. అయితే transcript పొడవు 10,000 tokens మాత్రమే ఉంటుంది.

అందుకే chat feature ఖర్చు దాని transcript సూచించే ఖర్చుకంటే ఎక్కువగా ఉంటుంది. దీర్ఘమైన threadsలో స్థిరమైన prefixను cache చేయడం లేదా పాత turnsను సంక్షిప్తం చేయడం ప్రయోజనకరం. Tool callsపై loop చేసే agentకు కూడా ఇదే విధానం ఉంటుంది, పైగా పరిస్థితి మరింత ఖరీదైనది: ప్రతి tool result historyలోనే ఉంటుంది. తరువాతి ప్రతి turnలో అది మళ్లీ పంపబడుతుంది. మీరు స్వయంగా నడుపుతున్న agentకు గరిష్ఠ ఖర్చు పరిమితిని నిర్ణయించడం ఇక్కడ అత్యంత ముఖ్యమైనది. ఎందుకంటే ఈ పెరుగుదల స్వయంచాలకంగా జరుగుతుంది, దాన్ని ఎవరూ పర్యవేక్షించకపోవచ్చు.

మీ అంచనాకు ముందు tokens సంఖ్యను లెక్కించండి

పదాల సంఖ్య ఆధారంగా tokens సంఖ్యను నిర్ధారించడం ఆపండి. API వాటిని మీ కోసం ఉచితంగా లెక్కిస్తుంది. ఈ లెక్కింపు message creation కు వేరుగా ఉన్న rate limit పై జరుగుతుంది.

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

Response లో ఒక field ఉంటుంది:

{ "input_tokens": 14 }

అందులో మీ నిజమైన system prompt మరియు tool definitions ను, ఒక ప్రతినిధి user message తో కలిపి పంపండి. తరువాత వచ్చిన సంఖ్యను పై cost function లో ఉపయోగించండి. ఈ endpoint message request లో ఉన్నదే body ను స్వీకరిస్తుంది. అందువల్ల images మరియు PDFs కూడా సరిగ్గా లెక్కించబడతాయి. రెండు విషయాలను గుర్తుంచుకోవాలి. ఈ count ఒక estimate మాత్రమే. billed figure తో స్వల్పంగా తేడా ఉండవచ్చు. అలాగే ఇది మీరు pass చేసిన model యొక్క tokenizer తో కొలవబడుతుంది. కాబట్టి వాస్తవంగా run చేయబోయే model నే pass చేయండి.

Output tokens ను ముందుగా లెక్కించలేరు, ఎందుకంటే అవి ఇంకా ఉనికిలో లేవు. max_tokens తో వాటికి పరిమితి విధించండి. తరువాత live traffic పై usage.output_tokens నుంచి వాస్తవ distribution ను కొలవండి.

బిల్లులోకి చేరే ఇతర అంశాలు

బిల్లులో ఎక్కువ భాగం tokens వల్లే వస్తుంది. కొన్ని అంశాలు tokens కావు, కానీ అవి చాలామందిని ఆశ్చర్యపరుస్తాయి.

• ప్రతి requestలో tool definitions input tokensగా మారతాయి. మీ స్వంత schemasను పరిగణనలోకి తీసుకునే ముందు, Opus 5లో tool use system prompt ఒక్కటే 286 నుంచి 406 tokens వరకు జోడిస్తుంది. వివరణలు పొడవుగా ఉన్న పది tools చిన్న prompt పరిమాణాన్ని రెండింతలు చేయవచ్చు.
• ప్రతి 1,000 searchesకు web search రుసుము $10. ఫలితాలు contextలోకి వచ్చినప్పుడు వినియోగించే tokensకు ఇది అదనపు రుసుము.
• web fetchకు ప్రత్యేక రుసుము లేదు. కానీ fetch చేసిన page input tokensగా మారుతుంది. 100 kB పరిమాణం గల documentation pageలో సుమారుగా 25,000 tokens ఉంటాయి.
• Claude 4.6 మరియు తరువాతి versionలలో inference_geo ఉపయోగించి US-only inference కోరితే, cache reads మరియు writesతో సహా ప్రతి token categoryకి 1.1 multiplier వర్తిస్తుంది.

మీ volumeను బట్టి APIని కొనడం అసలు సరైన ఎంపికేనా అనేది నిర్ణయించాలి. సాధారణంగా planలోని usage ceilingను చేరుకున్నప్పుడు ఈ ప్రశ్న తలెత్తుతుంది. అప్పుడు limit దాటిన తర్వాత అందుబాటులో ఉన్న మార్గాలు window ముగిసే వరకు వేచి ఉండటం నుంచి, ఆ పనిని metered API callsకు మార్చడం వరకు ఉంటాయి. వినియోగం ఒక నిర్దిష్ట స్థాయికంటే తక్కువగా ఉంటే flat monthly plan స్పష్టంగా మెరుగైన ఎంపిక. Claude subscriptionతో పోల్చిన API ఈ పోలికను వాస్తవ సంఖ్యలతో చూపిస్తుంది.

FAQ

Claudeలో 1M tokens ధర ఎంత?

ఇది model మరియు tokens input లేదా output అన్నదానిపై ఆధారపడి ఉంటుంది. August 2026 నాటికి, Claude Haiku 4.5లో ఒక million input tokens ధర $1, introductory pricing కింద Claude Sonnet 5లో $2, Claude Opus 5లో $5. ఈ ప్రతి modelలో output ధర input రేటుకు ఐదు రెట్లు ఉంటుంది. 1 September 2026న Sonnet 5 ధర inputకు $3, outputకు $15 అవుతుంది. రేట్లు మారవచ్చు. కాబట్టి బడ్జెట్‌లో మొత్తాన్ని చేర్చే ముందు అధికారిక pricing pageలో వాటిని నిర్ధారించండి.

1M tokens అంటే 1M wordsతో సమానమా?

కాదు. ఒక tokenలో Englishకు సుమారు 4 characters లేదా దాదాపు 0.75 words ఉంటాయి. అందువల్ల one million tokens సుమారు 750,000 wordsకు సమానం. ఈ నిష్పత్తి ఒక సాధారణ అంచనా మాత్రమే. Code, JSON మరియు English కాకుండా ఇతర languagesలో ప్రతి wordకు ఎక్కువ tokens అవసరం కావచ్చు. Claude Opus 4.7 మరియు తరువాతి versionsలో కొత్త tokenizer ఉపయోగిస్తారు. అదే textకు Claude Sonnet 4.6 మరియు అంతకుముందు versionsతో పోలిస్తే ఇది సుమారు 30 percent ఎక్కువ tokens ఉత్పత్తి చేస్తుంది. అందువల్ల వేర్వేరు model generations మధ్య countsను నేరుగా పోల్చలేరు. మీరు నడపాలని భావిస్తున్న modelను పంపించి, ఉచిత /v1/messages/count_tokens endpointతో కొలవండి.

Prompt caching ఎల్లప్పుడూ ఖర్చు తగ్గిస్తుందా?

కాదు. 5 minute cache writeకు base input rateకు 1.25 రెట్లు ఖర్చవుతుంది. అందువల్ల రాసి, ఎప్పుడూ చదవని prefixను సాధారణంగా పంపడం కంటే 25 percent ఎక్కువ ఖర్చవుతుంది. మొదటి read నుంచే దాని ఖర్చు తిరిగి వస్తుంది. ఇది రెండు విధాలుగా విఫలమవుతుంది. రెండూ ఎలాంటి error లేకుండా జరుగుతాయి. Requests మధ్య cached prefix మారితే lookup సరిపోలదు, ఎందుకంటే ఇది exact prefix matchపై ఆధారపడి ఉంటుంది. Prefix modelకు అవసరమైన కనిష్ఠ cacheable length కంటే చిన్నదైతే కూడా caching జరగదు. ఈ కనిష్ఠ పొడవు Sonnet 5లో 1,024 tokens, Haiku 4.5లో 4,096 tokens. ఎలాంటి error కూడా తిరిగి రాదు. cache_creation_input_tokens మరియు cache_read_input_tokens రెండూ 0గా ఉన్నప్పుడు cache ఏ పని చేయడం లేదు.

నా message count కంటే bill వేగంగా ఎందుకు పెరిగింది?

ప్రతి turnలో మొత్తం conversation మళ్లీ పంపబడుతుంది. Messages API ఎలాంటి stateను నిల్వ చేయదు. అందువల్ల chatలోని turn 20లో, అంతకుముందు 19 turns అన్నీ మళ్లీ inputగా ఉంటాయి. ప్రతి turnలో సగటున 500 tokens ఉంటే, 20 turn conversationలో సుమారు 105,000 input tokens పంపబడతాయి. అయితే transcript పొడవు 10,000 tokens మాత్రమే ఉంటుంది. ప్రతి tool result historyలోనే ఉండటం వల్ల agent loops కూడా ఇదే విధంగా పనిచేస్తాయి. స్థిరమైన prefixను cache చేయండి. లేదా పాత turnsను సంక్షిప్తం చేసి request నుంచి తొలగించండి.