لماذا أخطأ وكيلنا السحابي ذاكرة التخزين المؤقت للموجّه، وماذا غيّرت مدة TTL من ساعة واحدة

يجيب وكيل Foxl السحابي عن محادثات الشخص من هاتفه أو من الويب بينما حاسوبه مطفأ. وخلال أول 19 جولة له في بيئة الإنتاج، قرأ 42.6% من مدخلاته من ذاكرة التخزين المؤقت للموجّه (prompt cache). وحين نظرنا في عمليات الكتابة الكبيرة إلى الذاكرة المؤقتة، وجدنا أن كلًا منها جاء بعد فجوة تزيد على خمس دقائق، وهي مدة بقاء السجل في الذاكرة المؤقتة افتراضيًا. والناس الذين يردّون من الهاتف كثيرًا ما يتأخرون أكثر من ذلك.

منحنا سجلات الذاكرة المؤقتة لدى الوكيل مدة بقاء من ساعة واحدة، وأعدنا تشغيل جلسة مقيسة من تسعة استدعاءات. فارتفع معدل الإصابة من 71.8% إلى 85.7%، أو إلى 93.9% إذا استثنيت الاستدعاء الأول الذي يكتب دائمًا. وانخفضت تكلفة الجلسة 8% إجمالًا و15% في جانب المدخلات، مع أن الكتابة بمدة ساعة تكلّف ضعف السعر الأساسي للمدخلات. أما المحادثة التي تنتهي خلال خمس دقائق فتأتي نتيجتها معكوسة: فهي تدفع الضعف عن كل كتابة ولا تقرأ أيًا منها لاحقًا، وبعد إزالة التوقف تكلّف الاستدعاءات التسعة نفسها بإعداد الساعة نحو 23% أكثر منها بإعداد الدقائق الخمس. وقد صدر هذا التغيير في Foxl v0.9.3-beta.5، والطريقة تنطبق على أي وكيل يستدعي Claude عبر Messages API، سواء على Anthropic أو على Amazon Bedrock.

كيف تقيس معدل إصابة التخزين المؤقت للموجّه؟

معدل الإصابة هو حصة توكنات المدخلات في الاستدعاء التي قرأها المزوّد من ذاكرته المؤقتة بدل أن يعالجها من جديد: cache_read / (uncached input + cache_read + cache_write). وتعمل الذاكرة المؤقتة بنقاط التخزين المؤقت. نقطة التخزين المؤقت (breakpoint) علامة cache_control توضع على كتلة واحدة من الطلب، وتطلب من المزوّد تخزين كل ما يصل إلى تلك الكتلة، أي البادئة. ويبقى السجل طوال مدة TTL (time to live، أي مدة البقاء) الخاصة به، وهي خمس دقائق افتراضيًا، والطلب التالي الذي يبدأ بالبادئة نفسها يقرؤه بدل أن يدفع ثمنه مرة أخرى. ويسمّي Bedrock نقاط التخزين المؤقت نقاطَ تحقق (checkpoints).

تُبلغ كل استجابة من Messages API عن ثلاثة عدّادات للمدخلات، وتذكر صفحة Anthropic العلاقة بينها: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. أي أن input_tokens لا يعدّ إلا ما لم يُقرأ من الذاكرة المؤقتة ولم يُكتب فيها، وقسمة cache_read على input_tokens تعطي رقمًا مختلفًا وأكبر بكثير. ويوثّق Converse API في Bedrock الأمر نفسه لحقوله: عند تفعيل التخزين المؤقت، فإن inputTokens «يمثّل توكنات المدخلات غير المخزنة مؤقتًا فقط».

نذكر رقمين لكل تشغيل. معدل الإصابة عبر كل الاستدعاءات يشمل الاستدعاء الأول بعد انتهاء صلاحية الذاكرة المؤقتة، وهو يكتب دائمًا. أما معدل الإصابة بعد الاستدعاء الأول فيبيّن تكلفة المحادثة بعد امتلاء ذاكرتها المؤقتة. وجزء من الموجّه متطابق لكل المستخدمين (نقطة التخزين المؤقت الأولى أدناه)، لذلك قد يقرأ الاستدعاء الأول لشخص ما في بيئة الإنتاج ما كتبته محادثة شخص آخر، ولا يُظهر ذلك إلا الرقم المحسوب عبر كل الاستدعاءات. وقد جرى اختبارنا باسم شخص واحد، فهو لا يقيس ذلك.

