OpenAI की 12 घंटे की प्रॉम्प्ट कैशिंग: 2.5× राइट कब सस्ती पड़ती है?

OpenAI की 12 घंटे की प्रॉम्प्ट कैशिंग उस स्थिर शुरुआती हिस्से, यानी प्रिफिक्स, के लिए चुनें जिसे आपका एजेंट लंबे अंतराल के बाद दोबारा इस्तेमाल करता है; सत्र की बदलती सामग्री को 30m पर रखें या कैश में लिखने से बाहर छोड़ें। अगर दूसरे विकल्प में हर अनुरोध पर नई 30m राइट करनी पड़े, तो एक 12h राइट तीसरे अनुरोध, यानी उसी प्रिफिक्स के दूसरे पुनः उपयोग, पर सस्ती पड़ती है—बशर्ते प्रिफिक्स अब भी मेल खाता हो। अगर 30m से लगातार कैश हिट मिल रहे हैं, तो लंबी अवधि केवल खर्च बढ़ाती है; पढ़ने की दर कम नहीं करती।

30m और 12h में कितना खर्च आता है?

12h विकल्प कैश से पढ़ने की रियायती दर पाने की अवधि बढ़ाता है, लेकिन कैश में लिखने की कीमत डिफ़ॉल्ट से दोगुनी होती है। OpenAI के 20 अक्टूबर, 2026 के API चेंजलॉग में यह विकल्प Responses के लिए जोड़ा गया था। प्रॉम्प्ट कैशिंग गाइड में GPT-5.6 और उसके बाद के मॉडल के लिए ये नियम दिए हैं; जानकारी 2026-10-24 को जाँची गई थी।

इनपुट का प्रकार	सामान्य इनपुट दर का गुणक	GPT-6.1 Sol, USD प्रति 1M tokens
सामान्य इनपुट	1×	$2.00
30m राइट, डिफ़ॉल्ट	1.25×	$2.50
12h राइट	2.5×	$5.00
कैश से पढ़ना, दोनों अवधियों में	अधिकांश मॉडल पर 0.1×; GPT-6.1 Sol पर 0.05×	$0.10

ये कैश में लिखने की कुल दरें हैं। 12h राइट के रूप में बिल किए गए टोकन की कीमत सामान्य इनपुट की 2.5× होती है; सामान्य इनपुट का शुल्क लेकर उसके ऊपर फिर 2.5× नहीं जोड़ा जाता।

डॉलर वाले कॉलम में gpt-6.1-sol के लिए OpenAI की मौजूदा Standard दरें इस्तेमाल की गई हैं। इनमें प्रॉम्प्ट 272K इनपुट टोकन या उससे कम का है और क्षेत्र-विशेष में प्रोसेसिंग का कोई अतिरिक्त शुल्क नहीं है। आउटपुट की दर $10.00 प्रति 1M tokens है। बड़े प्रॉम्प्ट, दूसरी सेवा श्रेणियों और क्षेत्र-विशेष में प्रोसेसिंग के लिए दरें बदल सकती हैं; नीचे का हिसाब लागू करने से पहले मॉडल की कीमत से जुड़ी शर्तें देखें।

दोबारा इस्तेमाल होने वाले प्रिफिक्स में कम से कम 1,024 दिखने वाले इनपुट टोकन होने चाहिए। अनुरोध बड़ा होने से उसका छोटा-सा अपरिवर्तित शुरुआती हिस्सा अपने-आप कैशिंग के योग्य नहीं बन जाता।

महँगी राइट की लागत कब वसूल होती है?

गिनें कि लंबी अवधि से कितनी राइट बचती हैं। मान लें B आपके अपरिवर्तित प्रिफिक्स की सामान्य इनपुट लागत है, n कुल अनुरोधों की संख्या है, r पढ़ने की दर का गुणक है और k पहली राइट समेत कुल 30m राइट की संख्या है।

यदि हर राइट या सफल कैश हिट पूरा प्रिफिक्स कवर करती है, और 12h में एक राइट के बाद हर बार कैश से सफलतापूर्वक पढ़ा जाता है, तो:

• 12h cost = B × [2.5 + (n - 1) × r]
• 30m cost = B × [1.25 × k + (n - k) × r]
• No-cache cost = B × n

