Claude prompt caching బ్రేక్-ఈవెన్ లెక్క

సేవ్ చేయడానికి ముందు prompt caching ఖర్చు

Prompt caching వల్ల ప్రతి call సమయంలో మీ prompt ప్రారంభ భాగాన్ని మళ్లీ చదవకుండా Claude దాన్ని తిరిగి ఉపయోగించగలదు. మొత్తం నిర్ణయం మీ model యొక్క base input ధరకు వర్తించే రెండు multipliers పై ఆధారపడి ఉంటుంది. August 2026 నాటికి, 5 minute lifetime ఉన్న cache write కు base input ధరకు 1.25x ఖర్చవుతుంది. 1 hour lifetime ఉన్న cache write కు 2x ఖర్చవుతుంది. Cache read కు 0.1x ఖర్చవుతుంది. ఈ multipliers అన్ని modelల జాబితాలో ఒకే విధంగా ఉంటాయి. అందువల్ల ప్రతి token ధర మారినా, కింది break-even లెక్క మారదు.

ఇక్కడ ఉన్న trade-off ఏమిటంటే, ఇప్పుడు surcharge చెల్లించి తరువాత discount పొందడం. ఒక prefix ను store చేయడానికి మొదటిసారి అదనపు ఖర్చు చెల్లించాలి. తరువాత అదే bytes తో ఖచ్చితంగా ప్రారంభమయ్యే ప్రతి request లో, ఆ భాగానికి సాధారణ input ధరలో పదో వంతు మాత్రమే చెల్లించాలి. Lifetime లోపు ఒక్కసారి కూడా reuse కాని prefix కోసం 25 percent అదనంగా చెల్లించినా ఎలాంటి ప్రయోజనం ఉండదు.

బ్రేక్-ఈవెన్, ఒకే బీజగణిత సమీకరణలో

క్యాష్ లేకుండా పంపితే prefix కోసం అయ్యే ప్రాథమిక input ఖర్చును B గా పరిగణించండి. Caching లేకుండా, N requests కు N రెట్లు B ఖర్చవుతుంది. 5 minute cache తో, మొదటి request prefix ను 1.25B వద్ద రాస్తుంది. మిగిలిన N minus 1 requests దాన్ని 0.1B వద్ద చదువుతాయి. ఈ రెండు ఖర్చులను సమానం చేస్తే 0.9N = 1.15 వస్తుంది. అందువల్ల N = 1.28. రెండవ request నుంచే caching చేయడం, అసలు caching చేయకపోవడం కంటే చౌకగా ఉంటుంది.

1 hour cache యొక్క 2x write తో ఇదే లెక్కను మళ్లీ చేస్తే 0.9N = 1.9 వస్తుంది. అందువల్ల N = 2.11. దీర్ఘకాల cache break-even కు చేరే ముందు రెండు reads అవసరం. అందుకే ఇది default ఎంపిక కాదు.

క్రింది chart ఈ ఖర్చును Claude Opus 5 లోని 20,000 token prefix కోసం చూపిస్తుంది. August 2026 నాటికి దీని ప్రాథమిక input rate ప్రతి million tokens కు $5. ప్రతి million tokens కు $3 ఉన్న model కోసం ప్రతి సంఖ్యను 0.6 తో గుణించండి. Curve ఆకారం మారదు.

[
  {
    "requests": 1,
    "uncached_usd": "0.10",
    "cached_5m_usd": "0.125",
    "cached_1h_usd": "0.20"
  },
  {
    "requests": 2,
    "uncached_usd": "0.20",
    "cached_5m_usd": "0.135",
    "cached_1h_usd": "0.21"
  },
  {
    "requests": 3,
    "uncached_usd": "0.30",
    "cached_5m_usd": "0.145",
    "cached_1h_usd": "0.22"
  },
  {
    "requests": 5,
    "uncached_usd": "0.50",
    "cached_5m_usd": "0.165",
    "cached_1h_usd": "0.24"
  },
  {
    "requests": 10,
    "uncached_usd": "1.00",
    "cached_5m_usd": "0.215",
    "cached_1h_usd": "0.29"
  },
  {
    "requests": 20,
    "uncached_usd": "2.00",
    "cached_5m_usd": "0.315",
    "cached_1h_usd": "0.39"
  }
]