يأتي خط الأساس في بيئة الإنتاج من سجلات الفوترة في Foxl للوكيل السحابي: 19 جولة في 8 محادثات منذ الإطلاق، قُرئ فيها 35,054 توكنًا من الذاكرة المؤقتة، وكُتب 47,173، وبقي 72 دون تخزين مؤقت. و35,054 / (35,054 + 47,173 + 72) تساوي 42.6%. وقد كتب الوكيل أكثر مما قرأ: 12,119 توكنًا على الأقل (47,173 ناقص 35,054)، أي نحو ربع ما دفعه للتخزين المؤقت، لم تُقرأ قط.

لماذا يُخطئ وكيل المحادثة ذاكرته المؤقتة

كان مرحل Foxl، وهو الخادم الواقع بين تطبيقات Foxl وBedrock، يضع أصلًا ثلاث نقاط تخزين مؤقت على كل طلب إلى Claude: على آخر أداة، وعلى موجّه النظام، وعلى آخر رسالة من المستخدم، وكلها بمدة TTL الافتراضية البالغة خمس دقائق. وعندما كانت الاستدعاءات متقاربة كانت تصيب. فرسالة متابعة أُرسلت بعد 15 ثانية من رد ما قرأت 3,616 توكنًا وكتبت 44.

أما عمليات الكتابة الكبيرة فجاءت كلها بعد فجوات أطول من خمس دقائق. فالرسالة التي أُرسلت بعد 26 دقيقة من الرد السابق، أو المحادثة التي فُتحت بعد ساعتين من الأخيرة، كتبت البادئة كلها من جديد، أي نحو 3.6 ألف توكن من الأدوات وموجّه النظام. وإرشادات AWS للذاكرة المؤقتة بمدة ساعة تصف هذه الحالة تقريبًا بالضبط: «عند تخزين محادثة طويلة مع مستخدم، حين تتوقع عمومًا أن ذلك المستخدم قد لا يرد خلال الدقائق الخمس التالية».

ثم إن الإصابة تجدّد السجل مجانًا («تُجدَّد الذاكرة المؤقتة دون أي تكلفة إضافية في كل مرة يُستخدم فيها المحتوى المخزّن»). لذلك نادرًا ما يصطدم وكيل يعمل في حلقة أدوات بحدّ الدقائق الخمس، إلا إذا استغرق استدعاء واحد أو أداة واحدة أكثر من خمس دقائق. أما المحادثة مع إنسان فتصطدم به بين الجولات، وهناك تقضي مثل هذه المحادثة معظم وقتها.

أين توضع نقاط التخزين المؤقت الأربع

يمكن أن يحمل طلب Claude أربع نقاط تخزين مؤقت على الأكثر (Anthropic: «يمكنك تحديد ما يصل إلى 4 نقاط تخزين مؤقت»، ويذكر Bedrock الرقم 4 لكل نموذج Claude في جدوله). وتُقرأ البادئة المخزنة بالترتيب tools ثم system ثم messages، وأي تغيير في أي موضع يُبطل كل ما بعده. وكانت نقاط المرحل كلها بمدة خمس دقائق، لذلك صار الوكيل السحابي يضع النقاط الأربع كلها بنفسه، كلًا منها بمدة TTL الخاصة بها. ولا يمسّ المرحل طلبًا يحمل نقاط تخزين مؤقت أصلًا، ولا يضيف إليه شيئًا من عنده.

1. نهاية الجزء المشترك من موجّه النظام. قسمنا موجّه النظام عند بداية الذاكرة الخاصة بكل مستخدم، عند العنوان ## Memory. والأدوات وكل ما فوق ذلك العنوان (من هو الوكيل، وما يستطيع وما لا يستطيع فعله في السحابة) متطابقة في كل محادثة لكل شخص على النموذج نفسه، لذلك تبدأ أي محادثة جديدة تمامًا من أي شخص بقراءتها.
2. نهاية موجّه النظام. تضيف النقطة الثانية ذاكرة الشخص نفسه وسطرًا للتاريخ. ويذكر سطر التاريخ اليوم لا الوقت، فلا يغيّر البادئة بين الاستدعاءات.
3. آخر كتلة قابلة للتخزين المؤقت في رسالة المستخدم السابقة. هذا هو الموضع الذي كتب فيه الاستدعاء السابق بالضبط، فلا تعتمد قراءته على مدى بحث API إلى الوراء. فمن دون هذه النقطة، يبدأ API من أحدث نقطة ويبحث إلى الوراء عن سجل أقدم في الذاكرة المؤقتة، لكن إلى حدّ معيّن فقط («نافذة البحث إلى الوراء 20 كتلة»)، وقد تدفع جولة فيها استدعاءات أدوات كثيرة الكتابة السابقة خارج نطاق الوصول. وطريقة عدّ تلك الكتل تعتمد على المكان الذي تستدعي منه Claude: فـ API الخاص بـ Anthropic يعدّ سلسلة كتل tool_use أو tool_result المتتالية موضعًا واحدًا، بينما لا تقول صفحة Bedrock إلا «نحو 20 كتلة محتوى» ولا تذكر مثل هذا الاستثناء.
4. آخر كتلة قابلة للتخزين المؤقت في أحدث رسالة. هذه هي الكتابة التي سيقرؤها الاستدعاء التالي.

