Claude prompt caching: రెండోసారి నుంచే లాభమా?

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

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

ఇది ప్రస్తుతం చెల్లించే అదనపు రుసుముకు బదులుగా తరువాత పొందే discount. Prefix ను నిల్వ చేయడానికి ఒకసారి అదనపు మొత్తాన్ని చెల్లిస్తారు. తరువాత అదే bytesతో ఖచ్చితంగా ప్రారంభమయ్యే ప్రతి requestలో, ఆ భాగానికి సాధారణ input ధరలో పదో వంతు మాత్రమే చెల్లించాలి. Lifetimeలో తిరిగి ఉపయోగించని prefix కోసం 25 percent అదనపు ఖర్చు అవుతుంది.

బ్రేక్-ఈవెన్‌ను ఒకే బీజగణిత పంక్తిలో

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

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

క్రింది chart 20,000 token prefix కోసం ఈ ఖర్చును చూపిస్తుంది. ఇందులో Claude Opus 5ను ఉపయోగించారు. August 2026 నాటికి దీని base 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"
  }
]

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

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

తక్కువ cache hit rate వల్ల కలిగే ఖర్చు

వాస్తవ network traffic లో cache missలు జరుగుతాయి. Cache miss అయినా breakpoint ను కలిగి ఉన్న request ను write గా charge చేస్తారు. అందువల్ల hit rate ఆధారంగా cost ను లెక్కించడం సరైన పద్ధతి. క్రింది 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 లో పదో వంతు అయిన floor కు దగ్గరగా ఉంటుంది.

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

ఏ prefixలకు 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 ద్వారా $98.12 ఆదా అవుతుంది. చివరి వరుసే architecture‌ను మార్చేది: codebase లేదా transcript context‌కు చెందిన 120,000 tokens cache లేకుండా $600.00, cacheతో $129.00 ఖర్చవుతాయి. అంటే $471.00 ఆదా అవుతుంది.

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

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

క్రింది చార్ట్ పైన పేర్కొన్న 8,000 token prefix, system prompt మరియు tool definitions ను 90 percent 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. 1 million requests వద్ద caching లేకుండా input bill $40,000.00 ఉంటుంది. అందులో $31,400.00 ను caching తొలగిస్తుంది. ఇవి input tokens కు మాత్రమే సంబంధించినవి. Output కు విడిగా ధర నిర్ణయించబడుతుంది. caching దానిపై ఎలాంటి ప్రభావం చూపదు. కాబట్టి ఎవరికైనా bill 90 percent తగ్గుతుందని హామీ ఇచ్చే ముందు ఈ విషయాన్ని గుర్తుంచుకోవాలి. 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 మాత్రమే ఉంటుంది.

మీరు request.json లో save చేసిన 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 ఇలాంటి output ను చూపిస్తుంది:

{
  "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 ఖర్చు చెల్లిస్తున్నారు, కానీ దాని నుంచి ఏ cached 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 ను క్రమంగా సరిపోల్చుతుంది. అభ్యర్థన fixed order లో రూపొందుతుంది: ముందుగా tools, తరువాత system, ఆపై messages. ఏ స్థాయిలోనైనా మార్పు జరిగితే, ఆ స్థాయి మరియు దాని తరువాతి మొత్తం భాగం invalid అవుతుంది. ఒక tool description ను మాత్రమే మార్చినా, system prompt మరియు మొత్తం message history కూడా invalid అవుతాయి. వాటిని మీరు మార్చకపోయినా ఇదే జరుగుతుంది.

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

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

రెండవ సమస్య మారే block పై breakpoint ను ఉంచడం. breakpoint వద్ద cache writes జరుగుతాయి. కాబట్టి ఆ 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 lengthను పరిశీలించండి. 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 usage ను ఎలా నివేదిస్తుంది లో వివరించిన counters లో కనిపిస్తుంది.

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

బదులుగా మీరు మీ స్వంత client ను రాస్తుంటే, తరువాత layout ను మార్చే ప్రయత్నం చేయకుండా మొదటి request నుంచే సరైన నిర్మాణాన్ని ఉపయోగించండి. VPS పై మీ మొదటి Claude API app లో ఉన్న విధంగా call ను రూపొందించండి. స్థిరమైన blocks ను ముందుగా, తరచుగా మారే 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 శాతాన్ని మించిందని నిర్ధారించిన తరువాత 1 hour TTL కు మార్చండి.

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

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

FAQ

కాషింగ్ వల్ల ప్రయోజనం పొందడానికి ఒక prompt ను ఎన్ని సార్లు మళ్లీ ఉపయోగించాలి?

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

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

ముందుగా prefix length ను తనిఖీ చేయండి: model minimum కంటే తక్కువగా ఉంటే caching నిశ్శబ్దంగా skip అవుతుంది. August 2026 నాటికి Claude Opus 5 కు కనిష్ఠం 512 tokens, Claude Haiku 4.5 కు 4,096 tokens. ఈ పరిస్థితిలో రెండు counters కూడా 0 చూపిస్తాయి. Prefix తగినంత పొడవుగా ఉంటే, breakpoint వద్ద లేదా దాని ముందు calls మధ్య మారే content ఉందో చూడండి. ఉదాహరణకు 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 కంటే ఎక్కువ gaps ఉన్నప్పుడు మాత్రమే, అలాగే మీ hit rate సుమారు 53 percent కంటే ఎక్కువగా ఉంటుందని భావించినప్పుడు చెల్లించండి. Cache miss అయినప్పుడు 2x write, 1.25x write కంటే రెండింతల ప్రతికూల ప్రభావాన్ని కలిగిస్తుంది. 5 minute entry ప్రతి hit సమయంలో refresh అవుతుంది. కాబట్టి నిరంతర traffic ఉన్నప్పుడు, ఎక్కువ lifetime కోసం అదనంగా చెల్లించకుండా read ధరలకే అది సజీవంగా ఉంటుంది.