OpenAI और Claude की prompt caching: कैसे काम करती है, TTL, कीमत, काम न करने के कारण और जाँच का तरीका

Prompt caching किसी request के उस हिस्से की गणना दोबारा इस्तेमाल करती है जो पिछली request की शुरुआत (prefix) से हूबहू मेल खाता है, ताकि input का वह हिस्सा सस्ते में और तेज़ी से प्रोसेस हो। OpenAI API और Claude API दोनों में यह सुविधा है, लेकिन इसे चालू कैसे करें, cache कितनी देर टिकता है, cache में write करने की कीमत क्या है और यह काम कर रही है या नहीं, यह कैसे जाँचें — इन सब में दोनों के बीच बड़ा फ़र्क है। अगर आप दोनों के लिए एक जैसी मान्यताओं से डिज़ाइन करते हैं, तो हो सकता है कि एक तरफ़ caching ठीक चले और दूसरी तरफ़ आप हर request पर write की कीमत चुकाते रहें, पर एक भी hit न मिले।

यह लेख OpenAI के "Prompt caching", "Prompt cache diagnostics" और "Pricing" तथा Anthropic के "Prompt caching", "Cache diagnostics", "Pricing" और "Rate limits" दस्तावेज़ों के मूल पाठ के आधार पर OpenAI और Anthropic की prompt caching की तुलना करता है। इसमें बताया गया है कि दोनों के specs में क्या अंतर है, cache hit कैसे पाएँ और कैसे पक्का करें कि hit मिल रहे हैं। हर आँकड़ा 3 अक्टूबर 2026 को मूल पेजों से मिलाया गया। API की लागत घटाने की बड़ी तस्वीर (मॉडल चुनना, batch processing, output पर नियंत्रण आदि) के लिए हमारा अलग लेख "AI token लागत बचत" देखें।

1. Prompt caching क्या है: एक जैसे prefix का दोबारा इस्तेमाल

भाषा मॉडल जब भी अपना input पढ़ता है, वह हर token के लिए बीच के मान (KV, यानी key और value tensors) निकालता है। Prompt caching इन मानों को prompt की शुरुआत से एक तय बिंदु तक सहेज लेती है, और जब अगली request ठीक उन्हीं tokens से शुरू होती है तो यह गणना छोड़ देती है। OpenAI की गाइड बताती है कि सहेजे जाने वाले KV मान होते हैं, tokens ख़ुद नहीं।

मुख्य बात यह है कि सिर्फ़ वही हिस्सा दोबारा इस्तेमाल हो सकता है जो बिल्कुल शुरुआत से मेल खाता हो। नीचे की दो requests में सिर्फ़ निर्देश और दस्तावेज़ ही दोबारा इस्तेमाल हो सकते हैं।

Request 1: [निर्देश 5,000 tokens][दस्तावेज़ 20,000 tokens][प्रश्न A]
Request 2: [निर्देश 5,000 tokens][दस्तावेज़ 20,000 tokens][प्रश्न B]
           └──────────── यहाँ तक बिल्कुल एक जैसा ────────────┘└ अलग ┘
→ निर्देश + दस्तावेज़ के 25,000 tokens दोबारा इस्तेमाल हो सकते हैं

Request 3: [आज की तारीख़][निर्देश 5,000 tokens][दस्तावेज़ 20,000 tokens][प्रश्न C]
           └─── अलग ───┘
→ बाक़ी सब मेल खाने पर भी एक भी token दोबारा इस्तेमाल नहीं हो सकता

दोनों कंपनियों के दस्तावेज़ कहते हैं कि caching output की सामग्री नहीं बदलती। यह पिछला जवाब सहेजकर दोबारा नहीं चलाती; बस input पढ़ने का काम बचाती है। इसलिए यह उन chats में भी काम आती है जहाँ हर सवाल अलग हो, और उन agents में भी जो हर बार अलग दस्तावेज़ पढ़ते हैं — बशर्ते कोई साझा prefix हो (निर्देश, tool definitions, बातचीत का इतिहास)।

2. OpenAI और Anthropic की prompt caching: आमने-सामने

22 सितंबर 2026 को OpenAI ने GPT-6 के लिए caching सुधारों की घोषणा की, और GPT-5.6 व उसके बाद के मॉडलों के लिए तंत्र बदल गया (30 मिनट की retention, explicit breakpoints, cache write पर शुल्क आदि)। नीचे की तालिका में OpenAI वाला कॉलम GPT-5.6 और उसके बाद के मॉडलों का है। GPT-5.5 और पहले के मॉडलों के अंतर तालिका के बाद दिए गए हैं।

