Claude prompt caching: break-even कधी होते?

कॅशिंगमुळे बचत होण्यापूर्वी prompt caching ची किंमत

Prompt caching मुळे Claude ला प्रत्येक call वेळी prompt चा सुरुवातीचा भाग पुन्हा वाचण्याऐवजी तो पुन्हा वापरता येतो. हा निर्णय तुमच्या model च्या base input price वर लागू होणाऱ्या दोन multipliers वर अवलंबून असतो. August 2026 नुसार, 5 minute lifetime साठी cache write ची किंमत base input च्या 1.25x असते. 1 hour lifetime साठी ती 2x असते. Cache read ची किंमत 0.1x असते. हे multipliers model list मधील सर्व models साठी समान असतात. त्यामुळे per-token price बदलला तरी खालील break-even point बदलत नाही.

यामध्ये सध्याचा surcharge आणि नंतर मिळणारी discount यांचा trade-off असतो. Prefix store करण्यासाठी तुम्ही एकदा अतिरिक्त शुल्क देता. त्यानंतरच्या प्रत्येक request ची सुरुवात अगदी त्याच bytes ने होत असल्यास, त्या भागासाठी normal input price च्या एक-दशांश इतकीच किंमत द्यावी लागते. Prefix त्याच्या lifetime मध्ये एकदाही पुन्हा वापरला गेला नाही, तर त्यासाठी विनाकारण 25 percent अतिरिक्त खर्च होतो.

एका बीजगणितीय समीकरणात break-even

Prefix uncached पाठवल्यास त्याची base input cost 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 न करण्यापेक्षा आधीच स्वस्त असते.

1 hour cache च्या 2x write साठी हीच गणना केल्यास 0.9N = 1.9 मिळते, म्हणजे N = 2.11. Long cache ला break-even होण्यासाठी दोन reads लागतात. म्हणून तो default choice नाही.

खालील chart मध्ये Claude Opus 5 वरील 20,000 token prefix ची किंमत दाखवली आहे. August 2026 नुसार त्याचा base input rate प्रति million tokens $5 आहे. प्रति million $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 ची किंमत $0.10 uncached आणि $0.125 cached असते. त्यामुळे one-shot prompt चे caching केल्यास थेट तोटा होतो. दुसऱ्या request पर्यंत 5 minute cache ची किंमत $0.135 असते, तर uncached किंमत $0.20 असते. त्या वेळी 1 hour cache अजून महाग असतो: $0.21, तर तीच uncached किंमत $0.20 असते. तिसऱ्या request वरच तो uncached किंमतीपेक्षा कमी होतो: $0.22 विरुद्ध $0.30. 20 requests पर्यंत हा फरक $2.00 विरुद्ध $0.315 इतका असतो.

Cache hit मुळे entry refresh देखील होते. म्हणून प्रकाशित price table मध्ये त्या column ला cache hits and refreshes असे नाव दिले आहे. त्यामुळे व्यस्त endpoint 5 minute entry read prices वर अनिश्चित काळ जिवंत ठेवतो. Traffic मध्ये प्रत्यक्ष gaps असतील, तेव्हाच 1 hour lifetime च्या 2x write चा फायदा मिळतो.

कमी hit rate मुळे होणारा खर्च

प्रत्यक्ष network traffic मध्ये cache misses होतात. Cache miss झालेल्या request मध्ये breakpoint असला, तरी तिचे write म्हणून शुल्क आकारले जाते. त्यामुळे hit rate च्या फलनानुसार खर्च मोजणे ही योग्य पद्धत आहे. खालील 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 चे instrumentation करणे आवश्यक आहे.

कोणते prefixes breakpoint साठी उपयुक्त आहेत

एका request मध्ये जास्तीत जास्त चार cache breakpoints असू शकतात. त्यामुळे कोणत्या blocks साठी breakpoint ठेवावा हा प्रश्न आहे. जे blocks प्रत्येक call मध्ये byte-identical असतात आणि पुरेसे मोठे असतात, ते यासाठी योग्य उमेदवार आहेत. खालील chart 5 minute cache वर 90 percent hit rate गृहीत धरून 1,000 requests साठी चार सामान्य आकारांची किंमत दाखवतो.