ఒక request మాత్రమే ఉంటే caching లేకుండా ఖర్చు $0.10, caching తో ఖర్చు $0.125. అందువల్ల ఒకసారి మాత్రమే ఉపయోగించే prompt ను cache చేయడం వల్ల నష్టం మాత్రమే వస్తుంది. రెండవ request నాటికి 5 minute cache ఖర్చు $0.135, caching లేకుండా ఖర్చు $0.20. ఆ సమయంలో 1 hour cache ఇంకా వెనుకబడి ఉంటుంది: దాని ఖర్చు $0.21, అదే caching లేకుండా ఖర్చు $0.20. ఇది మూడవ request వద్ద మాత్రమే caching లేని ఖర్చు కంటే తక్కువకు వస్తుంది: $0.22, caching లేకుండా ఖర్చు $0.30. 20 requests నాటికి తేడా $2.00 మరియు $0.315 మధ్య ఉంటుంది.

Cache hit entry ను మళ్లీ refresh చేస్తుంది. అందుకే published price table లో ఆ column కు cache hits and refreshes అని పేరు పెట్టారు. అందువల్ల busy endpoint 5 minute entry ను read prices వద్ద నిరవధికంగా active గా ఉంచుతుంది. మీ traffic లో వాస్తవమైన విరామాలు ఉన్నప్పుడే 1 hour lifetime యొక్క 2x write ఖర్చు ప్రయోజనకరంగా మారుతుంది.

తక్కువ cache hit rate వల్ల అయ్యే ఖర్చు

నిజమైన traffic లో cache missలు జరుగుతాయి. Cache miss అయినా breakpoint ను కలిగి ఉన్న request ను write గా charge చేస్తారు. అందువల్ల hit rate ఆధారంగా cost ను model చేయడమే సరైన పద్ధతి. దిగువ chart 1,000 requests కోసం ఈ లెక్కను చూపిస్తుంది. ప్రతి request లో ఒకే 20,000 token prefix ఉంటుంది.

[
  {
    "hit_rate_percent": 0,
    "cost_5m_usd": "125.00",
    "cost_1h_usd": "200.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 25,
    "cost_5m_usd": "96.25",
    "cost_1h_usd": "152.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 50,
    "cost_5m_usd": "67.50",
    "cost_1h_usd": "105.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 75,
    "cost_5m_usd": "38.75",
    "cost_1h_usd": "57.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 90,
    "cost_5m_usd": "21.50",
    "cost_1h_usd": "29.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 95,
    "cost_5m_usd": "15.75",
    "cost_1h_usd": "19.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 99,
    "cost_5m_usd": "11.15",
    "cost_1h_usd": "11.90",
    "uncached_usd": "100.00"
  }
]

0 percent hit rate వద్ద మీకు $125.00 చెల్లించాలి. ఇది $100.00 కంటే ఎక్కువ. 1 hour cache bill ను రెండింతలు చేసి $200.00 కు తీసుకెళ్తుంది. 1.25 minus 1.15h = 1 ను పరిష్కరిస్తే, 5 minute cache సుమారు 22 percent hit rate వద్ద డబ్బు ఆదా చేయడం ప్రారంభిస్తుంది. అందుకే 25 percent వద్దనే $96.25 కనిపిస్తుంది. 2x write పై ఇదే లెక్క 1 hour cache కోసం సుమారు 53 percent ను ఇస్తుంది. అందువల్ల 50 percent hit rate వద్ద కూడా ఖర్చు $105.00 గా ఉంటుంది. ఇది uncached line కంటే ఎక్కువ. 90 percent వద్ద రెండు విలువలు వరుసగా $21.50 మరియు $29.00 కు చేరుతాయి. 99 percent వద్ద short cache $11.15 కు చేరుతుంది. ఇది uncached price లో one tenth గా ఉన్న floor కు దగ్గరగా ఉంటుంది.

