بقلم حساب نقطة التعادل لتخزين Claude prompt مؤقتاً
تكلّف كتابة الـcache 1.25x والقراءة 0.1x؛ لذلك يصبح prefix في Claude أوفر من الاستخدام العادي عند الطلب الثاني. احسبها وأثبتها من API.
تكلفة تخزين الـprompt مؤقتاً قبل أن تحقق وفراً
يتيح تخزين الـprompt مؤقتاً لـClaude إعادة استخدام بداية الـprompt بدلاً من قراءتها مرة أخرى مع كل استدعاء. ويعتمد القرار بالكامل على معامليْن يطبَّقان على سعر الإدخال الأساسي للنموذج. اعتباراً من August 2026، تكلّف كتابة الـcache مقدار 1.25x من سعر الإدخال الأساسي عند استخدام مدة صلاحية 5 minutes، أو 2x عند استخدام مدة صلاحية 1 hour. أما قراءة الـcache فتكلّف 0.1x. تنطبق هذه المعاملات على جميع النماذج، لذلك لا تتغير نقطة التعادل أدناه عند تغير السعر لكل token.
المقايضة هي رسم إضافي الآن مقابل خصم لاحق. تدفع مبلغاً إضافياً مرة واحدة لتخزين prefix. ثم تدفع كل طلبات لاحقة تبدأ بالـbytes نفسها تماماً عُشر سعر الإدخال المعتاد لذلك الجزء. أما الـprefix الذي لا يعاد استخدامه خلال مدة صلاحيته، فيكلفك 25 percent إضافية بلا فائدة.
نقطة التعادل، في سطر واحد من الجبر
سمِّ B تكلفة الإدخال الأساسية للبادئة إذا أرسلتها من دون تخزين مؤقت. من دون التخزين المؤقت، تكلّف N من الطلبات B مضروبة في N. مع التخزين المؤقت لمدة 5 دقائق، يكتب الطلب الأول البادئة بتكلفة 1.25B، وتقرأها الطلبات N ناقص 1 الأخرى بتكلفة 0.1B. ساوِ بين التكلفتين، فتحصل على 0.9N = 1.15، ومنه N = 1.28. يصبح الطلب الثاني أرخص من عدم استخدام التخزين المؤقت على الإطلاق.
كرّر الحساب نفسه مع كتابة التخزين المؤقت لمدة ساعة بتكلفة 2x، فتحصل على 0.9N = 1.9، ومنه N = 2.11. يحتاج التخزين المؤقت الطويل إلى قراءتين قبل الوصول إلى نقطة التعادل، ولذلك لا يكون الخيار الافتراضي.
يحسب المخطط أدناه التكلفة لبادئة تتكون من 20,000 رمز على Claude Opus 5، الذي يبلغ سعر الإدخال الأساسي فيه $5 لكل مليون رمز اعتباراً من August 2026. اضرب كل قيمة في 0.6 لنموذج سعره $3 لكل مليون رمز. لا يتغير شكل المنحنى.
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"
}
]تكلّف مطالبة واحدة بمفردها $0.10 من دون تخزين مؤقت، و$0.125 مع التخزين المؤقت، لذلك فإن تخزين مطالبة تُستخدم مرة واحدة مؤقتاً يمثل خسارة صافية. عند الطلب الثاني، تبلغ تكلفة التخزين المؤقت لمدة 5 دقائق $0.135 مقابل $0.20. ويظل التخزين المؤقت لمدة ساعة أعلى تكلفة في تلك النقطة، إذ يبلغ $0.21 مقابل $0.20 نفسها، ولا يتجاوز تكلفة عدم التخزين المؤقت إلا عند الطلب الثالث: $0.22 مقابل $0.30. وعند 20 من الطلبات، يصبح الفرق $2.00 مقابل $0.315.
تؤدي إصابة التخزين المؤقت أيضاً إلى تحديث الإدخال، ولذلك يطلق جدول الأسعار المنشور على ذلك العمود اسم إصابات التخزين المؤقت وتحديثاته. لذلك تحافظ نقطة نهاية نشطة على إدخال مدة 5 دقائق إلى أجل غير مسمى بأسعار القراءة، بينما لا تستفيد مدة الساعة من تكلفة الكتابة البالغة 2x إلا عندما تتخلل حركة المرور لديك فواصل فعلية.
ما تكلّفه نسبة إصابة منخفضة
تحدث حالات عدم إصابة فعلية في حركة الشبكة. يُحاسَب الطلب الذي لا يصيب ذاكرة التخزين المؤقت لكنه لا يزال يتضمن نقطة توقف باعتباره عملية كتابة، لذلك فإن الطريقة الدقيقة لنمذجة ذلك هي حساب التكلفة بوصفها دالة في نسبة الإصابة. يوضّح المخطط أدناه ذلك بالنسبة إلى 1,000 طلب، يحمل كل منها البادئة نفسها المؤلفة من 20,000 رمز.
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 بالمئة، تدفع $125.00 بدلاً من $100.00، وتضاعف ذاكرة التخزين المؤقت لمدة 1 ساعة الفاتورة لتصل إلى $200.00. بحل المعادلة 1.25 ناقص 1.15h = 1، تبدأ ذاكرة التخزين المؤقت لمدة 5 دقائق في توفير المال عند نسبة إصابة تبلغ نحو 22 بالمئة، ولذلك تظهر قيمة $96.25 عند 25 بالمئة. وتؤدي العملية الحسابية نفسها مع الكتابة المضاعفة 2x إلى نسبة تبلغ نحو 53 بالمئة لذاكرة التخزين المؤقت لمدة 1 ساعة، ولذلك تظل نسبة إصابة قدرها 50 بالمئة تكلّف $105.00، أي أعلى من خط التكلفة دون تخزين مؤقت. عند 90 بالمئة، تصل القيمتان إلى $21.50 و$29.00. وعند 99 بالمئة، تصل ذاكرة التخزين المؤقت القصيرة إلى $11.15، وهي قريبة من الحد الأدنى البالغ عُشر السعر دون تخزين مؤقت.
نسبة الإصابة هي القيمة التي يجب قياسها، لأنها المدخل الوحيد الذي يمكنك التحكم فيه بعد تثبيت حجم البادئة.
البادئات التي تستحق نقطة تخزين مؤقت
قد يحمل الطلب ما يصل إلى أربع نقاط لتخزين البادئات مؤقتاً، لذا فالسؤال هو: ما الكتل التي تستحق تخصيص نقطة لها؟ المرشحة هي الكتل المتطابقة بايتاً عبر الطلبات، والكبيرة بما يكفي لتؤثر في التكلفة. يوضح المخطط أدناه تكلفة أربعة أشكال شائعة عبر 1,000 طلب، مع معدل إصابة يبلغ 90 بالمئة في ذاكرة التخزين المؤقت التي مدتها 5 دقائق.
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"
}
]يوفّر system prompt بسيط يحتوي على 2,000 رمزاً $7.85 لكل 1,000 طلب، مقارنةً بتكلفة $10.00 من دون تخزين مؤقت. هذا مبلغ فعلي عند التوسع، لكنه ليس ما يجعل التخزين المؤقت مهماً. أضف تعريفات الأدوات، وستصل إلى 8,000 رمزاً، مع توفير $31.40. أما مستند سياسة يحتوي على 25,000 رمزاً، وتطرح كل الطلبات أسئلة عنه، فيوفّر $98.12. أما الصف الأخير فهو الذي يغيّر البنية: إذ تكلّفك 120,000 رمزاً من سياق قاعدة الشفرة أو نص المحادثة $600.00 من دون تخزين مؤقت، و$129.00 مع التخزين المؤقت، أي توفير $471.00.
تزداد الوفورات مع حجم البادئة ومع معدل الإصابة، ولا تعتمد على أي عامل آخر. وهذا يغيّر ما يستحق وضعه في الطلب من الأساس: ما تكلّفه فعلياً مليون من رموز Claude ينخفض إلى عُشر السعر المعلن لأي محتوى ترسله أكثر من مرة.
كيف يبدو ذلك في فاتورة شهرية
يأخذ المخطط أدناه بادئة الرمز المميز 8,000 المذكورة أعلاه، مع مطالبة نظام وتعريفات الأدوات، وبمعدل إصابة قدره 90 بالمئة، ثم يوسّعها لتشمل أحجام الطلبات الشهرية.
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 طلب شهرياً، يبلغ التوفير $314.00، وهو الفرق بين $400.00 و$86.00. وعند 100,000 طلب، يبلغ التوفير $3,140.00. وعند مليون طلب، تبلغ تكلفة المدخلات غير المخزنة مؤقتاً $40,000.00، ويزيل التخزين المؤقت منها $31,400.00. تتعلق هذه الأرقام برموز المدخلات فقط. تُسعَّر المخرجات بشكل منفصل، ولا يؤثر التخزين المؤقت فيها، لذا تذكّر ذلك قبل أن تعد أي شخص بخفض الفاتورة بنسبة 90 بالمئة. يأتي التخزين المؤقت إلى جانب الممارسات الأوسع الواردة في إبقاء فاتورة وكيل ذكاء اصطناعي تحت السيطرة على VPS.
كيفية إثبات عمل التخزين المؤقت
لا تعتمد على التصميم وحده. اقرأ قسم الاستخدام في الاستجابة. يعرض كل رد من Messages API عدد الرموز المميزة التي كتبها في ذاكرة التخزين المؤقت، وعدد الرموز المميزة التي قرأها منها، وعدد الرموز الجديدة التي اضطر إلى معالجتها.
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)شغّله مرتين باستخدام المستند نفسه وسؤال مختلف. يعرض الاستدعاء الأول قيمة غير صفرية لـ cache_creation_input_tokens وقيمة صفرية لـ cache_read_input_tokens. ويعكس الاستدعاء الثاني ذلك لأن البادئة عُثر عليها في ذاكرة التخزين المؤقت. يحسب input_tokens الرموز المميزة التي تأتي بعد آخر نقطة توقف فقط، ولذلك تكون قيمته صغيرة في الاستدعاء الثاني السليم، وعادةً ما تقتصر على رسالة المستخدم الجديدة. تُحتسب تكلفة الاستدعاءين، لأن Claude API لا يوفّر فئة مجانية، رغم أن بادئة من 20,000 رمز مميز، وفق السعر الموضح أعلاه، تكلف نحو أربعة عشر سنتاً.
يمكنك إجراء الفحص نفسه من 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'يطبع الاستدعاء الثاني السليم شيئاً يشبه ما يلي:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}يخبرك سطر واحد بالحقيقة. إذا ظل cache_read_input_tokens يساوي 0 في جميع الاستدعاءات، فأنت تدفع تكلفة الكتابة البالغة 1.25x في كل مرة، ولا تستفيد من أي شيء مقابلها.
بالنسبة إلى مدة الصلاحية البالغة 1 hour، تحمل نقطة التوقف مدة بقاء (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}يتوفر أيضاً التخزين المؤقت التلقائي: حقل cache_control واحد في المستوى الأعلى من الطلب، وبعده يدير API نقاط التوقف تلقائياً مع نمو المحادثة. يستهلك هذا الحقل إحدى خانات نقاط التوقف الأربع المتاحة لك. ابدأ بهذا الخيار. وانتقل إلى نقاط التوقف الصريحة عندما تحتاج إلى تحديد موضع الحد بدقة.
قاعدة الترتيب التي تقضي على معدلات الإصابة
تطابق الذاكرة المؤقتة بادئةً بايتاً ببايت بدءاً من بداية الطلب، ويُجمَّع الطلب بترتيب ثابت: الأدوات، ثم النظام، ثم الرسائل. يؤدي أي تغيير على أي مستوى إلى إبطال ذلك المستوى وكل ما يليه. إذا عدّلت وصف أداة واحدة، فسيُبطَل أيضاً موجّه النظام وسجل الرسائل بالكامل، رغم أنك لم تلمسهما.
ينتج عن ذلك rule واحدة بلا استثناءات. يجب أن يأتي كل ما يتغير بين الاستدعاءات بعد كل ما لا يتغير.
المتسبب المعتاد هو الطابع الزمني. يضمن وجود سطر يقرأ Current time: 2026-08-03T14:07:11Z في أعلى موجّه النظام معدل إصابة قدره 0 بالمئة، لأن تجزئة البادئة تختلف في كل استدعاء، ولا يمكن لأي إدخال سابق أن يطابقها. انقله إلى رسالة المستخدم، في النهاية. ويؤدي معرّف الجلسة أو nonce خاص بكل طلب إلى المشكلة نفسها، والحل نفسه ينطبق عليهما. يجب أن تأتي المستندات المسترجعة التي تختلف من طلب إلى آخر بعد الكتلة المخزنة مؤقتاً أيضاً، وإلا دفعت كل رمز ثابت خلف حد يتغير موضعه.
المتسبب الثاني هو وضع نقطة التوقف على الكتلة التي تتغير. تحدث عمليات الكتابة إلى الذاكرة المؤقتة عند نقطة التوقف، لذلك إذا اختلفت تلك الكتلة في كل مرة فلن يُخزَّن أي محتوى ثابت، ولن يعثر البحث في السجل السابق إلا على إدخالات كتبتها الطلبات السابقة عند نقاط توقفها المتغيرة. ضع cache_control على آخر كتلة يكون محتواها متطابقاً بين الطلبات.
المتسبب الثالث هو تغيير معامل لم تعتبره جزءاً من محتوى الموجّه. لكل model مختلف ذاكرة مؤقتة مختلفة. يؤدي تغيير اختيار الأداة إلى الإبطال بدءاً من مستوى النظام وما يليه. تؤدي إضافة أداة أو إزالتها إلى إبطال كل شيء.
الحد الأدنى للطول، وعدم تنفيذ العملية بصمت
لا يُخزَّن prefix أقصر من الحد الأدنى للنموذج في ذاكرة التخزين المؤقت، ولا يخبرك النظام بذلك. لا يظهر خطأ ولا تحذير. ينجح الطلب، ويعرض العدّادان القيمة 0. اعتباراً من August 2026، الحدود الدنيا المنشورة هي:
- 512 token على Claude Opus 5 وClaude Fable 5
- 1,024 token على Claude Sonnet 5 وClaude Opus 4.8
- 4,096 token على Claude Haiku 4.5
إذا عرض العدّادان القيمة 0 في طلب تعتقد أنه مخزّن مؤقتاً، فتحقق من طول prefix قبل أي شيء آخر. وهذا يفسر أيضاً سبب عدم كون النموذج الأرخص هو الأرخص تلقائياً في أعباء العمل التي تستخدم التخزين المؤقت. يحتاج Haiku 4.5 إلى prefix أطول بثماني مرات من Opus 5 قبل تفعيل التخزين المؤقت، لذلك يُخزّن system prompt مكوّن من 2,000 token على أحدهما، بينما يُتجاهل بصمت على الآخر.
مكان تخزين Claude Code المؤقت لك، والمواضع التي لا يمكنه فيها مساعدتك
يخزّن Claude Code البادئة الخاصة به مؤقتاً. تكون مطالبة النظام وتعريفات الأدوات في مقدمة كل طلب ولا تتغير مواضعها، لذلك تُكتب مرة واحدة ثم تُقرأ مجدداً طوال بقية الجلسة. لهذا تكون تكلفة كل دور في الجلسة الطويلة أقل بكثير مما يوحي به حجم السياق، ويظهر ذلك في العدادات الموضحة في كيفية إبلاغ Claude Code عن استخدام الرموز.
لا يمكنه مساعدتك عند تعديل جزء قريب من بداية السياق. سجل المحادثة قابل للإلحاق فقط، لذلك تضيف الأدوار الجديدة العادية امتداداً إلى بادئة مخزنة مؤقتاً بالفعل. يؤدي تعديل ملف قُرئ في وقت مبكر من الجلسة إلى تغيير المحتوى في منتصف تلك البادئة، ويجب عندها كتابة كل رمز يأتي بعد التغيير من جديد. ويحدث الأمر نفسه بعد فترة خمول طويلة، لأن الإدخال تنتهي صلاحيته، ويدفع الدور التالي تكلفة كتابة كاملة. هذا ليس خطأً. في الحالتين، تعمل قاعدة البادئة كما هو محدد لها تماماً.
إذا كنت تكتب عميلك الخاص بدلاً من ذلك، فطبّق هذا التخطيط منذ الطلب الأول ولا تحاول إضافته لاحقاً: أنشئ الاستدعاء بالطريقة الموضحة في أول تطبيق Claude API على VPS، مع وضع الكتل الثابتة أولاً والمتغيرة أخيراً.
أوضاع الفشل وما ستراه
كل استدعاء هو عملية كتابة. تكون قيمة cache_creation_input_tokens غير صفرية في كل طلب، بينما تبقى cache_read_input_tokens مساوية لـ0. يتغير شيء ما عند نقطة التوقف أو قبلها بين الطلبات. اطبع أول 200 حرف من البادئة التي جمّعتها في طلبين متتاليين، ثم قارنهما بصرياً.
العدّادان يساويان 0. البادئة أقصر من الحد الأدنى الذي يتطلبه النموذج، أو أن الحقل cache_control لم يصل إلى واجهة API. احسب رموز البادئة أولاً، ثم سجّل نص الطلب الذي أرسلته فعلياً.
تعمل عمليات القراءة ثم تتوقف. تحصل على سلسلة من مرات الإصابة، ثم عملية كتابة، ثم تعود مرات الإصابة. كانت الفجوة بين الطلبات أطول من مدة الصلاحية. اقبل عملية الكتابة، أو انتقل إلى TTL لمدة 1 hour بعد التحقق من أن معدل الإصابة يتجاوز 53 percent.
ينخفض معدل الإصابة بعد عملية نشر. عُدّل وصف أداة أو تغيّر نموذج. يؤدي كلا الأمرين إلى إبطال البادئة بالكامل. توقّع جولة واحدة مكلفة من عمليات الكتابة بعد كل عملية نشر تعدّل prompt.
ارتفعت الفاتورة بعد تفعيل التخزين المؤقت. معدل الإصابة لديك أقل من نقطة التعادل. عند معدل يقل تقريباً عن 22 percent في ذاكرة التخزين المؤقت لمدة 5 minutes، يكون إرسال البادئة من دون تخزين مؤقت أقل تكلفة. وينطبق الأمر نفسه على ذاكرة التخزين المؤقت لمدة 1 hour عندما يقل المعدل عن 53 percent.
FAQ
كم مرة يجب إعادة استخدام الطلب قبل أن يصبح التخزين المؤقت مجدياً؟
مرة واحدة، في التخزين المؤقت لمدة 5 دقائق. تكلّف عملية الكتابة 1.25x من تكلفة الإدخال الأساسية، وتكلّف القراءة 0.1x، لذلك تكلّف N من الطلبات غير المخزنة مؤقتاً N، بينما تكلّف N من الطلبات المخزنة مؤقتاً 1.25 زائد 0.1 مضروباً في N ناقص 1. يتساوى الخياران عند N = 1.28، لذلك يكون الطلب الثاني أوفر بالفعل. يكتب التخزين المؤقت لمدة 1 ساعة بتكلفة 2x، ويتساوى الخياران عند N = 2.11، لذلك يحتاج إلى قراءتين.
لماذا تكون cache_read_input_tokens صفراً دائماً؟
تحقق أولاً من طول البادئة: إذا كان أقل من الحد الأدنى للنموذج، وهو 512 رمزاً في Claude Opus 5 و4,096 في Claude Haiku 4.5 اعتباراً من August 2026، يتم تخطي التخزين المؤقت بصمت وتبقى العدّاداتان عند 0. إذا كان طول البادئة كافياً، فابحث عن محتوى يتغير بين الاستدعاءات ويقع عند نقطة الفصل أو قبلها، مثل طابع زمني أو معرّف جلسة في system prompt. إذا كانت العدّادات تعمل ثم توقفت، فالفاصل بين الطلبات كان أطول من مدة بقاء التخزين المؤقت.
هل يغيّر التخزين المؤقت للطلبات إجابات Claude؟
لا. يخزن التخزين المؤقت الشكل المعالَج للرموز التي أرسلتها مسبقاً، ويرى النموذج الطلب نفسه في الحالتين. هذه ميزة للفوترة وزمن الاستجابة، وليست تغييراً في السلوك. وهذا يعني أيضاً أنه يمكنك تفعيله في طلب يعمل من دون إعادة تشغيل تقييماتك.
هل ينبغي أن أدفع مقابل التخزين المؤقت لمدة 1 ساعة؟
فقط عندما تتضمن حركة الطلبات لديك فواصل أطول من 5 دقائق، ويظل معدل إصابة التخزين المؤقت أعلى من نحو 53 بالمئة. تكلفة الكتابة البالغة 2x تعادل ضعف الجانب السلبي لتكلفة الكتابة البالغة 1.25x عند عدم حدوث إصابة. يتم تحديث إدخال التخزين المؤقت لمدة 5 دقائق عند كل إصابة، لذلك تحافظ حركة الطلبات المنتظمة على بقائه بتكلفة القراءة من دون دفع تكلفة مدة البقاء الأطول.