تحریر: Claude prompt caching: break-even کب ہوتا ہے؟
Claude prompt caching میں cache write 1.25x اور read 0.1x ہے۔ جانیں دوسری request پر لاگت کیسے پوری ہوتی ہے اور API سے اپنے break-even کا ثبوت دیں۔
prompt caching کی لاگت کب فائدہ دیتی ہے
Prompt caching آپ کے prompt کے ابتدائی حصے کو ہر call پر دوبارہ پڑھنے کے بجائے Claude کو اسے دوبارہ استعمال کرنے دیتی ہے۔ پورا فیصلہ آپ کے model کی بنیادی input price پر لاگو ہونے والے دو multipliers پر منحصر ہے۔ August 2026 تک، cache write کی لاگت 5 minute lifetime کے لیے base input کی 1.25x، یا 1 hour lifetime کے لیے 2x ہے۔ cache read کی لاگت 0.1x ہے۔ یہ multipliers تمام models پر یکساں رہتے ہیں، اس لیے فی token price تبدیل ہونے پر بھی break-even point نہیں بدلتا۔
اس میں موجودہ اضافی لاگت کے بدلے بعد کی رعایت حاصل ہوتی ہے۔ prefix محفوظ کرنے کے لیے آپ ایک بار اضافی ادائیگی کرتے ہیں۔ اس کے بعد ہر request جو بالکل انہی bytes سے شروع ہو، اس حصے کے لیے معمول کی input price کا دسویں حصہ ادا کرتی ہے۔ اگر prefix اپنی lifetime کے اندر کبھی دوبارہ استعمال نہ ہو تو آپ بلا فائدہ 25 percent اضافی ادا کرتے ہیں۔
الگبری کی ایک سطر میں break-even
اگر آپ prefix کو cache کیے بغیر بھیجتے تو اس کی بنیادی 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 نہ کرنے کے مقابلے میں سستی ہو جاتی ہے۔
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 $5 per million tokens ہے۔ $3 per million model کے لیے ہر figure کو 0.6 سے ضرب دیں۔ curve کی شکل تبدیل نہیں ہوتی۔
The data behind this chart
[
{
"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 کی uncached لاگت $0.10 اور cached لاگت $0.125 ہوتی ہے، اس لیے one-shot prompt کو cache کرنا خالص نقصان ہے۔ دوسری request تک 5 minute cache کی لاگت $0.135 کے مقابلے میں $0.20 ہوتی ہے۔ اس مرحلے پر 1 hour cache اب بھی زیادہ مہنگا ہے: $0.21 کے مقابلے میں وہی $0.20۔ یہ صرف تیسری request پر uncached line سے نیچے آتا ہے: $0.22 کے مقابلے میں $0.30۔ 20 requests تک فرق $2.00 کے مقابلے میں $0.315 ہے۔
Cache hit entry کو دوبارہ refresh بھی کرتا ہے، اسی لیے published price table میں اس column کا نام cache hits and refreshes ہے۔ اس لیے مصروف endpoint 5 minute entry کو read prices پر غیر معینہ مدت تک برقرار رکھ سکتا ہے، جبکہ 1 hour lifetime کی 2x write صرف اس وقت فائدہ دیتی ہے جب traffic میں واقعی وقفے موجود ہوں۔
کمزور hit rate کی لاگت
حقیقی network traffic میں cache miss ہوتے ہیں۔ ایسی request جس کا cache miss ہو جائے لیکن وہ پھر بھی breakpoint رکھتی ہو، write کے طور پر charge ہوتی ہے۔ اس لیے لاگت کا درست ماڈل hit rate کے تابع ہونا چاہیے۔ نیچے دیا گیا chart 1,000 requests کے لیے یہی حساب دکھاتا ہے، جن میں ہر request کے ساتھ ایک ہی 20,000 token prefix ہے۔
The data behind this chart
[
{
"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 کی کم از کم سطح کے قریب ہے۔
hit rate وہ عدد ہے جس کی monitoring کرنی چاہیے، کیونکہ prefix size مقرر ہونے کے بعد یہی واحد input ہے جسے آپ control کرتے ہیں۔
کون سے prefixes breakpoint کے مستحق ہیں
ایک request میں زیادہ سے زیادہ چار cache breakpoints شامل ہو سکتے ہیں، اس لیے سوال یہ ہے کہ کن blocks کو breakpoint دیا جائے۔ امیدوار وہ blocks ہیں جو مختلف calls میں byte-identical رہتے ہیں اور اتنے بڑے ہوتے ہیں کہ ان کا اثر نمایاں ہو۔ ذیل کا chart 5 minute cache میں 90 percent hit rate کے ساتھ 1,000 requests پر چار عام shapes کی لاگت دکھاتا ہے۔
The data behind this 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، $7.85 کی بچت کرتا ہے، جبکہ uncached لاگت $10.00 ہوتی ہے، ہر 1,000 requests پر۔ زیادہ volume پر یہ حقیقی بچت ہے، لیکن caching کو اہم بنانے والی اصل وجہ یہ نہیں۔ tool definitions شامل کرنے پر کل حجم 8,000 tokens ہو جاتا ہے اور بچت $31.40 تک پہنچ جاتی ہے۔ 25,000 tokens پر مشتمل ایسا policy document جس کے بارے میں ہر request سوال کرتی ہے، $98.12 بچاتا ہے۔ آخری row architecture تبدیل کرتی ہے: codebase یا transcript context کے 120,000 tokens کی uncached لاگت $600.00 اور cached لاگت $129.00 ہے، یعنی $471.00 کی بچت۔
بچت prefix size اور hit rate کے ساتھ بڑھتی ہے، اور کسی اور چیز کے ساتھ نہیں۔ اس سے یہ بھی بدل جاتا ہے کہ prompt میں کیا شامل کرنا فائدہ مند ہے: Claude کے ایک million tokens کی اصل لاگت ان چیزوں کے لیے sticker price کے دسویں حصے تک آ جاتی ہے جنہیں آپ ایک سے زیادہ بار بھیجتے ہیں۔
ماہانہ بل میں اس کی شکل
نیچے دیا گیا چارٹ اوپر موجود 8,000 ٹوکن prefix، ایک system prompt اور tool definitions کو 90 فیصد hit rate کے ساتھ لیتا ہے اور اسے ماہانہ request volumes تک بڑھاتا ہے۔
The data behind this chart
[
{
"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 فیصد بل میں کمی کا وعدہ کرنے سے پہلے یاد رکھیں۔ Caching ان وسیع تر طریقوں کے ساتھ مل کر کام کرتی ہے جو VPS پر AI agent کے بل کو قابو میں رکھنے کے لیے استعمال ہوتے ہیں۔
کیش کے کام کرنے کا ثبوت کیسے حاصل کریں
ڈیزائن پر بھروسا نہ کریں۔ جواب میں usage block پڑھیں۔ ہر Messages API (application programming interface) جواب ان cached tokens کی تعداد بتاتا ہے جو اس نے لکھے، ان cached tokens کی تعداد جو اس نے پڑھے، اور ان fresh tokens کی تعداد جنہیں اسے process کرنا پڑا۔
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۔
Shell سے یہی جانچ اس request body کے خلاف کریں جسے آپ نے request.json میں محفوظ کیا ہے:
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 کچھ اس طرح دکھائی دے گی:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}ایک line حقیقت واضح کرتی ہے۔ اگر cache_read_input_tokens مختلف calls کے دوران 0 پر برقرار رہے تو آپ ہر بار 1.25x write کی لاگت ادا کر رہے ہیں اور اس کے بدلے کچھ بھی واپس نہیں مل رہا۔
1 hour lifetime کے لیے breakpoint میں time to live (TTL) شامل ہوتا ہے:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}خودکار caching بھی دستیاب ہے: request کی top level پر صرف ایک cache_control field شامل کریں، اس کے بعد API conversation کے بڑھنے کے ساتھ breakpoints کا انتظام خود کرتی ہے۔ یہ آپ کے چار breakpoint slots میں سے ایک استعمال کرتی ہے۔ ابتدا اسی سے کریں۔ جب آپ کو boundary کی درست جگہ خود متعین کرنی ہو تو explicit breakpoints استعمال کریں۔
ترتیب کا وہ اصول جو hit rates ختم کر دیتا ہے
Cache درخواست کے آغاز سے byte بہ byte prefix کو match کرتا ہے، اور درخواست ایک مقررہ ترتیب سے تیار ہوتی ہے: پہلے tools، پھر system، پھر messages۔ کسی بھی سطح پر تبدیلی ہونے سے وہ سطح اور اس کے بعد کی تمام سطحیں invalid ہو جاتی ہیں۔ ایک tool description میں ترمیم کرنے سے system prompt اور message history بھی invalid ہو جاتی ہے، حالانکہ آپ نے انہیں تبدیل نہیں کیا ہوتا۔
اس سے ایک ایسا اصول حاصل ہوتا ہے جس میں کوئی استثنا نہیں: calls کے درمیان تبدیل ہونے والی ہر چیز، تبدیل نہ ہونے والی ہر چیز کے بعد ہونی چاہیے۔
عام مسئلہ timestamp ہوتا ہے۔ system prompt کے آغاز میں Current time: 2026-08-03T14:07:11Z والی سطر 0 percent hit rate کی ضمانت دیتی ہے، کیونکہ prefix hash ہر call پر مختلف ہوتا ہے اور اس سے پہلے کا کوئی entry کبھی match نہیں کر سکتا۔ اسے user message میں، آخر میں منتقل کریں۔ session identifier یا per-request nonce بھی اسی طرح مسئلہ پیدا کرتا ہے اور اس کا حل بھی یہی ہے۔ ہر request کے ساتھ مختلف ہونے والی retrieved documents بھی cached block کے بعد ہونی چاہییں، ورنہ وہ ہر مستحکم token کو ایک ایسی boundary کے پیچھے دھکیل دیتی ہیں جو تبدیل ہوتی رہتی ہے۔
دوسرا مسئلہ breakpoint کو تبدیل ہونے والے block پر رکھنا ہے۔ Cache writes breakpoint پر ہوتی ہیں۔ اس لیے اگر وہ block ہر بار مختلف ہو تو کوئی مستحکم چیز کبھی store نہیں ہوتی، اور lookback کو صرف وہ entries ملتی ہیں جو سابقہ requests نے اپنے بدلتے ہوئے breakpoints پر لکھی تھیں۔ cache_control کو اس آخری block پر رکھیں جس کا content تمام requests میں یکساں ہو۔
تیسرا مسئلہ ایسا parameter change ہے جسے آپ prompt content نہیں سمجھتے۔ مختلف model کا cache مختلف ہوتا ہے۔ tool choice تبدیل کرنے سے system level کے بعد کی تمام سطحیں 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
اگر کسی ایسی request میں دونوں counters کی قدر 0 ہو جس کے بارے میں آپ سمجھتے ہیں کہ وہ cached ہے، تو سب سے پہلے prefix کی لمبائی چیک کریں۔ یہی وجہ ہے کہ caching workload کے لیے سب سے کم قیمت والا model خود بخود سب سے کم لاگت والا نہیں ہوتا۔ caching فعال ہونے کے لیے Haiku 4.5 کو Opus 5 کے مقابلے میں 8 گنا زیادہ طویل prefix درکار ہوتا ہے۔ اس لیے 2,000 tokens والا system prompt ایک model پر cache ہو جاتا ہے، جبکہ دوسرے پر خاموشی سے نظر انداز کر دیا جاتا ہے۔
Claude Code آپ کے لیے cache کہاں کرتا ہے، اور کہاں نہیں کر سکتا
Claude Code اپنے prefix کو cache کرتا ہے۔ System prompt اور tool definitions ہر request کے آغاز میں موجود رہتی ہیں اور تبدیل نہیں ہوتیں، اس لیے انہیں ایک بار لکھا جاتا ہے اور session کے باقی حصے میں دوبارہ پڑھا جاتا ہے۔ اسی وجہ سے طویل session میں ہر turn کی لاگت context size سے ظاہر ہونے والی لاگت کے مقابلے میں بہت کم ہوتی ہے۔ اس کا اثر Claude Code token usage کی اطلاع کیسے دیتا ہے میں بیان کیے گئے counters میں نظر آتا ہے۔
یہ اس وقت مدد نہیں کر سکتا جب context کے آغاز کے قریب کوئی edit ہو۔ Conversation history صرف append-only ہوتی ہے، اس لیے عام نئے turns پہلے سے cached prefix میں اضافہ کرتے ہیں۔ اگر session کے شروع میں پڑھی گئی file میں تبدیلی کی جائے تو اس prefix کے درمیان موجود content بدل جاتا ہے، اور تبدیلی کے بعد آنے والے ہر token کو دوبارہ لکھنا پڑتا ہے۔ طویل idle gap بھی یہی اثر پیدا کرتا ہے، کیونکہ entry expire ہو جاتی ہے اور اگلے turn میں مکمل write کی لاگت آتی ہے۔ ان میں سے کوئی بھی bug نہیں ہے۔ دونوں صورتیں prefix rule کے عین مطابق کام کرتی ہیں۔
اگر آپ اس کے بجائے اپنا client لکھ رہے ہیں تو layout کو بعد میں تبدیل کرنے کے بجائے پہلے request سے ہی درست ترتیب دیں۔ Call اسی طرح بنائیں جیسے VPS پر پہلی Claude API app میں کیا گیا ہے: stable blocks پہلے اور volatile blocks آخر میں رکھیں۔
Failure modes اور آپ کو کیا نظر آئے گا
ہر call ایک write ہے۔ cache_creation_input_tokens ہر request پر non-zero ہے، جبکہ cache_read_input_tokens بدستور 0 رہتا ہے۔ Breakpoint سے پہلے یا اسی مقام پر موجود کوئی چیز calls کے درمیان تبدیل ہو رہی ہے۔ دو مسلسل requests پر assembled prefix کے پہلے 200 characters print کریں اور انہیں بصری طور پر compare کریں۔
دونوں counters 0 ہیں۔ Prefix model کی minimum حد سے کم ہے، یا cache_control field API تک نہیں پہنچا۔ پہلے prefix tokens count کریں، پھر وہ request body log کریں جو حقیقت میں بھیجی گئی تھی۔
Reads کام کرتے ہیں، پھر رک جاتے ہیں۔ Hits کا ایک سلسلہ آتا ہے، پھر ایک write، اور اس کے بعد دوبارہ hits آتے ہیں۔ Requests کے درمیان وقفہ lifetime سے زیادہ طویل تھا۔ Write قبول کریں، یا hit rate کے 53 percent سے زیادہ ہونے کی تصدیق کے بعد 1 hour TTL اختیار کریں۔
Deploy کے بعد hit rate کم ہو جاتا ہے۔ Tool description edit کی گئی یا 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 کو cache کے لیے دوبارہ کتنی بار استعمال کرنا ضروری ہے؟
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 ہی فائدہ مند ہو جاتی ہے۔ 1 hour cache میں write کی لاگت 2x ہوتی ہے اور برابری N = 2.11 پر آتی ہے، اس لیے اس کے لیے دو reads ضروری ہیں۔
cache_read_input_tokens ہمیشہ zero کیوں ہوتا ہے؟
پہلے prefix length چیک کریں۔ اگر یہ model minimum سے کم ہو، جو August 2026 تک Claude Opus 5 کے لیے 512 tokens اور Claude Haiku 4.5 کے لیے 4,096 ہے، تو caching خاموشی سے skip ہو جاتی ہے اور دونوں counters 0 دکھاتے ہیں۔ اگر prefix کافی طویل ہو تو ایسی content تلاش کریں جو calls کے درمیان تبدیل ہوتی ہے اور breakpoint پر یا اس سے پہلے موجود ہو، مثلاً system prompt میں timestamp یا session identifier۔ اگر counters پہلے کام کر رہے تھے اور پھر رک گئے ہیں تو requests کے درمیان وقفہ cache lifetime سے زیادہ تھا۔
کیا prompt caching سے Claude کے answers تبدیل ہوتے ہیں؟
نہیں۔ cache ان tokens کی processed form محفوظ کرتا ہے جو آپ پہلے ہی بھیج چکے ہیں، اور model دونوں صورتوں میں ایک ہی prompt دیکھتا ہے۔ یہ billing اور latency feature ہے، behaviour میں تبدیلی نہیں۔ اس کا مطلب یہ بھی ہے کہ آپ کسی working prompt پر evaluations دوبارہ چلائے بغیر اسے enable کر سکتے ہیں۔
کیا مجھے 1 hour cache کے لیے ادائیگی کرنی چاہیے؟
صرف اس وقت جب آپ کے traffic میں 5 minutes سے زیادہ کے gaps ہوں اور آپ کی hit rate تقریباً 53 percent سے زیادہ رہنے کی توقع ہو۔ miss ہونے پر 2x write کی لاگت، 1.25x write کے مقابلے میں downside کو دوگنا کر دیتی ہے۔ 5 minute entry ہر hit پر refresh ہو جاتی ہے، اس لیے مسلسل traffic اسے read prices پر فعال رکھتا ہے اور آپ کو کبھی طویل lifetime کی ادائیگی نہیں کرنی پڑتی۔