[
  {
    "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 वाचवतो. मोठ्या प्रमाणावर ही लक्षणीय बचत आहे; परंतु caching महत्त्वाचे ठरण्याचे हे एकमेव कारण नाही. Tool definitions जोडल्यावर आकार 8,000 tokens होतो आणि बचत $31.40 होते. प्रत्येक request मध्ये ज्याबद्दल प्रश्न विचारले जातात अशा 25,000 token policy document मुळे $98.12 बचत होते. शेवटची row architecture बदलते: codebase किंवा transcript context चे 120,000 tokens cache नसताना $600.00 आणि cache असताना $129.00 खर्च करतात. त्यामुळे बचत $471.00 होते.

बचत prefix च्या आकारासोबत आणि hit rate सोबत वाढते. इतर कोणत्याही घटकामुळे ती वाढत नाही. त्यामुळे prompt मध्ये कोणती माहिती ठेवणे योग्य आहे याबाबतचा निर्णय बदलतो: दशलक्ष Claude tokens ची प्रत्यक्ष किंमत तुम्ही एकापेक्षा जास्त वेळा पाठवता त्या सर्व गोष्टींसाठी दर्शविलेल्या किंमतीच्या एकदशांशापर्यंत खर्च कमी करते.

मासिक बिलवर हे कसे दिसते

खालील चार्ट वरील 8,000 token prefix, system prompt आणि tool definitions यांचा 90 percent hit rate गृहीत धरतो आणि त्याचे मासिक request volumes नुसार प्रमाण वाढवतो.

[
  {
    "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 असताना uncached input bill $40,000.00 असतो आणि caching मुळे त्यातील $31,400.00 इतका खर्च वाचतो. हे केवळ input tokens साठी आहे. Output ची किंमत स्वतंत्रपणे आकारली जाते आणि caching चा त्यावर कोणताही परिणाम होत नाही. त्यामुळे कोणालाही बिलात 90 percent कपात होईल असे आश्वासन देण्यापूर्वी ही बाब लक्षात ठेवा. VPS वर AI agent चा बिलावरील खर्च नियंत्रणात ठेवण्यासाठी caching ही व्यापक पद्धतींसोबत वापरता येते: VPS वर AI agent चा बिलावरील खर्च नियंत्रणात ठेवणे.

कॅशे कार्यरत असल्याचे कसे सिद्ध करावे

डिझाइनवर अवलंबून राहू नका. प्रतिसादातील usage block वाचा. प्रत्येक Messages API (application programming interface) प्रतिसादात त्याने लिहिलेले cached tokens, वाचलेले cached tokens आणि नव्याने प्रक्रिया करावे लागलेले 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 वापरून ते दोनदा चालवा. पहिल्या call मध्ये non-zero cache_creation_input_tokens आणि zero cache_read_input_tokens दिसते. दुसऱ्या call मध्ये याच्या उलट दिसते, कारण prefix सापडलेला असतो. input_tokens मध्ये शेवटच्या breakpoint नंतरचे tokensच मोजले जातात. त्यामुळे निरोगी दुसऱ्या call मध्ये त्याची संख्या कमी असते. साधारणपणे त्यात फक्त नवीन user message असतो.

तुम्ही 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 मध्ये साधारणपणे असे output दिसते:

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

एक ओळ खरी स्थिती सांगते. Calls दरम्यान cache_read_input_tokens 0 वरच राहिल्यास, प्रत्येक वेळी तुम्ही 1.25x write साठी पैसे देत आहात आणि त्या बदल्यात काहीही परत मिळत नाही.

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 दिल्यानंतर API conversation वाढत असताना breakpoints व्यवस्थापित करते. यासाठी तुमच्या चार breakpoint slots पैकी एक वापरला जातो. सुरुवात यापासून करा. Boundary नेमकी कुठे असावी हे ठरवायचे असल्यास explicit breakpoints वापरा.

हिट रेट कमी करणारा क्रम नियम

कॅशे विनंतीच्या सुरुवातीपासून byte-by-byte prefix जुळवतो. विनंती ठरावीक क्रमाने तयार केली जाते: प्रथम tools, त्यानंतर system आणि शेवटी messages. कोणत्याही स्तरावर केलेला बदल त्या स्तराला आणि त्यानंतरच्या सर्व स्तरांना invalid करतो. एका tool चे वर्णन संपादित केल्यास system prompt आणि संपूर्ण message history देखील invalid होतात, जरी त्यांच्यात थेट बदल केलेला नसला तरी.

यातून कोणताही अपवाद नसलेला एक नियम मिळतो. प्रत्येक call दरम्यान बदलणारी कोणतीही गोष्ट, न बदलणाऱ्या सर्व गोष्टींनंतर ठेवली पाहिजे.

सामान्यतः ही समस्या timestamp मुळे उद्भवते. system prompt च्या सुरुवातीला Current time: 2026-08-03T14:07:11Z असलेली ओळ प्रत्येक call साठी 0 percent hit rate निश्चित करते, कारण प्रत्येक call मध्ये prefix hash वेगळा असतो आणि त्यापूर्वीची कोणतीही entry त्याच्याशी कधीही जुळू शकत नाही. ती ओळ user message मध्ये, शेवटी हलवा. session identifier किंवा per-request nonce देखील याच प्रकारे अडथळा निर्माण करतात आणि त्यांच्यासाठीही हाच उपाय आहे. प्रत्येक request नुसार बदलणारी retrieved documents देखील cached block नंतर ठेवली पाहिजेत. अन्यथा बदलणाऱ्या boundary च्या मागे असलेला प्रत्येक स्थिर token cache मधून बाहेर ढकलला जातो.

दुसरी समस्या बदलणाऱ्या block वर breakpoint ठेवणे ही आहे. Cache writes breakpoint वर होतात. त्यामुळे तो block प्रत्येक वेळी वेगळा असल्यास कोणतीही स्थिर माहिती साठवली जात नाही. Lookback ला फक्त आधीच्या requests ने त्यांच्या स्वतःच्या बदलत्या breakpoints वर लिहिलेल्या entries सापडतात. Requests मध्ये content समान असलेल्या शेवटच्या block वर cache_control ठेवा.

तिसरी समस्या prompt content मानला नाही असा parameter change आहे. वेगळ्या model साठी वेगळा cache असतो. tool choice बदलल्यास system स्तरापासून पुढील सर्व content invalid होते. एखादा tool जोडल्यास किंवा काढल्यास सर्व content 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

ज्या request चा cache वापरला गेला आहे असे तुम्हाला वाटते, त्या request मध्ये दोन्ही counters चे मूल्य 0 असल्यास इतर काहीही तपासण्यापूर्वी prefix ची लांबी तपासा. Caching workload साठी सर्वात स्वस्त model आपोआप सर्वात किफायतशीर असेलच असे नाही, याचे हेच कारण आहे. Caching सक्रिय होण्यासाठी Haiku 4.5 ला Opus 5 पेक्षा आठपट मोठा prefix आवश्यक असतो. त्यामुळे 2,000 tokens चा 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 मध्ये फक्त नवीन मजकूर जोडला जातो. त्यामुळे नेहमीचे नवीन turns आधीच cached असलेल्या prefix ला पुढे वाढवतात. Session च्या सुरुवातीला वाचलेल्या file मध्ये बदल केल्यास त्या prefix च्या मध्यभागी असलेला content बदलतो. त्या बदलानंतरचा प्रत्येक token पुन्हा लिहावा लागतो. बराच idle gap असल्यासही हेच होते, कारण entry ची मुदत संपते आणि पुढील turn मध्ये पूर्ण write करावा लागतो. यापैकी कोणतीही गोष्ट bug नाही. Prefix rule जसे सांगते तसेच दोन्ही बाबतीत कार्य करते.

त्याऐवजी तुम्ही स्वतःचा client लिहित असाल, तर layout नंतर बदलण्याऐवजी पहिल्या request पासूनच लागू करा. VPS वर पहिले Claude API app तयार करणे याप्रमाणे call तयार करा. Stable blocks आधी आणि volatile blocks शेवटी ठेवा.

अपयशाच्या स्थिती आणि त्यात दिसणारे परिणाम

प्रत्येक call ही write असते. प्रत्येक request वर cache_creation_input_tokens शून्येतर असते, तर cache_read_input_tokens 0 राहते. Breakpoint वर किंवा त्यापूर्वीची एखादी गोष्ट calls दरम्यान बदलत आहे. सलग दोन requests वर तयार केलेल्या prefix मधील पहिले 200 characters print करा आणि त्यांची प्रत्यक्ष तुलना करा.

दोन्ही counters 0 आहेत. Prefix model च्या किमान लांबीपेक्षा लहान आहे किंवा cache_control field API पर्यंत पोहोचलेले नाही. प्रथम prefix tokens ची संख्या मोजा. त्यानंतर तुम्ही प्रत्यक्ष पाठवलेला request body log करा.

Reads चालतात आणि नंतर थांबतात. काही hits मिळतात, त्यानंतर एक write होते आणि मग पुन्हा hits मिळतात. Requests मधील अंतर cache lifetime पेक्षा जास्त होते. Write स्वीकारा किंवा hit rate 53 percent पेक्षा जास्त असल्याची खात्री केल्यानंतर 1 hour TTL वर जा.

Deploy नंतर hit rate कमी होतो. Tool description संपादित केले गेले आहे किंवा model बदलला आहे. या दोन्ही बदलांमुळे संपूर्ण prefix invalid होतो. Prompt वर परिणाम करणाऱ्या प्रत्येक deploy नंतर writes ची एक महाग फेरी होईल, अशी अपेक्षा ठेवा.

Caching enable केल्यानंतर bill वाढले. तुमचा hit rate break-even पेक्षा कमी आहे. 5 minute cache वर सुमारे 22 percent पेक्षा कमी hit rate असल्यास prefix uncached पाठवणे स्वस्त ठरते. 1 hour cache साठी सुमारे 53 percent पेक्षा कमी hit rate असल्यास हेच लागू होते.

FAQ

कॅशिंगचा खर्च वसूल होण्यासाठी prompt किती वेळा पुन्हा वापरावा लागतो?

5 minute cache मध्ये एकदाच. Write साठी base input च्या 1.25x इतका खर्च येतो आणि read साठी 0.1x इतका खर्च येतो. त्यामुळे N uncached requests साठी खर्च N इतका असतो, तर N cached 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 ची लांबी तपासा. Model minimum पेक्षा कमी असल्यास caching शांतपणे वगळले जाते आणि दोन्ही counters 0 दाखवतात. August 2026 नुसार Claude Opus 5 साठी ही मर्यादा 512 tokens आणि Claude Haiku 4.5 साठी 4,096 tokens आहे. Prefix पुरेसा मोठा असल्यास breakpoint वर किंवा त्यापूर्वी calls दरम्यान बदलणारी content आहे का ते तपासा. उदाहरणार्थ, system prompt मधील timestamp किंवा session identifier तपासा. Counters पूर्वी कार्यरत होते आणि नंतर थांबले असल्यास requests मधील अंतर cache lifetime पेक्षा जास्त होते.

prompt caching मुळे Claude ची उत्तरे बदलतात का?

नाही. Cache तुम्ही आधी पाठवलेल्या tokens चे processed form साठवते. त्यामुळे cache वापरला किंवा नाही तरी model ला तोच prompt दिसतो. हे billing आणि latency साठीचे feature आहे; behaviour बदलणारे feature नाही. त्यामुळे कार्यरत prompt वर ते enable केल्यानंतर evaluations पुन्हा चालवण्याची गरज नसते.

1 hour cache साठी पैसे द्यावेत का?

तुमच्या traffic मध्ये 5 minutes पेक्षा जास्त अंतर असेल आणि hit rate साधारण 53 percent पेक्षा जास्त राहणार असेल, तरच. Miss झाल्यावर 2x write मुळे 1.25x write च्या तुलनेत downside दुप्पट असतो. 5 minute entry प्रत्येक hit वर refresh होते. त्यामुळे स्थिर traffic असल्यास जास्त lifetime साठी अतिरिक्त खर्च न करता ती read prices वर सक्रिय राहते.