Claudeలో 1M టోకెన్ల ధర ఎంత?

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

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

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

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

1M టోకెన్లు ఎలా ఉంటాయి

టోకెన్ అనేది మోడల్ చదివే లేదా రాసే పాఠ్యంలోని ఒక భాగం. Anthropic యొక్క సుమారు మార్గదర్శకం ప్రకారం, 4 అక్షరాలకు 1 టోకెన్ లేదా Englishలో సుమారు 0.75 పదాలు ఉంటాయి. కాబట్టి 1M టోకెన్లు దాదాపు 750,000 పదాలు లేదా సుమారు 4 MB plain textకు సమానం.

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

[
  {
    "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 టోకెన్లు సగటు పరిమాణంలోని సుమారు 400 వెబ్ పేజీలను ఒక్కసారి చదవడానికి లేదా అదే పరిమాణంలోని 8 పరిశోధనా పత్రాలకు సరిపోతాయి. ఇది మధ్యస్థ పరిమాణంలోని ఒక codebaseను ఒక్కసారి పరిశీలించడానికి లేదా ఒక వ్యక్తి ఒక నెలపాటు పరిమితంగా chat ఉపయోగించడానికి సరిపోతుంది.

ఇవన్నీ అంచనాలుగానే పరిగణించండి. English కాకుండా ఇతర భాషల్లోని code, JSON మరియు textలో ఒక్క టోకెన్‌లో చేరే పదాల సంఖ్య తక్కువగా ఉంటుంది. అందువల్ల 0.75 నిష్పత్తి ఆశావహ అంచనా. టోకెన్ల సంఖ్యను ప్రభావితం చేసే మరో విషయం ఉంది: Opus 5 మరియు Sonnet 5లను కలిగి ఉన్న Claude Opus 4.7 మరియు తరువాతి వెర్షన్లు, Sonnet 4.6 మరియు అంతకుముందు వెర్షన్లతో పోలిస్తే అదే textకు సుమారు 30 శాతం ఎక్కువ టోకెన్లను ఉత్పత్తి చేసే కొత్త tokenizerను ఉపయోగిస్తాయి. Claude Haiku 4.5 పాత tokenizerను ఉపయోగిస్తుంది. కాబట్టి Haiku 4.5లో కొలిచిన సంఖ్య, అదే inputకు Sonnet 5లో ఉండే సంఖ్య కంటే తక్కువగా ఉంటుంది. అందువల్ల ఆ రెండు tokenizerల సరిహద్దును దాటి నేరుగా ప్రతి మిలియన్ టోకెన్ల ధరను పోల్చడం సముచితం కాదు. నిర్ణయం తీసుకునే ముందు అదే promptను రెండు మోడళ్లతో లెక్కించండి.

మిలియన్ టోకెన్లకు 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 వరకు ప్రారంభ ధర అమల్లో ఉంటుంది: ఇన్‌పుట్‌కు $2, అవుట్‌పుట్‌కు $10. 1 September 2026 నుంచి ప్రామాణిక రేటు అమల్లోకి వస్తుంది: ఇన్‌పుట్‌కు $3, అవుట్‌పుట్‌కు $15. Claude Opus 5 ధర ఇన్‌పుట్‌కు $5, అవుట్‌పుట్‌కు $25.

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

Context length రేటును మార్చదు. Claude 4.6 మరియు తదుపరి వెర్షన్‌లలో పూర్తి 1M token context windowకు ప్రామాణిక ధరనే వర్తింపజేస్తారు. అందువల్ల 900,000 tokenల requestకు, 9,000 tokenల requestకు ఒక్కో tokenపై ఒకే ధర ఉంటుంది. పొడవైన promptకు ఎక్కువ ఖర్చు అవుతుంది, ఎందుకంటే అందులో ఎక్కువ tokenలు ఉంటాయి. దీనికి ప్రత్యేక 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 ఖర్చవుతుంది. రెండు rates ను మీ code లో ఒకే చోట ఉంచండి. ధర మారినప్పుడు రెండు lines ను సవరించండి. అప్పుడు మీ system లోని ప్రతి estimate కూడా దానికి అనుగుణంగా మారుతుంది.

వాస్తవ యాప్ కోసం ఒక ఉదాహరణ అంచనా

ఒక సపోర్ట్ అసిస్టెంట్‌ను పరిగణించండి. దాని system prompt మరియు ఉత్పత్తి డాక్యుమెంటేషన్ కలిపి 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 ఉంటే, app ప్రతిరోజూ 4.3 million input tokens వినియోగిస్తుంది. అందువల్ల "1M tokens" ట్రాఫిక్ 6 గంటలకంటే తక్కువ సమయానికే సరిపోతుంది.

[
  {
    "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తో అదే app‌కు సుమారు $162 ఖర్చవుతుంది. ఈ పరిమాణంలో మీరు చర్చించి పొందగల ఏ rate కంటే మీ model ఎంపిక మరియు caching నిర్ణయం ఒక్కొక్కటి ఎక్కువ ప్రభావం చూపుతాయి. ఏ model‌ను అమలు చేయాలనేది వేరే ప్రశ్న. మీ evaluationsలో ఉత్తీర్ణత సాధించే అత్యంత చవకైన model‌నే ఎంచుకోవాలి: Opus, Sonnet మరియు Haiku మధ్య ఎంపిక దీన్ని సరిగ్గా ఎలా పరీక్షించాలో వివరిస్తుంది.

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

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

Cache read ఖర్చు base input rateలో 0.1 రెట్లు ఉంటుంది. 5 నిమిషాల lifetime కోసం cache రాయడానికి base రేటుకు 1.25 రెట్లు, 1 గంట lifetime కోసం 2 రెట్లు ఖర్చవుతుంది. అందువల్ల 5 నిమిషాల cacheను ఒకసారి చదివిన తర్వాతే దాని ఖర్చు తిరిగి వస్తుంది. Writeకు అదనంగా 0.25 ఖర్చవుతుంది, ప్రతి readలో 0.9 ఆదా అవుతుంది. 1 గంట cacheకు ఖర్చు సమం కావడానికి 2 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కు మూడు వేర్వేరు రేట్లతో billing జరుగుతుంది. ఇవి కలిపి మీ వాస్తవ input volumeను చూపిస్తాయి: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. input_tokensను మాత్రమే చదివే cost estimate, caching ప్రారంభించిన తర్వాత చాలా తప్పుగా ఉంటుంది.

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

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

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

Batch processing రేటును సగానికి తగ్గిస్తుంది

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 మొత్తం సంభాషణను మళ్లీ పంపుతుంది. కాబట్టి ఒకే chat‌లో token వినియోగం సరళ రేఖలా కాకుండా, దాని పొడవు వర్గానికి అనుగుణంగా పెరుగుతుంది.

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

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

ఊహించడానికి ముందు టోకెన్లను లెక్కించండి

పదాల సంఖ్య ఆధారంగా టోకెన్ల సంఖ్యను అంచనా వేయడం ఆపండి. 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"
    }]
  }'

ప్రతిస్పందనలో ఒక field ఉంటుంది:

{ "input_tokens": 14 }

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

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

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

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

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

మీ వినియోగ పరిమాణంపై ఆధారపడి, APIనే కొనడం సరైన ఎంపిక కాకపోవచ్చు. నిర్దిష్ట స్థాయి కంటే తక్కువ వినియోగంలో flat monthly plan స్పష్టంగా ప్రయోజనకరంగా ఉంటుంది. Claude subscriptionతో పోల్చిన API వాస్తవ సంఖ్యలతో ఆ పోలికను చూపిస్తుంది.

FAQ

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

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

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

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

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

కాదు. 5 minute cache writeకు base input rateకు 1.25 రెట్లు ఖర్చవుతుంది. అందువల్ల write చేసి ఎప్పుడూ read చేయని prefixను సాధారణంగా పంపితే కలిగే ఖర్చుకంటే 25 percent ఎక్కువ ఖర్చవుతుంది. మొదటి read నుంచే అది తన ఖర్చును తిరిగి పొందుతుంది. ఇది రెండు విధాలుగా విఫలమవుతుంది. రెండూ నిశ్శబ్దంగా జరుగుతాయి. Requests మధ్య cached prefix మారితే lookup ఎప్పుడూ సరిపోలదు, ఎందుకంటే ఇది exact prefix match. Prefix modelకు అవసరమైన కనిష్ఠ cacheable length కంటే చిన్నదైతే కూడా ఏదీ cache కాదు, error కూడా తిరిగి రాదు. Sonnet 5లో ఈ పరిమితి 1,024 tokens, Haiku 4.5లో 4,096. 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ను summarise చేసి request నుంచి తొలగించండి.