स्रोत: OpenAI "Prompt caching", "Prompt cache diagnostics"; Anthropic "Prompt caching", "Cache diagnostics", "Rate limits" (3 अक्टूबर 2026 को जाँचा गया)

GPT-5.5 और पहले के मॉडलों में सिर्फ़ implicit caching है, जिसमें breakpoints तय अंतराल पर अपने-आप लगते हैं, और cache write पर कोई अतिरिक्त शुल्क नहीं है। Retention prompt_cache_retention से तय होती है: गाइड के अनुसार in_memory "लगभग 5 से 10 मिनट की निष्क्रियता, अधिकतम 1 घंटा" तक और 24h "आम तौर पर लगभग 30 मिनट, अधिकतम 24 घंटे" तक रहता है। GPT-5.6 या उसके बाद के मॉडल पर जाते समय इस setting को prompt_cache_options.ttl से बदलें।

हर मॉडल की प्रति-token कीमतें हमारी तुलना "Claude vs ChatGPT कीमत तुलना" में हैं। GPT-6 मॉडलों (Astra, Sol, Luna) के लिए "GPT-6 Sol और Luna पर हमारा लेख" और सभी कंपनियों के मौजूदा मॉडलों के लिए "AI मॉडलों की नॉलेज कटऑफ़ तारीख़ें" देखें।

3. Cache कब hit होता है: prefix, न्यूनतम लंबाई, TTL और दायरा

साझा prefix और request का क्रम

दोनों प्लेटफ़ॉर्म पर cache तभी hit होता है जब breakpoint तक का prefix हूबहू मेल खाए। Claude request को शुरुआत से tools → system → messages के क्रम में पढ़ता है, इसलिए एक भी tool definition बदलने से उसके बाद आने वाले system prompt और बातचीत के इतिहास का cache अमान्य हो जाता है। OpenAI भी बताता है कि tool definitions, output format (text.format), reasoning effort (reasoning.effort) जैसी settings prefix का हिस्सा हैं।

व्यवहार में दोनों के लिए ढाँचा एक ही है: जो नहीं बदलता (tool definitions, निर्देश, दस्तावेज़) उसे पहले रखें, और जो हर request में बदलता है (तारीख़ें, हर user का डेटा, सवाल) उसे आख़िर में। बातचीत को आगे बढ़ाने के लिए इतिहास दोबारा लिखे बिना अंत में जोड़ते जाएँ।

Breakpoints लगाना: अपने-आप या हाथ से

OpenAI का implicit mode (GPT-5.6 और उसके बाद) breakpoint को सबसे नए योग्य message (user message, लगातार आए tool results में आख़िरी वाला आदि) के अंत में लगाता है। सिर्फ़-explicit mode में सिर्फ़ वे जगहें breakpoint बनती हैं जहाँ आप prompt_cache_breakpoint जोड़ते हैं, और अगर आप एक भी नहीं जोड़ते, तो cache इस्तेमाल नहीं होता और write की कीमत भी नहीं लगती।

Claude की automatic caching, जो top level पर एक "cache_control": {"type": "ephemeral"} से चालू होती है, breakpoint को आख़िरी cache होने लायक block पर लगाती है और बातचीत बढ़ने के साथ उसे आगे खिसकाती है। अलग-अलग blocks में cache_control जोड़कर आप breakpoints ख़ुद चुन सकते हैं।

// Claude: न बदलने वाले system prompt के अंत में breakpoint (explicit breakpoint)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "लंबे निर्देश और दस्तावेज़...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "आज का सवाल..." }]
}

// OpenAI (Responses API): न बदलने वाले निर्देशों के बाद breakpoint, सिर्फ़-explicit mode
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "लंबे निर्देश और दस्तावेज़...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "आज का सवाल..." }
  ]
}

न्यूनतम लंबाई: छोटे prefix cache नहीं होते

GPT-5.6 और उसके बाद के लिए OpenAI की न्यूनतम सीमा दिखने वाले input के 1,024 tokens है (OpenAI पर्दे के पीछे जो छिपे निर्देश जोड़ता है, वे नहीं गिने जाते)। Claude में यह मॉडल पर निर्भर करती है।

स्रोत: Anthropic "Prompt caching", Cache limitations (3 अक्टूबर 2026 को जाँचा गया)। Bedrock पर AWS के दस्तावेज़ों के मान लागू होते हैं।