r = 0.1 और r = 0.05, दोनों के लिए लंबी अवधि वाला कैश n = 3 पर बिना कैश वाले इनपुट से सस्ता हो जाता है। डिफ़ॉल्ट कैश के मुकाबले वह तब सस्ता होता है जब k >= 3 हो, जबकि 12h नीति में अब भी केवल एक राइट की जरूरत पड़े। यानी पहली राइट के बाद छोटी अवधि वाली दो और राइट बचनी चाहिए; सिर्फ बहुत सारे कैश हिट मिलना पर्याप्त नहीं है।

अगर दोनों नीतियों में एक बार राइट होती है और उसके बाद हर अनुरोध कैश से पढ़ता है, तो 12h की लागत हमेशा 1.25 × B अधिक रहती है। इसलिए लगातार चल रही बातचीत में लंबी अवधि वाली राइट के लिए अधिक भुगतान करने की जरूरत कम है, जब तक बीच में ऐसे अंतराल न आएँ जिनके बाद दोबारा राइट करनी पड़े।

30 मिनट से लंबा अंतराल बचत का अवसर देता है, लेकिन इससे यह साबित नहीं होता कि अगली बार प्रिफिक्स कैश में नहीं मिलेगा। OpenAI एंट्री को उसकी न्यूनतम अवधि से अधिक समय तक रख सकता है, और 30m कैश से पढ़ने पर उसकी वैधता कम से कम अगले 30 मिनट के लिए बढ़ जाती है। मौजूदा काम का खर्च अनुमानित करते समय वास्तव में हुई राइट की संख्या इस्तेमाल करें।

एक ठोस अनुमान के लिए GPT-6.1 Sol की Standard दरों पर 10,000 टोकन का प्रिफिक्स लें: B = $0.02 और r = 0.05। प्रिफिक्स बदले बिना घंटा 0 से घंटा 11 तक हर घंटे एक अनुरोध भेजें, यानी कुल 12 अनुरोध।

कैश के व्यवहार की धारणा	12 अनुरोधों में प्रिफिक्स की इनपुट लागत
कैशिंग नहीं: 12 बार सामान्य इनपुट	$0.240
30m: सभी 12 अनुरोधों पर राइट जरूरी	$0.300
12h: एक राइट और 11 बार पढ़ना	$0.061
30m: एक राइट और 11 बार पढ़ना	$0.036

30m की दोनों पंक्तियाँ दिखाती हैं कि सिर्फ अनुरोधों का अंतराल देखकर बचत तय क्यों नहीं की जा सकती। हर बार राइट वाली पंक्ति एक धारणा है; हर घंटे भेजे गए अनुरोधों में ऐसा होना अनिवार्य नहीं है। इन अनुमानों में बदलता अंतिम हिस्सा, आउटपुट टोकन या टूल के शुल्क शामिल नहीं हैं; ये वास्तविक बिल के माप नहीं हैं।

पूरे अनुरोध पर 12h लगाने से खर्च क्यों बढ़ सकता है?

अनुरोध के स्तर पर दिया गया prompt_cache_options.ttl: "12h" अपने-आप बनने वाले, यानी इम्प्लिसिट ब्रेकपॉइंट पर भी लागू होता है। ब्रेकपॉइंट वह सीमा तय करता है जहाँ तक प्रिफिक्स कैश में शामिल होता है। डिफ़ॉल्ट mode: "implicit" में बातचीत की नई और कैशिंग के योग्य सामग्री पर हर बार 2.5× की राइट लग सकती है, भले पुराने प्रिफिक्स को सस्ती दर पर पढ़ा जा रहा हो।

जिस एजेंट में टूल के नतीजे और उपयोगकर्ता के संदेश लगातार जुड़ते रहते हैं, उसका बढ़ता अंतिम हिस्सा स्थिर शुरुआती हिस्से की बचत से ज्यादा महँगा पड़ सकता है। सिर्फ कैश हिट का ऊँचा प्रतिशत यह नहीं बताता कि नीति किफायती है।

इनमें से उपयुक्त व्यवस्था चुनें:

• स्थिर साझा सामग्री और दोबारा इस्तेमाल होने वाला सत्र संदर्भ: अनुरोध का डिफ़ॉल्ट 30m रखें और साझा सामग्री के अंत पर 12h का अलग मान दें।
• स्थिर सामग्री और एक बार पूछे जाने वाले सवाल: mode: "explicit" इस्तेमाल करें और बदलते सवाल को आखिरी स्पष्ट ब्रेकपॉइंट के बाद रखें।
• ऐसी बातचीत जिसका नया संदर्भ जल्द फिर इस्तेमाल होगा: साझा प्रिफिक्स पर 12h ब्रेकपॉइंट के साथ mode: "implicit" बनाए रखें और अनुरोध का डिफ़ॉल्ट 30m रखें।

ब्रेकपॉइंट अपने से पहले का पूरा प्रिफिक्स कवर करता है। पहले से कैश न होने वाले अनुरोध में, अगर 12h ब्रेकपॉइंट 2,000 टोकन पर और 30m ब्रेकपॉइंट 5,000 टोकन पर है, तो 2,000 टोकन लंबी अवधि की राइट और 3,000 टोकन छोटी अवधि की राइट के रूप में बिल होंगे। इसके बजाय बाद वाली 5,000 टोकन की सीमा पर 12h ब्रेकपॉइंट लगा दें, तो सभी 5,000 टोकन पर लंबी अवधि की राइट दर लगेगी। हर टोकन का शुल्क केवल एक बार लगता है, उसे कवर करने वाली चुनी गई सबसे लंबी राइट अवधि के अनुसार।

अवधि बदलने के दो और नियम ध्यान में रखें। अभी वैध 30m कवरेज को 12h में अपग्रेड करने पर नई लंबी राइट का पूरा शुल्क लगता है; पुरानी राइट का कोई समायोजन नहीं मिलता। 30m वाला अनुरोध जब अभी वैध 12h कैश से प्रिफिक्स पढ़ता है, तो उन टोकन पर पढ़ने की दर लगती है; न 12 घंटे का समय फिर शुरू होता है, न नई राइट का शुल्क जुड़ता है। इन ओवरलैप और अवधि के नियमों के कारण बड़े प्रिफिक्स को पहली बार कैश में लिखने से पहले नीति तय करना उपयोगी है।

एक Responses अनुरोध में 12h और 30m कैसे सेट करें?

अनुरोध का डिफ़ॉल्ट 30m रखें और साझा संदर्भ सामग्री, सत्र के संदर्भ तथा मौजूदा सवाल को अलग करने के लिए स्पष्ट ब्रेकपॉइंट लगाएँ। यह उदाहरण सीधे OpenAI के Responses API को अनुरोध भेजता है और तैयार जवाब के साथ बिल जाँचने के लिए जरूरी उपयोग आँकड़े भी दिखाता है।

आपको Bash, curl, jq और gpt-6.1-sol की पहुँच वाली OpenAI API कुंजी चाहिए। मौजूदा डायरेक्टरी में ये फ़ाइलें तैयार करें:

• shared-context.md: उपयोगी इंजीनियरिंग निर्देश और संदर्भ सामग्री, जिन्हें दिन भर दोबारा इस्तेमाल करना है; इसमें कम से कम 1,024 दिखने वाले इनपुट टोकन हों।
• session-context.md: मौजूदा डिप्लॉयमेंट या पुल रिक्वेस्ट का संदर्भ, जिसे इस सत्र में फिर इस्तेमाल करने की अपेक्षा है।

उदाहरण की दोनों कॉल के बीच दोनों फ़ाइलों को अपरिवर्तित रखें। जब read इनपुट की प्रतीक्षा करे, तब API कुंजी पेस्ट करके Enter दबाएँ; कुंजी टर्मिनल पर दिखाई नहीं देगी। प्रमाणीकरण OpenAI API की शुरुआती गाइड के अनुसार है।

set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY

cache_request() {
  jq -n \
    --rawfile shared ./shared-context.md \
    --rawfile session ./session-context.md \
    --arg question "$1" \
    '{
  model: "gpt-6.1-sol",
  service_tier: "default",
  reasoning: {effort: "low"},
  prompt_cache_options: {mode: "explicit", ttl: "30m"},
  input: [
    {
      role: "developer",
      content: [{
        type: "input_text",
        text: $shared,
        prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
      }]
    },
    {
      role: "user",
      content: [
        {
          type: "input_text",
          text: $session,
          prompt_cache_breakpoint: {mode: "explicit"}
        },
        {type: "input_text", text: $question}
      ]
    }
  ]
}' |
  curl --silent --show-error --fail-with-body \
    https://api.openai.com/v1/responses \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @- |
  jq '{id, status, service_tier,
  text: ([.output[]? | .content[]? |
    select(.type == "output_text") | .text] | join("\n")),
  usage, error}'
}

cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."

पहला सामग्री ब्लॉक "ttl": "12h" देकर अनुरोध के डिफ़ॉल्ट को बदलता है। सत्र वाला ब्लॉक अपना TTL नहीं देता, इसलिए उसे "30m" मिलता है। अनुरोध में केवल स्पष्ट ब्रेकपॉइंट वाला मोड होने से अंतिम सवाल पर कैश राइट शुल्क नहीं लगता; उसका सामान्य इनपुट शुल्क फिर भी लगता है।

पहले से कैश न हुए, योग्य प्रिफिक्स के लिए पहले पूरे हुए रिस्पॉन्स में usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens के अंतर्गत लंबी राइट दिखाई देनी चाहिए। अगर प्रिफिक्स और उसकी कवरेज वैध बने रहें, तो दूसरे रिस्पॉन्स में cached_tokens > 0 और कोई नई लंबी राइट नहीं दिखनी चाहिए। लौटे हुए text में इस्तेमाल करने योग्य जवाब होता है। तुरंत दोबारा कॉल करने से प्रिफिक्स का मेल और बिलिंग जाँची जाती है; लंबे अंतराल की बचत को अपने वास्तविक प्रोडक्शन अंतराल पर अनुरोध भेजकर आँकें।

अगर 400 invalid_request_error मिले, तो TTL की सटीक स्ट्रिंग, चुना गया मॉडल और Responses एंडपॉइंट जाँचें। अगर दोनों कॉल में कैश किए गए टोकन शून्य हों, तो पहले प्रिफिक्स की लंबाई देखें, फिर फ़ाइलों, मॉडल, सेटिंग और ब्रेकपॉइंट की जगह की तुलना करें। साझा ब्रेकपॉइंट से पहले का कोई बदलाव—टूल जोड़ते समय उनकी परिभाषा बदलना भी—दोबारा इस्तेमाल रोक सकता है।

बिना कैश वाला आधार मापने के लिए mode: "explicit" रखें और हर prompt_cache_breakpoint हटा दें। अनुरोध के आधिकारिक स्कीमा के अनुसार, बिना मार्कर वाला स्पष्ट मोड प्रॉम्प्ट कैशिंग नहीं करता।

usage से इनपुट का शुल्क कैसे निकालें?

सामान्य इनपुट, कैश से पढ़े गए टोकन और दोनों तरह की राइट को अलग-अलग श्रेणियाँ मानें। कुल cache_write_tokens में ttl_30m_tokens और ttl_12h_tokens पहले से शामिल हैं; तीनों को अलग-अलग बिल करने से राइट दो बार गिनी जाएगी। 12h में अपग्रेड के रूप में बिल हुए टोकन राइट में आते हैं और cached_tokens में शामिल नहीं होते।

OpenAI का उपयोग और बिलिंग का उदाहरण इस रूप में है:

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 4000,
      "cache_write_tokens": 7000,
      "cache_write_tokens_details": {
        "ttl_30m_tokens": 3000,
        "ttl_12h_tokens": 4000
      }
    }
  }
}

मान लें I का अर्थ input_tokens, R का अर्थ cached_tokens और W30 तथा W12 का अर्थ दोनों TTL पर लिखे गए टोकन की संख्या है। सामान्य इनपुट U = I - R - W30 - W12 होगा; यहाँ वह 1,000 टोकन है।

अगर सामान्य इनपुट की दर P USD प्रति 1M tokens है और कैश से पढ़ने का गुणक r है, तो:

Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000

