تحریر: Claude prompt caching کا break-even حساب
cache write کی لاگت 1.25x اور read صرف 0.1x ہے، اس لیے Claude prefix دوسرے استعمال پر فائدہ دیتا ہے۔ API سے اپنا break-even حساب اور ثبوت دیکھیں۔
بچت شروع ہونے سے پہلے prompt caching کی لاگت
Prompt caching آپ کے prompt کے ابتدائی حصے کو ہر call پر دوبارہ پڑھنے کے بجائے Claude کو اسے دوبارہ استعمال کرنے دیتا ہے۔ اس کا پورا فیصلہ آپ کے model کی بنیادی input price پر لاگو ہونے والے 2 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 تبدیل نہیں ہوتا۔
اس میں فوری surcharge کے بدلے بعد میں discount ملتا ہے۔ Prefix محفوظ کرنے کے لیے آپ 1 بار اضافی ادائیگی کرتے ہیں۔ اس کے بعد ہر وہ request جو بالکل انہی bytes سے شروع ہو، اس حصے کے لیے معمول کی input price کا دسواں حصہ ادا کرتی ہے۔ اگر prefix اپنی lifetime کے دوران کبھی دوبارہ استعمال نہ ہو تو آپ بلاوجہ 25 percent اضافی ادائیگی کرتے ہیں۔
ایک سطر کے الجبری حساب سے break-even
اگر prefix کو cache کیے بغیر بھیجا جائے تو اس کی بنیادی input cost کو B کہیں۔ Caching کے بغیر N requests کی لاگت N گنا B ہوتی ہے۔ 5 minute cache کے ساتھ پہلی request prefix کو 1.25B پر write کرتی ہے، جبکہ باقی N minus 1 requests اسے 0.1B پر read کرتی ہیں۔ دونوں کو برابر رکھنے پر 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 choice نہیں ہے۔
نیچے دیا گیا chart Claude Opus 5 پر 20,000 token prefix کی قیمت دکھاتا ہے۔ August 2026 تک اس کی base 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 ہو جاتی ہے، جبکہ uncached لاگت $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 میں واقعی وقفے موجود ہوں۔
کمزور cache hit rate کی قیمت
حقیقی network traffic میں cache misses ہوتی ہیں۔ ایسی request جو cache میں miss ہو جائے لیکن پھر بھی breakpoint رکھتی ہو، اسے write کے طور پر charge کیا جاتا ہے۔ اس لیے درست ماڈل یہ ہے کہ cost کو 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 ادا کرتے ہیں، جبکہ cache کے بغیر لاگت $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 رہتی ہے، جو cache کے بغیر والی line سے زیادہ ہے۔ 90 percent پر دونوں کی لاگت بالترتیب $21.50 اور $29.00 رہتی ہے۔ 99 percent پر short cache $11.15 تک پہنچ جاتا ہے، جو cache کے بغیر قیمت کے ایک دسویں حصے کی کم سے کم سطح کے قریب ہے۔
Hit rate وہ عدد ہے جس کی monitoring کرنی چاہیے، کیونکہ prefix size مقرر ہونے کے بعد یہی واحد input ہے جسے آپ کنٹرول کرتے ہیں۔
کون سے 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 tokens پر مشتمل bare system prompt، $7.85 کی uncached لاگت کے مقابلے میں ہر 1,000 requests پر $7.85 بچاتا ہے۔ بڑے پیمانے پر یہ حقیقی بچت ہے، لیکن 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 token prefix، system prompt اور tool definitions کو 90 فیصد hit rate کے ساتھ لیتا ہے اور اسے ماہانہ requests کے حجم پر لاگو کرتا ہے۔
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 کے ساتھ، لیکن مختلف سوال کے ساتھ اسے 2 بار چلائیں۔ پہلی call میں cache_creation_input_tokens کی non-zero قدر اور cache_read_input_tokens کی صفر قدر رپورٹ ہوگی۔ دوسری call میں اس کے برعکس ہوگا، کیونکہ prefix مل چکا تھا۔ input_tokens صرف آخری breakpoint کے بعد موجود tokens کو شمار کرتا ہے، اس لیے کامیاب دوسری call میں یہ قدر کم ہوتی ہے، عموماً صرف نیا user message۔ دونوں calls کا بل بنتا ہے، کیونکہ Claude API کا کوئی free tier نہیں ہے، اگرچہ اوپر بیان کردہ 20,000 token prefix پر یہ جوڑی تقریباً 14 cents کی بنتی ہے۔
محفوظ کیے گئے request body کے خلاف shell سے یہی جانچ 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 تقریباً اس طرح کا 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 کی قیمت ادا کر رہے ہیں اور اس کے بدلے کچھ بھی واپس نہیں مل رہا۔
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 خود manage کرتی ہے۔ یہ آپ کے 4 breakpoint slots میں سے ایک استعمال کرتا ہے۔ ابتدا اسی سے کریں۔ جب آپ کو boundary کی درست جگہ خود متعین کرنی ہو تو explicit breakpoints استعمال کریں۔
درست ترتیب جو cache hit rate ختم کر دیتی ہے
Cache درخواست کے آغاز سے byte بہ byte prefix کا موازنہ کرتا ہے، اور درخواست ایک مقررہ ترتیب میں تیار ہوتی ہے: پہلے tools، پھر system، اور آخر میں messages۔ کسی بھی سطح پر تبدیلی اس سطح اور اس کے بعد آنے والی ہر چیز کو invalid کر دیتی ہے۔ ایک tool description میں ترمیم کرنے سے system prompt اور پیغامات کی پوری history بھی invalid ہو جاتی ہے، حالانکہ آپ نے انہیں تبدیل نہیں کیا ہوتا۔
اس سے ایک ایسا اصول بنتا ہے جس میں کوئی استثنا نہیں: calls کے درمیان جو کچھ تبدیل ہوتا ہے، وہ ہر اس چیز کے بعد آنا چاہیے جو تبدیل نہیں ہوتی۔
عام مسئلہ timestamp ہوتا ہے۔ system prompt کے آغاز میں Current time: 2026-08-03T14:07:11Z پر مشتمل سطر 0 فیصد hit rate کی ضمانت دیتی ہے، کیونکہ prefix hash ہر call پر مختلف ہوتا ہے اور اس سے پہلے کی کوئی entry اس سے match نہیں کر سکتی۔ اسے user message کے آخر میں منتقل کریں۔ Session identifier یا per-request nonce بھی اسی طرح مسئلہ پیدا کرتا ہے اور اس کا حل بھی یہی ہے۔ Retrieved documents جو ہر request پر مختلف ہوں، cached block کے بعد ہونے چاہییں؛ ورنہ وہ ہر stable token کو ایسی boundary کے پیچھے دھکیل دیتے ہیں جو تبدیل ہوتی رہتی ہے۔
دوسرا مسئلہ breakpoint کو تبدیل ہونے والے block پر رکھنا ہے۔ Cache writes breakpoint پر ہوتی ہیں۔ اس لیے اگر وہ block ہر بار مختلف ہو تو کوئی stable مواد کبھی store نہیں ہوتا، اور lookback کو صرف وہ entries ملتی ہیں جو پچھلی requests نے اپنی تبدیل ہوتی ہوئی breakpoints پر لکھی تھیں۔ cache_control کو اس آخری block پر رکھیں جس کا content تمام requests میں یکساں ہو۔
تیسرا مسئلہ ایسا parameter change ہے جسے آپ prompt content نہیں سمجھتے۔ مختلف model کے لیے cache بھی مختلف ہوتا ہے۔ tool choice تبدیل کرنے سے system level سے آگے کا cache 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 ہو جس کے cache ہونے کا آپ کو یقین ہو، تو کسی اور چیز سے پہلے prefix کی لمبائی چیک کریں۔ یہی وجہ ہے کہ caching workload کے لیے سب سے سستا model خودکار طور پر سب سے کم لاگت والا نہیں ہوتا۔ Haiku 4.5 میں caching فعال ہونے کے لیے Opus 5 کے مقابلے میں 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 سے ظاہر ہونے والی لاگت کے مقابلے میں بہت کم ہوتی ہے۔ یہ لاگت ان counters میں ظاہر ہوتی ہے جن کی وضاحت Claude Code token usage کیسے رپورٹ کرتا ہے میں کی گئی ہے۔
یہ اس وقت مدد نہیں کر سکتا جب context کے آغاز کے قریب کوئی edit ہو۔ Conversation history صرف آخر میں شامل ہوتی ہے، اس لیے عام نئے 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 آخر میں رکھیں۔
ناکامی کی صورتیں، اور آپ کو کیا نظر آئے گا
ہر call ایک write ہوتی ہے۔ cache_creation_input_tokens ہر request پر non-zero رہتا ہے، جبکہ cache_read_input_tokens کی قدر 0 رہتی ہے۔ breakpoint سے پہلے یا اسی مقام پر موجود کوئی چیز calls کے درمیان تبدیل ہو رہی ہے۔ مسلسل دو requests پر تیار کردہ prefix کے پہلے 200 characters print کریں اور انہیں بصری طور پر compare کریں۔
دونوں counters کی قدر 0 ہے۔ prefix ماڈل کی minimum حد سے کم ہے، یا cache_control field کبھی API تک نہیں پہنچی۔ پہلے prefix کے tokens شمار کریں، پھر وہ request body log کریں جو حقیقت میں بھیجی گئی تھی۔
Reads کام کرتی ہیں، پھر رک جاتی ہیں۔ پہلے hits کا سلسلہ، پھر ایک write، اور اس کے بعد دوبارہ hits۔ requests کے درمیان وقفہ lifetime سے زیادہ طویل تھا۔ write کو قبول کریں، یا hit rate کے 53 percent سے زیادہ ہونے کی تصدیق کے بعد 1 hour TTL استعمال کریں۔
Deploy کے بعد hit rate کم ہو جاتی ہے۔ کسی tool description میں ترمیم کی گئی یا model تبدیل کیا گیا۔ دونوں تبدیلیاں پورے prefix کو invalid کر دیتی ہیں۔ prompt کو متاثر کرنے والے ہر deploy کے بعد writes کا ایک مہنگا دور متوقع رکھیں۔
Caching فعال کرنے کے بعد bill بڑھ گیا۔ آپ کا hit rate break-even سطح سے کم ہے۔ 5 minute cache پر تقریباً 22 percent سے کم hit rate کی صورت میں prefix کو uncached بھیجنا سستا ہے، اور 1 hour cache کے لیے تقریباً 53 percent سے کم hit rate پر بھی یہی بات درست ہے۔
FAQ
کسی prompt کو cache کرنے سے فائدہ اٹھانے کے لیے اسے کتنی بار دوبارہ استعمال کرنا ضروری ہے؟
5 minute cache میں ایک بار۔ write کی لاگت base input کی 1.25x ہے اور read کی لاگت 0.1x ہے۔ اس لیے N uncached requests کی لاگت N ہوتی ہے، جبکہ N cached requests کی لاگت 1.25 جمع 0.1 ضرب N منفی 1 ہوتی ہے۔ دونوں N = 1.28 پر برابر ہوتے ہیں، اس لیے دوسری request ہی سے فائدہ شروع ہو جاتا ہے۔ 1 hour cache میں write کی لاگت 2x ہے اور برابری N = 2.11 پر آتی ہے، اس لیے اسے دو reads درکار ہوتے ہیں۔
cache_read_input_tokens ہمیشہ صفر کیوں ہوتا ہے؟
پہلے prefix کی لمبائی چیک کریں۔ اگر یہ model minimum سے کم ہو، جو August 2026 تک Claude Opus 5 کے لیے 512 tokens اور Claude Haiku 4.5 کے لیے 4,096 ہے، تو caching خاموشی سے skip ہو جاتی ہے اور دونوں counters کی قدر 0 رہتی ہے۔ اگر prefix کافی طویل ہو تو دیکھیں کہ breakpoint پر یا اس سے پہلے ایسا content تو موجود نہیں جو calls کے درمیان تبدیل ہوتا ہو، مثلاً system prompt میں timestamp یا session identifier۔ اگر counters پہلے کام کر رہے تھے اور پھر رک گئے ہیں تو requests کے درمیان وقفہ cache lifetime سے زیادہ تھا۔
کیا prompt caching سے Claude کے جوابات تبدیل ہو جاتے ہیں؟
نہیں۔ cache ان tokens کی processed شکل محفوظ کرتا ہے جو آپ پہلے ہی بھیج چکے ہیں، اور model دونوں صورتوں میں ایک ہی prompt دیکھتا ہے۔ یہ billing اور latency کی سہولت ہے، behaviour میں تبدیلی نہیں۔ اس کا مطلب یہ بھی ہے کہ آپ کسی working prompt پر اسے enable کر سکتے ہیں، اور evaluations دوبارہ چلانے کی ضرورت نہیں۔
کیا مجھے 1 hour cache کے لیے ادائیگی کرنی چاہیے؟
صرف اس وقت جب آپ کے traffic میں 5 minutes سے زیادہ کے وقفے ہوں اور آپ کی hit rate تقریباً 53 percent سے زیادہ رہنے کی توقع ہو۔ miss ہونے کی صورت میں 2x write، 1.25x write کے مقابلے میں دوگنا اضافی بوجھ ڈالتی ہے۔ 5 minute entry ہر hit پر refresh ہو جاتی ہے، اس لیے مسلسل traffic اسے read prices پر فعال رکھتا ہے اور زیادہ lifetime کی قیمت ادا نہیں کرنی پڑتی۔