अगर Claude का prompt न्यूनतम से छोटा है, तो cache_control जोड़ने पर कोई error नहीं आता; prompt बस चुपचाप cache नहीं होता। ऐसे में usage में cache_creation_input_tokens और cache_read_input_tokens दोनों 0 होते हैं। मॉडल बदलने पर न्यूनतम सीमा भी बदलती है, इसलिए जो prefix पिछले मॉडल पर cache होता था, वह अब cache होना बंद हो सकता है (OpenAI की गाइड भी यही चेतावनी देती है)।

TTL: घड़ी कब से चलती है, इस पर ध्यान दें

OpenAI (GPT-5.6 और उसके बाद) में cache "आख़िरी write या reuse के बाद कम से कम 30 मिनट रहता है, और इससे ज़्यादा भी रह सकता है"। Claude में डिफ़ॉल्ट 5 मिनट है, और 1 घंटा चुनने पर write की कीमत input कीमत की 2x हो जाती है। दोनों प्लेटफ़ॉर्म पर हर बार cache इस्तेमाल होने पर TTL बिना अतिरिक्त शुल्क के रीफ़्रेश होता है।

Claude में एक जाल है: TTL response के अंत से नहीं, request की शुरुआत से गिना जाता है। दस्तावेज़ों के उदाहरण में, अगर किसी response को बनने में 4 मिनट लगते हैं, तो 5 मिनट वाले cache को hit करने के लिए अगली request उस response के ख़त्म होने के लगभग 1 मिनट के भीतर शुरू होनी चाहिए। लंबा output बनाने वाले agents के लिए 5 मिनट दिखने से कम है।

Cache का दायरा और वह कहाँ रहता है

OpenAI का cache प्रति organization होता है और processing regions (data residency settings) के बीच साझा नहीं होता। गाइड यह भी कहती है कि cache अलग-अलग machines पर रहता है, और लगभग 15 requests प्रति मिनट से ऊपर, requests किसी दूसरी machine पर route हो सकती हैं। GPT-5.6 से OpenAI routing अपने-आप संभालता है, और prompt_cache_key अब hit rate बढ़ाने का तरीका नहीं, बल्कि ग्राहक के हिसाब से cache reporting अलग करने की एक वैकल्पिक setting बन गई है (GPT-5.5 और पहले के मॉडलों में एक ही key से requests को एक ही machine पर भेजना मायने रखता था)।

Claude API cache को प्रति workspace सीमित करता है। एक ही organization के भीतर अलग-अलग workspaces एक जैसे prompts होने पर भी cache साझा नहीं करते। Bedrock और Google Cloud पर यह प्रति organization है। साथ ही, cache तभी उपलब्ध होता है जब पहला response शुरू हो जाए, इसलिए अगर आप एक ही prefix वाली कई requests एक साथ parallel में भेजते हैं, तो पहली request के cache लिखने से पहले बाक़ी सब भी writes बन जाती हैं।

4. कीमत और break-even: caching फ़ायदेमंद होने के लिए कितने read चाहिए

क्योंकि cache write सामान्य input से महँगा है, जो cache entry लिखी जाए और कभी पढ़ी न जाए, वह caching न करने से ज़्यादा महँगी पड़ती है। मान लीजिए w write का गुणक है, r read का गुणक और n write के बाद reads की संख्या। Break-even के लिए ज़रूरी reads इन सूत्रों से निकलते हैं।

Caching के साथ  = w + n × r
Caching के बिना = 1 + n          (एक ही prefix को n + 1 बार वैसे ही भेजना)
फ़ायदा तब       : n > (w − 1) ÷ (1 − r)

गुणक input कीमत को 1 मानकर। OpenAI "Prompt caching" व "Pricing" और Anthropic "Pricing" से गणना (3 अक्टूबर 2026 को जाँचा गया)। सिर्फ़ prefix की तुलना है; output और हर request का सवाल शामिल नहीं।

OpenAI की गाइड में 0.1x वाले मॉडल के लिए यही गणना है: एक बार write और एक बार read की कीमत 1.35x है, जबकि बिना caching दो बार प्रोसेस करने पर 2x। Anthropic का pricing पेज भी कहता है कि 5 मिनट वाला cache एक read के बाद और 1 घंटे वाला दो reads के बाद फ़ायदेमंद होता है। Read चाहे कितना भी सस्ता हो, 1 घंटे का cache एक read से फ़ायदेमंद नहीं हो सकता, क्योंकि 2x का write बहुत भारी है।

एक जैसी input कीमत वाले मॉडलों की तुलना: requests का अंतराल नतीजा पलट देता है