दस्तावेज़ के काल्पनिक उदाहरण में P = $1 और r = 0.1 रखने पर:

(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515

उसी उपयोग के लिए GPT-6.1 Sol की Standard दरें लगाएँ, यानी P = $2 और r = 0.05: इनपुट शुल्क $0.02990 होगा। आउटपुट और दूसरे लागू शुल्क अलग से जोड़ें। यह हिसाब केवल इनपुट बिलिंग का है; इससे कोई कोडिंग कार्य पूरा करने की कुल लागत का अनुमान नहीं मिलता।

रिस्पॉन्स ID, समय, मॉडल, वास्तव में मिला service_tier और ये टोकन संख्याएँ लॉग करें। अगर क्लाइंट TTL के हिसाब से विवरण नहीं दिखाता, तो अलग-अलग अवधि का खर्च निकालने से पहले मूल JSON देखें; काउंटर न दिखने का अर्थ शून्य राइट नहीं है। किसी एक हिट प्रतिशत के आधार पर नीति चुनने के बजाय, सामान्य कामकाज वाले पूरे दिन के डॉलर में शुल्क जोड़कर देखें।

12h कैश से पढ़ने की दर पाने की न्यूनतम अवधि बताता है। यह डेटा मिटाने की समय-सीमा तय नहीं करता, डेटा रखने की अधिकतम अवधि से जुड़ी नीति नहीं बदलता और हर अनुरोध में कम विलंब की गारंटी नहीं देता।

Codex, Work और Anthropic की कैशिंग से क्या अंतर है?

API बिलिंग को लॉग इन करके इस्तेमाल किए जाने वाले उत्पादों की उपयोग सीमाओं से अलग रखें। अपने 21 अक्टूबर, 2026 के पोस्ट में Tibo Sottiaux ने लॉग इन किए हुए Codex और Work उपयोगकर्ताओं की कैशिंग को “forever”, यानी हमेशा के लिए, कहा और बताया कि पुरानी बातचीत पर लौटने पर भी कैश हिट मिलेगा। यह बयान उन उत्पादों के सत्रों के बारे में है; इससे API का TTL तय नहीं होता और न सदस्यता असीमित बनती है।

Codex के आधिकारिक मूल्य दस्तावेज़ अलग से बताते हैं कि क्रेडिट आधारित Codex बिलिंग में कैश राइट का अलग शुल्क नहीं है, जबकि API कुंजी से किया गया उपयोग API की दरों पर बिल होता है। अगर आप API कुंजी के साथ Codex चलाते हैं, तो खर्च का बजट API के नियमों के अनुसार बनाएँ; लॉग इन वाले उत्पाद का वादा उस उपयोग पर लागू न मानें।

Claude के लिए 2026-10-24 तक दस्तावेज़ में दिए विकल्प हैं: डिफ़ॉल्ट 5 मिनट का कैश, जिसकी राइट दर 1.25× है, और वैकल्पिक 1 घंटे का कैश, जिसकी राइट दर 2× है। पढ़ने की छूट मॉडल के अनुसार बदलती है: Claude Opus 5.5 और Sonnet 5.5 में दर 0.05× है; बाकी दरें Anthropic की मूल्य तालिका में हैं। सफलतापूर्वक पढ़ने पर बिना अतिरिक्त राइट शुल्क के अवधि फिर शुरू होती है, और अलग-अलग TTL वाले अनुरोधों में लंबी अवधि के ब्लॉक छोटी अवधि के ब्लॉक से पहले होने चाहिए।

अगर अनुरोधों में बार-बार कई घंटे का अंतर आता है और आपका ऐप पहले से किसी समर्थित OpenAI मॉडल पर चलता है, तो पहले स्थिर प्रिफिक्स के लिए 12h नीति आज़माएँ। लगातार सक्रिय सत्र के लिए छोटी अवधि वाले कैश से शुरू करें। प्रदाताओं की तुलना के लिए उनकी वास्तविक आधार दरें, आउटपुट का उपयोग और देखा गया कैश व्यवहार चाहिए; केवल अवधि और राइट गुणक देखकर यह तय नहीं किया जा सकता कि पूरा कार्य किस पर सस्ता पड़ेगा।