تستخدم النقاط الأربع مدة TTL نفسها. يقبل Bedrock المدتين في طلب واحد ما دام كل سجل بمدة ساعة يأتي أولًا («يجب أن يظهر سجل الذاكرة المؤقتة ذو الساعة الواحدة قبل أي سجلات ذات خمس دقائق»)، ومدة واحدة للنقاط الأربع تضمن ذلك دون أي فحص. ولا توضع النقاط إلا على كتل text وimage وdocument وtool_use وtool_result، وهي محتوى الرسائل الذي تذكر Anthropic أنه قابل للتخزين المؤقت.

لا تحصل على مدة الساعة إلا نماذج Claude التي يذكرها جدول Bedrock مع «Supported TTL: 5 minutes, 1 hour». ويحذّر Bedrock من أن إرسال هذا الحقل إلى نموذج لا يدعم إلا خمس دقائق «قد يؤدي إلى ValidationException»، لذلك تحصل نماذج Claude الأخرى على النقاط الأربع نفسها دون ttl. ولا نمسّ GPT-5.6 وما بعده على Bedrock: فهي تستخدم حقلها الخاص prompt_cache_breakpoint، وبحسب الصفحة نفسها «حدًا أدنى لمدة TTL قدره 30 دقيقة».

// the marker on each of the four blocks, on a model that takes it
"cache_control": { "type": "ephemeral", "ttl": "1h" }

وهناك أيضًا حد أدنى للحجم. لا يخزّن Bedrock نقطة تحقق إلا إذا بلغ كل ما قبلها الطول الأدنى للنموذج: 512 توكنًا في نماذج 5.5، و1,024 أو 4,096 في بعض النماذج الأقدم. وتحت الحد الأدنى «يظل الاستدلال ناجحًا، لكن البادئة لا تُخزَّن مؤقتًا». وعلى نموذج حدّه الأدنى 4,096 توكنًا، يترك موجّه من 3.6 ألف توكن نقطتي الأدوات وموجّه النظام دون تخزين أي شيء، إلى أن تدفع المحادثة نفسها البادئة إلى ما فوق الحد الأدنى، لذا راجع الجدول لكل نموذج تقدّمه.

هل تكلّف الذاكرة المؤقتة بمدة ساعة أكثر مما توفّر؟

بأسعار Anthropic، تكلّف الكتابة بمدة خمس دقائق 1.25 ضعف السعر الأساسي للمدخلات، والكتابة بمدة ساعة ضعفيه، والقراءة 0.1 منه (0.05 على Opus 5.5 وSonnet 5.5). أي أن الكتابة بمدة ساعة تكلّف 0.75 من السعر الأساسي أكثر من الكتابة بمدة خمس دقائق. وتدفع هذه العلاوة على البادئة مرة كل ساعة، وعلى المحتوى الجديد في كل استدعاء في كل مرة. وفي المقابل، لم يعد التوقف الذي يتجاوز خمس دقائق يعيد كتابة البادئة كلها بسعر 1.25 ضعف، بل تُقرأ البادئة بدلًا من ذلك.

لقياس ذلك، شغّلنا شيفرة الإنتاج للوكيل السحابي عبر نسخة محلية من المرحل على Bedrock الحقيقي. السيناريو محادثة واحدة من أربع جولات (خطة تُتابَع بأداة، ثم متابعة، ثم حفظ ملف، ثم سؤال عن الجولة الأولى بعد 6.5 دقيقة)، تليها محادثة جديدة. وهذا يصل إلى تسعة استدعاءات للنموذج على Sonnet 5.5، لأن الجولة التي تستخدم أداة تجري أكثر من استدعاء. وقُرئ الاستهلاك من البث الذي أعاده Bedrock، ويستخدم عمود التكلفة أسعار Foxl الخاصة لكل توكن على Sonnet 5.5.