3 अक्टूबर 2026 की आधिकारिक कीमतों पर GPT-6.1 Sol और Claude Sonnet 5.5 दोनों प्रति 10 लाख input tokens $2 लेते हैं, और 5 मिनट वाले write की कीमत भी दोनों की $2.50 है। फ़र्क read की कीमत (Sol $0.10, Sonnet 5.5 $0.20) और TTL में है। हमने 100,000 tokens का prefix अलग-अलग अंतराल पर 10 बार भेजने पर prefix की लागत निकाली।

कीमतें OpenAI "Pricing" (Standard, 272K तक) और Anthropic "Pricing" से (दोनों 3 अक्टूबर 2026 को जाँची गईं)। 100,000 tokens = 0.1 (10 लाख tokens की इकाई में)। Hit होने पर पहली request write है और बाक़ी 9 reads; miss होने पर सभी 10 writes। OpenAI में machine routing जैसे कारणों से भी miss हो सकता है, इसलिए hit वाली पंक्तियाँ अनुकूल हालात के मान हैं।

उदाहरण के लिए, हर 3 मिनट पर GPT-6.1 Sol की लागत "0.1 × $2.50 (एक write) + 0.1 × $0.10 × 9 reads = $0.25 + $0.09 = $0.34" बनती है। तालिका तीन बातें दिखाती है।

• 5 मिनट या उससे कम अंतराल पर दोनों का फ़र्क छोटा है ($0.34 बनाम $0.43)। यह सिर्फ़ read की कीमत पर टिका है।
• 5 से 30 मिनट के अंतराल पर OpenAI का 30 मिनट वाला TTL जीतता है। Claude के 5 मिनट वाले TTL में हर request write बन जाती है और $2.50 लगते हैं, जो बिना cache से भी ज़्यादा है। 1 घंटे पर जाने से यह $0.58 रह जाता है।
• जब अंतराल TTL से ज़्यादा हो, caching घाटे का सौदा है। हर 2 घंटे पर बिना cache के $2.00 सबसे सस्ता है। Claude में cache_control न लगाएँ; OpenAI GPT-5.6 और उसके बाद में सिर्फ़-explicit mode इस्तेमाल करें और कोई breakpoint न लगाएँ, तो write का शुल्क बच जाता है।

ख़ास तौर पर, क्योंकि OpenAI GPT-5.6 और उसके बाद में caching डिफ़ॉल्ट रूप से चालू है, implicit mode में बने रहने का मतलब उस input के लिए भी write की कीमत चुकाना हो सकता है जिसे आप दोबारा कभी नहीं भेजेंगे। अगर आपका workload बहुत सारे लंबे, एक-बार वाले inputs भेजता है, तो usage में cache_write_tokens देखें और तय करें कि सिर्फ़-explicit mode पर जाना है या नहीं।

Caching बाक़ी pricing के साथ कैसे जुड़ती है

• Batch: OpenAI की price list में Batch और Flex के लिए भी cached input और cache write की कीमतें हैं (Batch पर GPT-6.1 Sol: input $1, cache read $0.05, cache write $1.25)। Anthropic कहता है कि cache के गुणक batch की 50% छूट के साथ जुड़ते हैं, लेकिन क्योंकि batch requests parallel में और बिना तय क्रम के प्रोसेस होती हैं, वह cache hits को "best effort" (बिना गारंटी) बताता है।
• लंबे inputs: OpenAI पर जब input 272K tokens से ज़्यादा होता है, तो input, cache read और cache write तीनों की कीमत दोगुनी हो जाती है (गुणक वही रहते हैं)। Anthropic पर Claude 4.6 और उसके बाद के मॉडल 10 लाख tokens तक एक ही कीमत लेते हैं।
• Prewarming: दोनों में prewarm write पर सामान्य write की कीमत लगती है। Claude के max_tokens: 0 पर output का शुल्क नहीं लगता।

5. Prompt caching काम क्यों नहीं कर रही: आम कारण

दोनों कंपनियों की आम ग़लतियों वाली टिप्पणियों और उनके diagnostics से लौटने वाले कारणों की सूचियों को मिलाकर देखें, तो cache miss के कारण मोटे तौर पर तीन समूहों में बँटते हैं।

OpenAI में आम समस्याएँ