Prefix size స్థిరమైన తర్వాత మీరు నియంత్రించగల ఏకైక input hit rate. అందుకే instrument చేయాల్సిన ప్రధాన సంఖ్య కూడా hit rate.

ఏ prefixes కు breakpoint విలువైనది

ఒక request గరిష్ఠంగా నాలుగు cache breakpoints ను కలిగి ఉండవచ్చు. కాబట్టి ఏ blocks కు breakpoint అవసరమో నిర్ణయించాలి. Calls మధ్య byte స్థాయిలో పూర్తిగా ఒకేలా ఉండి, వ్యత్యాసం చూపించేంత పెద్దవిగా ఉన్న blocks అభ్యర్థులు. 5 minute cache లో 90 percent hit rate తో 1,000 requests కు నాలుగు సాధారణ ఆకృతుల ధరలను క్రింది chart చూపిస్తుంది.

[
  {
    "label": "System prompt",
    "prefix_size_tokens": "2,000",
    "uncached_usd": "10.00",
    "cached_usd": "2.15",
    "saved_usd": "7.85"
  },
  {
    "label": "System plus tools",
    "prefix_size_tokens": "8,000",
    "uncached_usd": "40.00",
    "cached_usd": "8.60",
    "saved_usd": "31.40"
  },
  {
    "label": "Policy document",
    "prefix_size_tokens": "25,000",
    "uncached_usd": "125.00",
    "cached_usd": "26.88",
    "saved_usd": "98.12"
  },
  {
    "label": "Codebase context",
    "prefix_size_tokens": "120,000",
    "uncached_usd": "600.00",
    "cached_usd": "129.00",
    "saved_usd": "471.00"
  }
]

కేవలం 2,000 token system prompt ను ఉపయోగిస్తే, cache చేయనప్పుడు అయ్యే $10.00 తో పోలిస్తే 1,000 requests కు $7.85 ఆదా అవుతుంది. పెద్ద volume లో ఇది వాస్తవమైన ఆదాయం. అయితే caching ఆసక్తికరంగా అనిపించడానికి ఇదొక్కటే కారణం కాదు. Tool definitions ను కూడా చేరిస్తే మొత్తం 8,000 tokens అవుతాయి, ఆదా $31.40. ప్రతి request ప్రశ్నలు అడిగే 25,000 token policy document ను cache చేస్తే $98.12 ఆదా అవుతుంది. Architecture ను మార్చే వరుస చివరిది: 120,000 tokens codebase లేదా transcript context cache చేయనప్పుడు $600.00, cache చేసినప్పుడు $129.00 ఖర్చవుతుంది. అంటే $471.00 ఆదా అవుతుంది.

Savings prefix పరిమాణం మరియు hit rate తో పెరుగుతాయి. ఇతర ఏ అంశంతోనూ అవి పెరగవు. అందువల్ల prompt లో ఏమి చేర్చాలో కూడా ఇది మార్చుతుంది: ఒకటి కంటే ఎక్కువసార్లు పంపే ఏ content కైనా మిలియన్ Claude tokens కు వాస్తవంగా ఎంత ఖర్చవుతుంది అనేది sticker price లో పదో వంతుకు తగ్గుతుంది.

నెలవారీ బిల్లులో ఇది ఎలా కనిపిస్తుంది

క్రింది చార్ట్ పైన పేర్కొన్న 8,000 token prefix, system prompt మరియు tool definitions ను 90 శాతం hit rate వద్ద తీసుకుని, వాటిని నెలవారీ request పరిమాణాలకు విస్తరిస్తుంది.

[
  {
    "label": "10k requests",
    "uncached_usd": "400.00",
    "cached_usd": "86.00",
    "saved_usd": "314.00"
  },
  {
    "label": "100k requests",
    "uncached_usd": "4,000.00",
    "cached_usd": "860.00",
    "saved_usd": "3,140.00"
  },
  {
    "label": "1M requests",
    "uncached_usd": "40,000.00",
    "cached_usd": "8,600.00",
    "saved_usd": "31,400.00"
  }
]