يكاد الفرق كله يكون في الاستدعاء الذي تلا التوقف البالغ 6.5 دقيقة. فبسجلات الدقائق الخمس، أعاد كتابة بادئته البالغة 5,873 توكنًا. وبسجلات الساعة، قرأ 5,750 توكنًا وكتب 133، وأبلغ Bedrock عن كل كتابة على أنها ephemeral_1h_input_tokens، وبذلك نعرف أن المدة الأطول طُبّقت فعلًا ولم تُتجاهل بصمت. وقرأ تشغيل الساعة 5,880 توكنًا أكثر من تشغيل الدقائق الخمس (35,859 ناقص 29,979)، منها 5,750 من ذلك الاستدعاء وحده، ونحو 130 الباقية من نقل نقاط التخزين المؤقت. ولم يتضمن السيناريو جولة فيها استدعاءات أدوات كثيرة، وهي الحالة التي وُضعت النقطة الثالثة من أجلها. وكانت المدخلات غير المخزنة 28 توكنًا في كل تشغيل.

يحقق إعداد الدقائق الخمس 71.8% في هذا الاختبار مقابل 42.6% في الإنتاج، لأن في الاختبار فجوة واحدة مدتها 6.5 دقيقة، بينما توزعت جولات الإنتاج الـ 19 على 8 محادثات بفجوات من 26 دقيقة ومن ساعتين. فالشيفرة نفسها تحقق نتائج مختلفة جدًا مع حركة استخدام مختلفة، لذلك لا تقارن معدلات الإصابة إلا بين تشغيلات السيناريو نفسه.

ومن دون التوقف تنقلب النتيجة. احذفه من القياسات نفسها، فلا يعيد إعداد الدقائق الخمس كتابة بادئته أبدًا، فيصبح هو الأرخص: إذ يكلّف تشغيل الساعة نحو 23% أكثر إجمالًا ونحو 48% أكثر في المدخلات، لأنه دفع ضعف السعر الأساسي عن كل كتابة ولم يقرأها شيء بعد الدقيقة الخامسة.

ولحركة الاستخدام لديك على Sonnet 5.5 أو Opus 5.5، قارن بين رقمين:

• التوفير: كل توكن من البادئة كان التوقف سيجبرك على إعادة كتابته يوفّر نحو 1.2 من السعر الأساسي (إعادة كتابة بسعر 1.25 تحلّ محلها قراءة بسعر 0.05).
• العلاوة: كل توكن يُكتب في تلك الساعة يكلّف 0.75 من السعر الأساسي أكثر (2 بدل 1.25).

تتقدّم مدة الساعة عندما يكون التوفير أكبر. والمحادثة التي فيها توقف بين خمس دقائق وستين دقيقة تبلغ ذلك عادة، وكذلك محادثة ثانية تبدأ خلال الساعة؛ أما المحادثة التي تنتهي خلال خمس دقائق، دون أي شيء آخر في تلك الساعة، فلا تبلغه. ولمن يجيبون من الهاتف اخترنا ساعة واحدة. أما الوكيل الذي تصل استدعاءاته بفارق ثوانٍ فالأنسب له خمس دقائق.

إن كنت تحجز رصيدًا قبل كل استدعاء، فإن TTL يغيّر الحجز أيضًا. يحجز مرحل Foxl لأسوأ الحالات، فيُحجز للطلب الذي يطلب مدة ساعة بسعر الكتابة بمدة ساعة. وهذا السعر (2 ضعف) يساوي 1.6 مرة سعر الدقائق الخمس (1.25 ضعف)، فيحجز استدعاء Sonnet 5.5 بسياق من 100 ألف توكن نحو $0.40 للمدخلات بدل $0.25. ويبقى المبلغ المخصوم هو ما استهلكه الاستدعاء فعلًا، لكن الرصيد شبه الفارغ قد يُرفض قبل موعده باستدعاء واحد.

ما الذي يحدد السقف