• साझा prefix के ठीक बाद कोई breakpoint नहीं: implicit mode breakpoint को सबसे नए message के अंत में लगाता है, इसलिए "तय निर्देश + हर बार अलग user message" में बदलने वाला हिस्सा भी write हो जाता है और अगली request miss होती है। तय हिस्से के ठीक बाद explicit breakpoint लगाएँ।
• बीच में सिर्फ़-explicit mode पर जाना: सिर्फ़-explicit mode केवल आपके लगाए breakpoints ढूँढ़ता है, इसलिए implicit mode में लिखी गई cache entries पर hit नहीं होता।
• उसी message में जोड़ते जाना: अगर कोई message जो "सामग्री A" पर ख़त्म होता था, अब "सामग्री A + सामग्री B" बन जाए, तो पिछला breakpoint message के बीच में आ जाता है और miss होता है। नई सामग्री नए message के रूप में जोड़ें।
• बीच में reasoning effort बदलना: GPT-6 मॉडलों में request का reasoning.effort वैसा ही छोड़कर input के बाद configuration_update जोड़ने से cache तोड़े बिना effort बदला जा सकता है।
• Compaction (context compression) चलाना: prefix बदलता है, इसलिए hit rate गिरता है। फिर भी गाइड बताती है कि input छोटा होने से कुल लागत घट सकती है, और कुल लागत की तुलना करने की सलाह देती है।

Claude में आम समस्याएँ

• हर बार बदलने वाले block पर breakpoint: writes सिर्फ़ breakpoint की जगहों पर होते हैं, और reads सिर्फ़ पीछे की ओर पिछली write की जगहें ढूँढ़ते हैं। अगर breakpoint हर बार बदलने वाले block पर है, तो आप हर बार write की कीमत चुकाते हैं और कभी hit नहीं मिलता। Automatic caching भी breakpoint आख़िरी block पर लगाती है, इसलिए वह भी इसी जाल में फँसती है। आख़िरी न बदलने वाले block पर explicit breakpoint लगाएँ।
• एक turn में 20 या ज़्यादा blocks जुड़ना: पिछली writes की खोज breakpoint से पीछे की ओर 20 जगहों तक ही होती है। अगर बातचीत एक साथ बहुत बढ़ जाए, तो पिछली write इस दायरे से बाहर चली जाती है। Prompt में पहले की ओर एक अतिरिक्त breakpoint रखें।
• बीच में system prompt दोबारा लिखना: समर्थित मॉडलों पर top-level system को जस का तस छोड़कर messages के भीतर "role": "system" वाला message जोड़ने से cache तोड़े बिना निर्देश जोड़े जा सकते हैं।
• Fast mode (speed: "fast") और standard के बीच बदलना: इससे system और बातचीत का cache अमान्य हो जाता है।

6. Cache hit कैसे जाँचें: usage और diagnostics

शुरुआत usage से करें: input_tokens का मतलब अलग है

दोनों प्लेटफ़ॉर्म पर response का usage बताता है कि cache से कितना पढ़ा गया और उसमें कितना लिखा गया। ध्यान देने वाली बात यह है कि input_tokens का मतलब दोनों प्लेटफ़ॉर्म पर उल्टा है।

स्रोत: OpenAI "Prompt caching", Monitor cache performance; Anthropic "Prompt caching", Tracking cache performance (3 अक्टूबर 2026 को जाँचा गया)

अगर आप Claude के input_tokens को कुल input मानकर भाग देंगे, तो hit rate और लागत दोनों बहुत ग़लत निकलेंगे। दोनों कंपनियों के आँकड़े एक ही dashboard पर रखते समय तुलना से पहले ऊपर के सूत्रों से कुल को एक जैसा कर लें। OpenAI की गाइड "token hit rate" को cache से पढ़े गए कुल tokens को कुल input tokens से भाग देकर निकालने और उसे user, दिन आदि के हिसाब से जोड़ने की सलाह देती है।

लागत के लिए OpenAI में "(input − reads − writes) × कीमत + reads × कीमत × 0.1 + writes × कीमत × 1.25" और Claude में "input_tokens × कीमत + reads × कीमत × 0.1 + writes × कीमत × 1.25 (1 घंटे वाले हिस्से के लिए 2)" है (मॉडल के हिसाब से read गुणक को 0.05 या दूसरे मान से बदलें)। OpenAI के usage पेज पर "Prompt Caching Dashboard" है, और Anthropic के Rate limits दस्तावेज़ cache hit rate देखने के लिए Usage पेज की ओर इशारा करते हैं।

Reads 0 हों तो क्रम से क्या जाँचें