నెలకు 10,000 requests వద్ద ఆదా $314.00. ఇది $400.00 మరియు $86.00 మధ్య తేడా. 100,000 requests వద్ద ఆదా $3,140.00. ఒక million requests వద్ద caching లేకుండా input bill $40,000.00 ఉంటుంది. caching అందులోని $31,400.00 ను తొలగిస్తుంది. ఇవి input tokens కు మాత్రమే సంబంధించినవి. Output కు విడిగా ధర నిర్ణయించబడుతుంది. caching దానిపై ఎలాంటి ప్రభావం చూపదు. అందువల్ల ఎవరికైనా bill ను 90 శాతం తగ్గిస్తామని హామీ ఇచ్చే ముందు ఈ విషయాన్ని గుర్తుంచుకోవాలి. VPSలో AI agent bill ను నియంత్రణలో ఉంచే విస్తృత పద్ధతులతో పాటు caching కూడా ఉపయోగపడుతుంది. VPSలో AI agent bill ను నియంత్రణలో ఉంచడం

క్యాష్ పనిచేస్తోందని ఎలా నిరూపించాలి

డిజైన్‌ను నమ్మి ఆగిపోవద్దు. Response లోని usage block ను చదవండి. ప్రతి Messages API (application programming interface) reply అది రాసిన cached tokens, చదివిన cached tokens, అలాగే కొత్తగా process చేయాల్సి వచ్చిన fresh tokens సంఖ్యలను చూపిస్తుంది.

from anthropic import Anthropic

client = Anthropic()

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=512,
    system=[
        {
            "type": "text",
            "text": POLICY_DOCUMENT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": question}],
)

u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)

అదే document తో, వేరే question ఉపయోగించి దీన్ని రెండుసార్లు run చేయండి. మొదటి call లో non-zero cache_creation_input_tokens మరియు zero cache_read_input_tokens కనిపిస్తాయి. Prefix కనుగొనబడినందున, రెండో call లో ఇది తారుమారవుతుంది. చివరి breakpoint తర్వాత ఉన్న tokens ను మాత్రమే input_tokens లెక్కిస్తుంది. అందువల్ల సక్రమంగా పనిచేసే రెండో call లో ఇది చిన్నదిగా ఉంటుంది. సాధారణంగా కొత్త user message మాత్రమే ఉంటుంది. రెండు calls కు billing జరుగుతుంది, ఎందుకంటే Claude APIలో ఉచిత tier లేదు. అయితే పై ధర ప్రకారం 20,000 token prefix కు ఈ రెండు calls కలిపి సుమారు పద్నాలుగు cents ఖర్చవుతుంది.

మీరు request.json లో సేవ్ చేసిన request body కు వ్యతిరేకంగా shell నుంచి ఇదే తనిఖీ చేయవచ్చు:

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @request.json | jq '.usage'

సక్రమంగా పనిచేసే రెండో call లో ఇలాంటిది print అవుతుంది:

{
  "input_tokens": 42,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 20143,
  "output_tokens": 187
}

ఒక line వాస్తవాన్ని తెలియజేస్తుంది. Calls మధ్య cache_read_input_tokens 0గానే ఉంటే, ప్రతి సారి 1.25x write కోసం చెల్లిస్తున్నారు. దానికి బదులుగా ఏ cache data తిరిగి పొందడం లేదు.

1 hour lifetime కోసం breakpoint లో time to live (TTL) ఉంటుంది:

{
  "type": "text",
  "text": "your stable prefix",
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

Automatic caching కూడా ఉంది. Request యొక్క top level లో ఒకే cache_control field ను ఉంచిన తర్వాత, conversation పెరుగుతున్న కొద్దీ API breakpoints ను నిర్వహిస్తుంది. ఇది మీ నాలుగు breakpoint slots లో ఒకదాన్ని ఉపయోగిస్తుంది. ముందుగా దీన్నే ఉపయోగించండి. Boundary ఖచ్చితంగా ఎక్కడ ఉండాలో నిర్ణయించాల్సినప్పుడు explicit breakpoints కు మారండి.

హిట్ రేట్లను తగ్గించే క్రమ నియమం

క్యాష్ అభ్యర్థన ప్రారంభం నుంచి ప్రతి byte ను క్రమంగా సరిపోల్చుతుంది. అభ్యర్థనను స్థిరమైన క్రమంలో assemble చేస్తారు: ముందుగా tools, తరువాత system, ఆపై messages. ఏ స్థాయిలో మార్పు వచ్చినా, ఆ స్థాయి మరియు దాని తరువాతి మొత్తం భాగం invalid అవుతుంది. ఒక tool వివరణను edit చేస్తే, system prompt మరియు మొత్తం message history కూడా invalid అవుతాయి. వాటిలో మీరు మార్పు చేయకపోయినా ఇదే జరుగుతుంది.

దీని నుంచి మినహాయింపులులేని ఒక నియమం వస్తుంది. Calls మధ్య మారే ప్రతిదీ, మారని ప్రతిదాని తరువాత ఉండాలి.

సాధారణంగా సమస్యకు కారణమయ్యేది timestamp. System prompt పైభాగంలో Current time: 2026-08-03T14:07:11Z ఉన్న line ప్రతి call లో prefix hash ను మార్చుతుంది. అందువల్ల hit rate 0 percent అవుతుంది. అంతకుముందు ఉన్న ఏ entry కూడా దానికి సరిపోలదు. దాన్ని user message లో చివరికి తరలించండి. Session identifier లేదా ప్రతి request కు ప్రత్యేకమైన nonce కూడా ఇదే విధంగా సమస్య కలిగిస్తాయి. వాటికీ ఇదే పరిష్కారం. ప్రతి request లో మారే retrieved documents కూడా cached block తరువాత ఉండాలి. లేకపోతే మారే boundary వెనుక ఉన్న ప్రతి స్థిరమైన token ప్రభావితమవుతుంది.

రెండవ సమస్య మారే block పైనే breakpoint ఉంచడం. Cache writes breakpoint వద్ద జరుగుతాయి. అందువల్ల ఆ block ప్రతి సారి వేరుగా ఉంటే, స్థిరమైనది ఏదీ నిల్వ చేయబడదు. Lookback కు కనిపించేది, మునుపటి requests తమ తమ మారే breakpoints వద్ద రాసిన entries మాత్రమే. Requests మధ్య content ఒకేలా ఉండే చివరి block పై cache_control ఉంచండి.

మూడవది prompt content గా మీరు పరిగణించని parameter మార్పు. వేరే model కు వేరే cache ఉంటుంది. Tool choice మార్చితే system స్థాయి నుంచి తరువాతి మొత్తం భాగం invalid అవుతుంది. Tool ను జోడించినా లేదా తొలగించినా ప్రతిదీ invalid అవుతుంది.

కనిష్ట prefix మరియు మౌన no-op

మోడల్‌కు అవసరమైన కనిష్ట పొడవుకంటే prefix తక్కువగా ఉంటే అది cache చేయబడదు. మీకు ఏ సూచన కూడా కనిపించదు. ఎలాంటి error లేదా warning ఉండదు. Request విజయవంతమవుతుంది, కానీ రెండు counters విలువలు 0గా ఉంటాయి. August 2026 నాటికి ప్రచురితమైన కనిష్ట పరిమితులు ఇవి:

• Claude Opus 5 మరియు Claude Fable 5లో 512 tokens
• Claude Sonnet 5 మరియు Claude Opus 4.8లో 1,024 tokens
• Claude Haiku 4.5లో 4,096 tokens

Cache అయిందని మీరు భావించే requestలో రెండు counters విలువలు 0గా ఉంటే, మరేదైనా పరిశీలించే ముందు prefix పొడవును తనిఖీ చేయండి. Caching workload కోసం తక్కువ ధర కలిగిన model స్వయంచాలకంగా అత్యంత చవకైనదిగా ఉండదని చెప్పడానికి ఇదే కారణం. Caching ప్రారంభం కావాలంటే Haiku 4.5కు Opus 5 కంటే ఎనిమిది రెట్లు ఎక్కువ పొడవైన prefix అవసరం. అందువల్ల 2,000 tokenల system prompt ఒక modelలో cache అవుతుంది, కానీ మరొక modelలో ఎలాంటి సమాచారం లేకుండా విస్మరించబడుతుంది.

Claude Code మీ కోసం ఎక్కడ cache చేస్తుంది, ఎక్కడ సహాయం చేయలేకపోతుంది

Claude Code తన స్వంత prefix ను cache చేస్తుంది. System prompt మరియు tool definitions ప్రతి request ప్రారంభంలోనే ఉంటాయి. అవి మారవు. అందువల్ల వాటిని ఒకసారి రాసి, session మిగతా సమయంలో తిరిగి చదువుతుంది. దీని వల్ల context size సూచించే మొత్తంతో పోలిస్తే, దీర్ఘమైన session లో ప్రతి turn కు అయ్యే ఖర్చు చాలా తక్కువగా ఉంటుంది. ఇది Claude Code token వినియోగాన్ని ఎలా నివేదిస్తుంది లో వివరించిన counters లో కనిపిస్తుంది.

Context ప్రారంభానికి సమీపంలోని భాగాన్ని సవరించినప్పుడు cache మీకు సహాయం చేయదు. Conversation history append-only గా ఉంటుంది. కాబట్టి సాధారణ కొత్త turns ఇప్పటికే cache అయిన prefix ను పొడిగిస్తాయి. Session ప్రారంభంలో చదివిన file ను సవరించినప్పుడు, ఆ prefix మధ్యలోని content మారుతుంది. అందువల్ల ఆ మార్పు తర్వాత ఉన్న ప్రతి token ను మళ్లీ రాయాలి. ఎక్కువసేపు idle గా ఉంటే కూడా ఇదే జరుగుతుంది. Entry expire అవుతుంది. తదుపరి turn లో పూర్తి write ఖర్చు అవుతుంది. ఇది bug కాదు. Prefix rule చెప్పిన విధంగానే రెండు సందర్భాల్లోనూ పనిచేస్తుంది.

మీరు మీ స్వంత client ను రాస్తుంటే, layout ను తరువాత మార్చకుండా మొదటి request నుంచే అమలు చేయండి. VPS పై మొదటి Claude API app చూపించే విధంగా call ను నిర్మించండి. Stable blocks ను ముందుగా, volatile blocks ను చివరగా ఉంచండి.

విఫల పరిస్థితులు, మీరు చూడగలిగేది

ప్రతి call ఒక write. ప్రతి request‌లో cache_creation_input_tokens non-zeroగా ఉంటుంది, అయితే cache_read_input_tokens 0గానే ఉంటుంది. Breakpoint వద్ద లేదా దాని ముందు ఉన్న ఏదో అంశం calls మధ్య మారుతోంది. వరుసగా పంపిన రెండు requests‌లో assembled prefixలోని మొదటి 200 characters‌ను print చేసి, వాటిని ప్రత్యక్షంగా పోల్చండి.

రెండు counters కూడా 0. Prefix model minimum కంటే చిన్నదిగా ఉంది, లేదా cache_control field APIకి చేరలేదు. ముందుగా prefix tokens‌ను లెక్కించండి. తరువాత మీరు వాస్తవంగా పంపిన request bodyని log చేయండి.

Reads పనిచేసి, తరువాత ఆగిపోతాయి. కొంతకాలం hits వస్తాయి, తరువాత ఒక write జరుగుతుంది, ఆపై మళ్లీ hits వస్తాయి. Requests మధ్య విరామం lifetime కంటే ఎక్కువగా ఉంది. ఆ writeని అంగీకరించండి. లేదా మీ hit rate 53 percent దాటిందని నిర్ధారించిన తరువాత 1 hour TTLకి మార్చండి.

Deploy తర్వాత hit rate తగ్గుతుంది. Tool description మార్చబడింది లేదా model మార్చబడింది. ఈ రెండూ మొత్తం prefixను invalidate చేస్తాయి. Promptను ప్రభావితం చేసే ప్రతి deploy తర్వాత writes‌తో కూడిన ఒక ఖరీదైన దశ వస్తుందని ఆశించండి.

Caching ప్రారంభించిన తర్వాత bill పెరిగింది. మీ hit rate break-even స్థాయి కంటే తక్కువగా ఉంది. 5 minute cacheలో సుమారు 22 percent కంటే తక్కువగా ఉంటే prefixను uncachedగా పంపడం చౌకగా ఉంటుంది. 1 hour cacheలో సుమారు 53 percent కంటే తక్కువగా ఉన్నా ఇదే వర్తిస్తుంది.

FAQ

prompt ను caching చేయడం లాభదాయకం కావడానికి దాన్ని ఎన్నిసార్లు మళ్లీ ఉపయోగించాలి?

5 minute cache లో ఒక్కసారి చాలు. write కు base input ఖర్చులో 1.25x, read కు 0.1x ఖర్చవుతుంది. అందువల్ల caching లేకుండా N requests కు N ఖర్చవుతుంది. caching ఉన్నప్పుడు N requests కు 1.25 plus 0.1 times N minus 1 ఖర్చవుతుంది. ఇవి N = 1.28 వద్ద సమానమవుతాయి. కాబట్టి రెండవ request నుంచే caching లాభదాయకంగా ఉంటుంది. 1 hour cache లో write ఖర్చు 2x ఉంటుంది. ఇది N = 2.11 వద్ద సమానమవుతుంది. అందువల్ల దీనికి రెండు reads అవసరం.

cache_read_input_tokens ఎల్లప్పుడూ zero ఎందుకు చూపిస్తుంది?

ముందుగా prefix length ను తనిఖీ చేయండి. model minimum కంటే తక్కువగా ఉంటే caching నిశ్శబ్దంగా skip అవుతుంది. August 2026 నాటికి ఇది Claude Opus 5 లో 512 tokens, Claude Haiku 4.5 లో 4,096 tokens. అప్పుడు రెండు counters కూడా 0గా కనిపిస్తాయి. Prefix తగినంత పొడవుగా ఉంటే, calls మధ్య మారే content breakpoint వద్ద లేదా దాని ముందు ఉందా చూడండి. ఉదాహరణకు system prompt లో timestamp లేదా session identifier ఉండవచ్చు. Counters ఇంతకుముందు పనిచేసి తరువాత ఆగితే, requests మధ్య విరామం cache lifetime కంటే ఎక్కువగా ఉంది.

prompt caching Claude సమాధానాలను మార్చుతుందా?

లేదు. మీరు ఇప్పటికే పంపిన tokens యొక్క processed form ను cache నిల్వ చేస్తుంది. Model రెండు సందర్భాల్లోనూ అదే prompt ను చూస్తుంది. ఇది billing మరియు latency feature మాత్రమే. behaviour లో మార్పు కాదు. అందువల్ల పనిచేస్తున్న prompt పై దీనిని enable చేసినా evaluations ను మళ్లీ run చేయాల్సిన అవసరం లేదు.

1 hour cache కోసం చెల్లించాలా?

మీ traffic మధ్య విరామాలు 5 minutes కంటే ఎక్కువగా ఉన్నప్పుడు మాత్రమే, మరియు మీ hit rate సుమారు 53 percent కంటే ఎక్కువగా ఉంటుందని నిర్ధారించగలిగితే చెల్లించండి. Miss అయినప్పుడు 2x write వల్ల కలిగే downside, 1.25x write కంటే రెండింతలు. 5 minute entry ప్రతి hit వద్ద refresh అవుతుంది. అందువల్ల నిరంతర traffic ఉన్నప్పుడు ఎక్కువ lifetime కోసం అదనంగా చెల్లించకుండా read ధరతోనే అది active గా ఉంటుంది.