المحتوى الجديد. فكل رسالة جديدة من المستخدم وكل رد يُكتب في الذاكرة المؤقتة مرة واحدة قبل أن يمكن قراءته، فلا يوجد ترتيب لنقاط التخزين المؤقت يتيح لاستدعاء أن يقرأ التوكنات التي يضيفها هو. وفي تشغيل الساعة لم يقرأ الاستدعاء الأول شيئًا، لأن سجلات الدقائق الخمس من التشغيل السابق كانت قد انتهت، فجاءت كل التوكنات المقروءة البالغة 35,859 من الاستدعاءات 2 إلى 9: أي 93.9% من نحو 38,200 توكن من المدخلات استهلكتها. وكانت الـ 2,300 تقريبًا الباقية رسائل ذلك التشغيل وردوده الجديدة، وهذا ما يجعل 93.9% سقف ذلك السيناريو. والمحادثة الأطول تحمل تاريخًا أكبر لكل توكن جديد، فسقفها أعلى.

والبادئة الثابتة الأكبر ترفع النسبة أيضًا، دون أن تجعل أي شيء أرخص. رأينا ذلك حين اكتسب الوكيل السحابي خيارًا لتضمين ملفات ذاكرة المستخدم: أربعة ملفات Markdown (SOUL.md وUSER.md وMEMORY.md وAGENTS.md) يضعها تطبيق Foxl لسطح المكتب في موجّهه الخاص. ينسخها الهاتف أو المتصفح ما دام الحاسوب متصلًا، ويقتطعها بالشيفرة نفسها التي يستخدمها تطبيق سطح المكتب، ويرسلها مع كل رسالة سحابية. وقد بلغت مجموعة حقيقية واحدة من هذه الملفات، بعد اقتطاعها بهذه الطريقة، نحو 41 ألف حرف، أي نحو 14 ألف توكن من المدخلات لكل استدعاء؛ واستخدم التشغيل الثالث ملف اختبار بالحجم نفسه.

في ذلك التشغيل كتب الاستدعاء الأول 17,619 توكنًا من موجّه الشخص، وقرأها كل استدعاء لاحق، وبلغ معدل الإصابة بعد الاستدعاء الأول 98.6%. وكلّف التشغيل أيضًا $0.1219 مقابل $0.0494، لأن الموجّه أكبر بعدة أضعاف؛ ومن دون الذاكرة المؤقتة كانت الاستدعاءات التسعة نفسها ستكلّف $0.4187. كان له أفضل معدل إصابة بين التشغيلات الثلاثة وأكبر فاتورة، ولهذا نضع التكلفة بجوار كل معدل إصابة نذكره.

ما لم نقسه

• الإنتاج بعد التغيير. حتى 2026-10-23 لم تجرِ أي جولة سحابية في بيئة الإنتاج منذ نشر التغيير، لذلك فإن 42.6% هي الرقم الوحيد من الإنتاج، وأرقام «ما بعد التغيير» مأخوذة من المرحل المحلي على Bedrock الحقيقي.
• نماذج أخرى. لم نشغّل إلا Sonnet 5.5. أما نماذج Claude الأخرى التي تحصل على مدة الساعة فتحصل عليها استنادًا إلى جدول Bedrock، وفي حالة Opus 5.5 إلى قياس سابق عبر المرحل أيضًا.
• سيناريوهات أخرى. تسعة استدعاءات بنمط واحد، ليس بينها جولة فيها استدعاءات أدوات كثيرة. والمحادثة التي تبقى خاملة أكثر من ساعة تدفع ثمن الكتابة الأولى مرة أخرى، والساعة الواحدة هي أطول مدة TTL يقدّمها أيّ من المزوّدين لـ Claude.

إن كنت تشغّل وكلاء Claude خاصين بك، فمعدل الإصابة أرخص ما يمكنك فحصه. اجمع العدّادات الثلاثة لكل استدعاء، واقسم القراءات على كل المدخلات، وانظر إلى ما سبق كل استدعاء كتب بادئة كبيرة. فإن جاء بعد فجوة أطول من خمس دقائق، فمدة الساعة تعالج ذلك، كما حدث مع معظم مكسب هذا السيناريو. وإن جاء بعد استدعاء جرى قبله بثوانٍ، فإما أن البادئة تغيّرت بين الاستدعاءين وإما أن الكتابة السابقة كانت خارج نطاق البحث إلى الوراء، وهذا ما تمنعه النقطة الثالثة. ويشرح مقال سابق كيف يبقى الوكيل الفرعي على الذاكرة المؤقتة لوكيله الأم (بالإنجليزية)، وهي قاعدة البادئة نفسها داخل جولة واحدة.