1. क्या writes भी 0 हैं? Claude में अगर दोनों 0 हैं, तो prompt न्यूनतम लंबाई से छोटा है या cache_control नहीं है। OpenAI के सिर्फ़-explicit mode में अगर आपने कोई breakpoint नहीं लगाया, तो write भी नहीं होता।
2. क्या हर request में writes दिखते हैं? Breakpoint ऐसी जगह पर है जो हर बार बदलती है, या prefix में कुछ हर बार बदल रहा है। क्या बदला, यह ढूँढ़ने के लिए आगे बताए गए diagnostics इस्तेमाल करें।
3. पिछली request को कितना समय हुआ? जाँचें कि कहीं Claude के 5 मिनट (response बनने का समय मिलाकर) या OpenAI के 30 मिनट पार तो नहीं हुए।

OpenAI diagnostics: prompt_cache_diagnostics

OpenAI के Responses API में, GPT-5.6 और उसके बाद के समर्थित मॉडलों पर, prompt_cache_options.comparison_response_id में किसी पिछले response की ID देने पर उस request और मौजूदा request की तुलना का नतीजा prompt_cache_diagnostics में आता है। दस्तावेज़ कहते हैं कि इसका कोई अतिरिक्त शुल्क नहीं है और यह rate limits में अलग से नहीं गिना जाता।

// दूसरी request में तुलना का लक्ष्य जोड़ें
{
  "model": "gpt-6.1-sol",
  "input": [ ...पहली request जैसा ही prefix..., { "role": "user", "content": "अगला सवाल" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(पहले response की ID)" }
}

// Miss पर लौटने वाला उदाहरण (दस्तावेज़ों का उदाहरण: एक tool का नाम बदला गया)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

type के चार मान हैं: cache_hit, cache_miss, comparison_response_not_found (तुलना का रिकॉर्ड नहीं है या ख़त्म हो गया) और unavailable (कोई निष्कर्ष नहीं)। Miss होने पर reason इन नौ में से एक होता है।

स्रोत: OpenAI "Prompt cache diagnostics", Fix a cache miss (3 अक्टूबर 2026 को जाँचा गया)

Claude diagnostics: diagnostics

Claude API पर हर request में diagnostics field शामिल करना ज़रूरी है, क्योंकि API तुलना के लिए fingerprint (hashes और अनुमानित token संख्या) सिर्फ़ उन्हीं requests के लिए सहेजता है जिनमें यह field हो। पहले turn में "previous_message_id": null दें; उसके बाद पिछले response की id दें।

// दूसरे turn से आगे
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(पिछले response की id)" },
  "system": "...",
  "messages": [ ... ]
}

अगर response का diagnostics null है, तो कोई अंतर नहीं मिला (या तुलना नहीं हुई); {"cache_miss_reason": null} का मतलब है कि तुलना अभी पूरी नहीं हुई; और अगर कोई कारण दिया है, तो वह उस पहली जगह को बताता है जहाँ requests अलग हुईं। कारण छह हैं: model_changed, system_changed, tools_changed, messages_changed, previous_message_not_found और unavailable। *_changed वाले कारणों के साथ cache_missed_input_tokens आता है, जो बताता है कि अनुमानतः कितना नुकसान हुआ।

Claude के दस्तावेज़ diagnostics को cache_read_input_tokens के साथ पढ़ने को कहते हैं।

स्रोत: Anthropic "Cache diagnostics", Reading diagnostics alongside usage (3 अक्टूबर 2026 को जाँचा गया)

दोनों diagnostics सुविधाओं में काफ़ी समानता है: दोनों सिर्फ़ पहला मिला अंतर लौटाती हैं, इसलिए उसे ठीक करने के बाद दोबारा तुलना करें। अंतर यह है कि Claude के diagnostics सिर्फ़ Claude API पर काम करते हैं (Amazon Bedrock, Google Cloud, Claude Platform on AWS या Microsoft Foundry पर नहीं), और सिर्फ़ उसी workspace की requests से तुलना करते हैं। OpenAI के दस्तावेज़ों में तुलना के लिए पिछली request को पहले से चिह्नित करने का कोई चरण नहीं बताया गया। Claude में अगर पिछली request में भी diagnostics नहीं था, तो previous_message_not_found मिलता है।

7. Cache hit rate के आँकड़े: कंपनियों के उदाहरण और third-party डेटा

चर्चा में घूमने वाले cache hit rate के आँकड़ों का मतलब इस पर बहुत निर्भर करता है कि उन्हें किसने और किन हालात में प्रकाशित किया। यहाँ उन्हें अलग-अलग रखा गया है।

कंपनियों के आँकड़े

• OpenAI की गाइड के उदाहरण: एक बार चलने वाले grading workload (LLM को grader बनाकर) में तय rubric के बाद explicit breakpoint लगाने पर "लगभग 70% token hit rate" मिला, और बार-बार tools बुलाने वाले agent में "90% से ज़्यादा"। गाइड सावधान करती है कि ये संभावित नतीजों के उदाहरण हैं और ऊपरी सीमा workload पर निर्भर है।
• OpenAI की घोषणा (22 सितंबर 2026) में ग्राहकों की टिप्पणियाँ: Manus टीम कहती है कि breakpoints की जगह पर दोबारा सोचने के बाद OpenAI मॉडलों पर उसका hit rate एक हफ़्ते से कम में "लगभग 85% से लगातार 90% से ऊपर" पहुँच गया। GitHub Copilot के बारे में एक टिप्पणी कहती है कि पिछले कुछ महीनों में उसने दोबारा प्रोसेस होने वाले input के हिस्से को पहले के baseline की तुलना में 50% से ज़्यादा घटाया है। दोनों ग्राहकों के कथन हैं जिन्हें OpenAI ने अपने पेज पर प्रकाशित किया, स्वतंत्र माप नहीं।
• Anthropic: दस्तावेज़ों में hit rate के असली आँकड़े नहीं हैं। Rate limits पेज पर एक गणना का उदाहरण है, "80% hit rate पर 20 लाख tokens प्रति मिनट की input limit असल में 1 करोड़ tokens प्रति मिनट प्रोसेस करती है", लेकिन यह एक मान्यता पर आधारित गणित है, माप नहीं।

Third-party डेटा: कौन बेहतर है, इसका सीधा फ़ैसला नहीं

Requesty, जो कई AI APIs तक requests route करने वाली सेवा है, ने अपने gateway से गुज़री requests को जोड़कर अप्रैल 2026 के hit rate प्रकाशित किए: सीधे Anthropic के लिए 77% (तालिका में 77.50%) और OpenAI के लिए 36% (36.40%) ("Prompt-cache hit rate per provider, April 2026", 9 मई को अपडेट)। पहली नज़र में Claude दोगुने से ज़्यादा hit करता दिखता है, लेकिन चार कारणों से ये आँकड़े इस लेख की तुलना में इस्तेमाल नहीं किए जा सकते।

1. डेटा OpenAI के बदलाव से पहले का है: OpenAI ने 30 मिनट की retention और explicit breakpoints 22 सितंबर को शुरू किए, जबकि अप्रैल का डेटा उससे पहले का है।
2. Workloads अलग हैं: ये अलग-अलग users के apps के नतीजे हैं, जो gateway से अलग-अलग अंतराल पर अलग-अलग prompts भेजते हैं, न कि एक ही prompt दोनों कंपनियों को भेजा गया। Claude में सिर्फ़ वे requests गिनी गईं जिनमें users ने ख़ुद cache_control जोड़ा।
3. Denominator (भाजक): पेज "cached_tokens ÷ input_tokens" कहता है, लेकिन जैसा सेक्शन 6 में बताया गया, Claude के input_tokens में cached tokens शामिल नहीं होते। पेज यह नहीं बताता कि उसने इन्हें कैसे बदला।
4. पेज अपनी ही बात काटता है: एक जगह वह Google Cloud (Vertex) के ज़रिए Claude को 24% पर रखता है और दूसरी जगह 14% पर।

3 अक्टूबर 2026 की हमारी खोज में हमें ऐसा कोई third-party माप नहीं मिला जिसने दोनों caches की तुलना एक जैसी शर्तों में की हो। आख़िरकार, आपके app में caching काम करती है या नहीं, यह जानने का एकमात्र तरीका अपने usage डेटा में इसे मापना है। सेक्शन 6 के सूत्रों से hit rate और लागत निकालें, और miss हो तो diagnostics से वजह पता करें।

सारांश

OpenAI और Claude की prompt caching का मूल विचार एक ही है: एक जैसे prefix का दोबारा इस्तेमाल करना और reads पर input कीमत का लगभग 0.1x लेना। फ़र्क यह है कि OpenAI (GPT-5.6 और उसके बाद) डिफ़ॉल्ट रूप से चालू है, cache कम से कम 30 मिनट रखता है और write के लिए 1.25x लेता है, जबकि Claude तभी cache करता है जब आप cache_control जोड़ें, cache 5 मिनट रखता है (1 घंटे के विकल्प के साथ) और write के लिए 1.25x लेता है (1 घंटे के लिए 2x)।

कीमत के मामले में, क्योंकि write महँगा है, जो cache कभी पढ़ा न जाए वह घाटा है। 5 मिनट और 30 मिनट वाले caches एक read के बाद फ़ायदेमंद होते हैं, और Claude का 1 घंटे वाला cache दो reads के बाद। 5 से 30 मिनट के request अंतराल पर OpenAI के 30 मिनट वाले TTL को बढ़त है, और Claude में 1 घंटा चुनने से नतीजा पलटने से बचता है। अगर आपकी requests TTL से ज़्यादा दूरी पर हैं, तो caching न करना सस्ता है।

Caching काम कर रही है या नहीं, यह usage में read और write की मात्रा देखकर जाँचें। Claude का input_tokens सिर्फ़ breakpoint के बाद वाले हिस्से को कवर करता है, इसलिए पहले कुल निकालें, फिर hit rate। Miss होने पर OpenAI का prompt_cache_diagnostics और Claude का diagnostics बताते हैं कि request पिछली request से कहाँ अलग है। लागत घटाने के दूसरे तरीकों के लिए "AI token लागत बचत" देखें।

FAQ

Q. OpenAI prompt caching का TTL क्या है?

A. GPT-5.6 और उसके बाद के लिए आख़िरी write या reuse के बाद कम से कम 30 मिनट। prompt_cache_options.ttl setting सिर्फ़ "30m" स्वीकार करती है, और गाइड कहती है कि cache इससे ज़्यादा भी रह सकता है। GPT-5.5 और पहले के लिए आप prompt_cache_retention से चुनते हैं: in_memory लगभग 5 से 10 मिनट की निष्क्रियता (अधिकतम 1 घंटा) तक और 24h अधिकतम 24 घंटे तक रहता है।

Q. क्या Claude prompt caching का TTL बढ़ाया जा सकता है?

A. हाँ, "cache_control": {"type": "ephemeral", "ttl": "1h"} से 1 घंटा मिलता है। Write की कीमत input कीमत की 2x है, इसलिए जब तक cache कम से कम दो बार न पढ़ा जाए, यह फ़ायदेमंद नहीं होता। अगर आप 5 मिनट से कम अंतराल पर इस्तेमाल करते रहते हैं, तो 5 मिनट वाला cache हर read पर मुफ़्त में रीफ़्रेश होता है। दोनों request की शुरुआत से गिने जाते हैं, इसलिए लंबा response बनने में लगा समय भी TTL में गिना जाता है।

Q. क्या caching से जवाब बदल जाते हैं?

A. नहीं। दोनों कंपनियों के दस्तावेज़ कहते हैं कि caching output बनने पर असर नहीं डालती। जो सहेजा जाता है वह input पढ़ने की बीच की गणना है, जवाब ख़ुद नहीं। बिना caching की तरह ही, एक जैसा input हमेशा एक जैसा जवाब नहीं देता।

Q. क्या cache को हाथ से साफ़ किया जा सकता है?

A. किसी भी प्लेटफ़ॉर्म पर नहीं। OpenAI कहता है कि entries TTL और settings के अनुसार ख़त्म होती हैं, और Anthropic कहता है कि कम से कम 5 मिनट तक इस्तेमाल न होने पर वे अपने-आप हट जाती हैं (अगर आपने 1 घंटा चुना है तो 1 घंटे बाद)। अगर आप prompt की सामग्री बदलना चाहते हैं, तो prefix बदलें और अगली request नई entry लिख देगी।

स्रोत

• OpenAI API दस्तावेज़: Prompt caching
• OpenAI API दस्तावेज़: Prompt cache diagnostics
• OpenAI API दस्तावेज़: Pricing
• OpenAI: Better prompt caching for GPT-6 (22 सितंबर 2026)
• Claude Platform दस्तावेज़: Prompt caching
• Claude Platform दस्तावेज़: Cache diagnostics
• Claude Platform दस्तावेज़: Pricing
• Claude Platform दस्तावेज़: Rate limits
• Requesty: Prompt-cache hit rate per provider, April 2026

सभी स्रोत 3 अक्टूबर 2026 को मूल रूप में जाँचे गए। नए मॉडल आने के साथ कीमतें, TTL और न्यूनतम लंबाई बदल सकती हैं, इसलिए उन पर भरोसा करने से पहले हर कंपनी के pricing पेज पर पुष्टि करें। इस लेख की लागत गणनाएँ आधिकारिक कीमतों पर आधारित अंकगणित हैं, हमारे ख़ुद API बुलाकर किए गए माप नहीं।