التخزين المؤقت للموجّهات في OpenAI وClaude: آلية العمل وTTL والأسعار وأسباب عدم نجاحه وطريقة التحقق

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

يقارن هذا المقال بين التخزين المؤقت للموجّهات لدى OpenAI ولدى Anthropic اعتمادًا على النص الأصلي لصفحات OpenAI ‏«Prompt caching» و«Prompt cache diagnostics» و«Pricing»، وصفحات Anthropic ‏«Prompt caching» و«Cache diagnostics» و«Pricing» و«Rate limits». ويشرح كيف تختلف المواصفتان، وكيف تحصل على إصابات في التخزين المؤقت، وكيف تتأكد من أنك تحصل عليها. راجعنا كل الأرقام على الصفحات الأصلية في 3 أكتوبر 2026. وللاطلاع على الصورة الأشمل لخفض تكاليف الواجهات البرمجية (اختيار النموذج، والمعالجة الدفعية، والتحكم في المخرجات، وغير ذلك)، راجع مقالنا «كيف توفّر في تكلفة الذكاء الاصطناعي والرموز».

1. ما التخزين المؤقت للموجّهات: إعادة استخدام بادئة متطابقة

في كل مرة يقرأ فيها نموذج لغوي مدخلاته، يحسب قيمًا وسيطة لكل رمز (موتّرات KV، أي المفاتيح والقيم). يحفظ التخزين المؤقت للموجّهات هذه القيم من بداية الموجّه حتى نقطة معيّنة، ويتخطّى الحساب عندما يبدأ الطلب التالي بالرموز نفسها تمامًا. ويوضّح دليل OpenAI أن ما يُحفظ هو قيم KV لا الرموز نفسها.

النقطة الأساسية أنه لا يمكن إعادة استخدام إلا الجزء المتطابق من البداية تمامًا. في الطلبين التاليين، لا يُعاد استخدام إلا التعليمات والمستندات.

Request 1: [Instructions 5,000 tokens][Documents 20,000 tokens][Question A]
Request 2: [Instructions 5,000 tokens][Documents 20,000 tokens][Question B]
           └────────────── identical up to here ──────────────┘└ differs  ┘
→ The 25,000 tokens of instructions + documents can be reused

Request 3: [Today's date][Instructions 5,000 tokens][Documents 20,000 tokens][Question C]
           └─ differs ──┘
→ Even though the rest matches, not a single token can be reused

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

2. التخزين المؤقت للموجّهات في OpenAI وAnthropic جنبًا إلى جنب

في 22 سبتمبر 2026 أعلنت OpenAI تحسينات في التخزين المؤقت لـGPT-6، وتغيّرت الآلية في GPT-5.6 والنماذج اللاحقة (الاحتفاظ لمدة 30 دقيقة، ونقاط القطع الصريحة، والكتابة المدفوعة في التخزين المؤقت، وغير ذلك). يصف عمود OpenAI في الجدول أدناه GPT-5.6 وما بعده، وتأتي الفروق الخاصة بـGPT-5.5 وما قبله بعد الجدول.

المصادر: OpenAI ‏«Prompt caching» و«Prompt cache diagnostics»؛ Anthropic ‏«Prompt caching» و«Cache diagnostics» و«Rate limits» (رُوجعت في 3 أكتوبر 2026)

أما GPT-5.5 والنماذج الأقدم فلديها تخزين مؤقت ضمني فقط، بنقاط قطع توضع تلقائيًا على فترات ثابتة، ودون رسوم إضافية على الكتابة في التخزين المؤقت. وتُضبط مدة الاحتفاظ عبر prompt_cache_retention: بحسب الدليل، يستمر in_memory «نحو 5 إلى 10 دقائق من عدم النشاط، وحتى ساعة»، ويستمر 24h «عادةً نحو 30 دقيقة، وحتى 24 ساعة». عند الانتقال إلى GPT-5.6 أو ما بعده، استبدل هذا الإعداد بـprompt_cache_options.ttl.

أسعار الرموز لكل نموذج موجودة في مقارنتنا «مقارنة أسعار Claude وChatGPT». ولنماذج GPT-6 ‏(Astra وSol وLuna) راجع «مقالنا عن GPT-6 Sol وLuna»، وللنماذج الحالية لدى كل المزوّدين راجع «تواريخ قطع المعرفة لنماذج الذكاء الاصطناعي».

3. متى يصيب التخزين المؤقت: البادئة والحد الأدنى للطول ومدة TTL والنطاق

البادئة المشتركة وترتيب الطلب

على المنصتين، يصيب التخزين المؤقت فقط عندما تتطابق البادئة حتى نقطة القطع تمامًا. يقرأ Claude الطلب من بدايته بالترتيب tools → system → messages، لذا فإن تغيير تعريف أداة واحدة يُبطل التخزين المؤقت لموجّه النظام وسجل المحادثة اللذين يليانه. وتوضّح OpenAI بالمثل أن تعريفات الأدوات وتنسيق المخرجات (text.format) ومستوى الاستدلال (reasoning.effort) والإعدادات المشابهة جزء من البادئة.

عمليًا، الترتيب واحد لدى الطرفين: ضع ما لا يتغيّر (تعريفات الأدوات، والتعليمات، والمستندات) أولًا، وما يتغيّر مع كل طلب (التواريخ، وبيانات كل مستخدم، والسؤال) أخيرًا. وأضِف إلى المحادثة بالإلحاق في آخرها، دون إعادة كتابة السجل.

وضع نقاط القطع: تلقائيًا أم يدويًا

يضع الوضع الضمني لدى OpenAI (‏GPT-5.6 وما بعده) نقطة قطع في نهاية أحدث رسالة مؤهلة (رسالة مستخدم، أو آخر نتيجة في سلسلة نتائج أدوات، وما إلى ذلك). وفي وضع «الصريح فقط» لا تصبح نقاط قطع إلا المواضع التي تضيف إليها prompt_cache_breakpoint، وإن لم تضف أيًّا منها، فلن يُستخدم التخزين المؤقت ولن تدفع سعر الكتابة أيضًا.

أما التخزين المؤقت التلقائي في Claude، الذي يُفعَّل بإضافة "cache_control": {"type": "ephemeral"} واحد في المستوى الأعلى، فيضع نقطة قطع على آخر كتلة قابلة للتخزين المؤقت ويحرّكها إلى الأمام مع نمو المحادثة. وبإضافة cache_control إلى كتل بعينها تختار نقاط القطع بنفسك.

// Claude: نقطة قطع في نهاية موجّه النظام الثابت (نقطة قطع صريحة)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "تعليمات ومستندات طويلة...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "سؤال اليوم..." }]
}

// OpenAI (Responses API): نقطة قطع بعد التعليمات الثابتة، وضع الصريح فقط
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "تعليمات ومستندات طويلة...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "سؤال اليوم..." }
  ]
}

الحد الأدنى للطول: البادئات القصيرة لا تُخزَّن مؤقتًا

في GPT-5.6 وما بعده، الحد الأدنى لدى OpenAI هو 1,024 رمزًا من المدخلات المرئية (لا تُحتسب التعليمات المخفية التي تضيفها OpenAI في الخلفية). أما في Claude فيعتمد على النموذج.

المصدر: Anthropic ‏«Prompt caching»، قسم Cache limitations (رُوجع في 3 أكتوبر 2026). في Bedrock تُطبَّق القيم الواردة في وثائق AWS.

إذا كان موجّه Claude أقصر من الحد الأدنى، فإن إضافة cache_control لا تُطلق خطأً، بل لا يُخزَّن الموجّه مؤقتًا بصمت. وفي هذه الحالة تكون قيمتا cache_creation_input_tokens وcache_read_input_tokens في usage صفرًا. ويتغيّر الحد الأدنى عند تبديل النموذج، فقد تتوقف بادئة كانت تُخزَّن مؤقتًا في النموذج السابق عن التخزين (ويحذّر دليل OpenAI من الأمر نفسه).

مدة TTL: انتبه إلى نقطة بدء العدّ

في OpenAI (‏GPT-5.6 وما بعده) يبقى التخزين المؤقت «30 دقيقة على الأقل بعد آخر كتابة أو إعادة استخدام، وقد يستمر مدة أطول». ويستخدم Claude ‏5 دقائق افتراضيًا، واختيار الساعة يجعل الكتابة بضعف سعر الإدخال. وعلى المنصتين تتجدد مدة TTL دون تكلفة إضافية مع كل استخدام للتخزين المؤقت.

في Claude فخّ واحد: تُحسب مدة TTL من بداية الطلب، لا من نهاية الاستجابة. في مثال الوثائق، إذا استغرق توليد استجابة 4 دقائق، فيجب أن يبدأ الطلب التالي خلال نحو دقيقة واحدة من انتهاء تلك الاستجابة كي يصيب تخزين الدقائق الخمس. وبالنسبة إلى الوكلاء الذين يولّدون مخرجات طويلة، فإن 5 دقائق أقصر مما تبدو.

نطاق التخزين المؤقت ومكان وجوده

التخزين المؤقت لدى OpenAI على مستوى المؤسسة ولا يُشارَك بين مناطق المعالجة (إعدادات إقامة البيانات). ويذكر الدليل أيضًا أن التخزين المؤقت يوجد على أجهزة بعينها، وأنه عند تجاوز نحو 15 طلبًا في الدقيقة قد تُوجَّه الطلبات إلى جهاز آخر. ومنذ GPT-5.6 تتولى OpenAI التوجيه تلقائيًا، وأصبح prompt_cache_key إعدادًا اختياريًا لتقسيم تقارير التخزين المؤقت حسب العميل بدلًا من أن يكون وسيلة لرفع نسبة الإصابة (في GPT-5.5 وما قبله كان استخدام المفتاح نفسه لتوجيه الطلبات إلى الجهاز نفسه مهمًا).

تحدّد واجهة Claude البرمجية نطاق التخزين المؤقت بمساحة العمل. وداخل المؤسسة الواحدة، لا تتشارك مساحات العمل المختلفة التخزين المؤقت حتى مع موجّهات متطابقة. أما في Bedrock وGoogle Cloud فالنطاق هو المؤسسة. كذلك لا يصبح التخزين المؤقت متاحًا إلا بعد بدء الاستجابة الأولى، فإذا أرسلت دفعة واحدة كثيرًا من الطلبات المتوازية بالبادئة نفسها، تتحول البقية أيضًا إلى عمليات كتابة قبل أن يكتب الطلب الأول التخزين المؤقت.

4. الأسعار ونقطة التعادل: كم قراءة تلزم حتى يصبح التخزين المؤقت مجديًا

لأن الكتابة في التخزين المؤقت أغلى من الإدخال العادي، فإن مدخلًا مخزّنًا يُكتب ولا يُقرأ أبدًا يكلّف أكثر من عدم استخدام التخزين المؤقت إطلاقًا. لنرمز إلى مضاعف الكتابة بـw، ومضاعف القراءة بـr، وعدد القراءات بعد الكتابة بـn. يُستخرج عدد القراءات اللازم للتعادل من المعادلات التالية: التكلفة مع التخزين المؤقت تساوي w + n × r، ودونه تساوي 1 + n (إرسال البادئة نفسها n + 1 مرة كما هي)، ويصبح التخزين مجديًا عندما يكون n أكبر من (w − 1) ÷ (1 − r).

With caching    = w + n × r
Without caching = 1 + n          (sending the same prefix n + 1 times as is)
Pays off when   : n > (w − 1) ÷ (1 − r)

المضاعفات منسوبة إلى سعر إدخال يساوي 1. حُسبت من OpenAI ‏«Prompt caching» و«Pricing» ومن Anthropic ‏«Pricing» (رُوجعت في 3 أكتوبر 2026). المقارنة للبادئة فقط، دون المخرجات والسؤال الخاص بكل طلب.

يتضمن دليل OpenAI الحساب نفسه لنموذج بمضاعف 0.1: الكتابة مرة والقراءة مرة تكلّفان 1.35 ضعف، مقابل ضعفين لمعالجة البادئة مرتين دون تخزين مؤقت. وتذكر صفحة أسعار Anthropic كذلك أن تخزين الدقائق الخمس يصبح مجديًا بعد قراءة واحدة، وتخزين الساعة بعد قراءتين. مهما كانت القراءة رخيصة، لا يمكن أن يصبح تخزين الساعة مجديًا بقراءة واحدة، لأن الكتابة بضعف السعر ثقيلة جدًا.

مقارنة نموذجين بسعر الإدخال نفسه: الفاصل بين الطلبات يقلب النتيجة

بحسب الأسعار الرسمية في 3 أكتوبر 2026، يتقاضى كلٌّ من GPT-6.1 Sol وClaude Sonnet 5.5 مبلغ ‎$2 لكل مليون رمز إدخال، وسعر الكتابة لخمس دقائق واحد لديهما أيضًا: ‎$2.50. الفرق في سعر القراءة (Sol ‏‎$0.10، وSonnet 5.5 ‏‎$0.20) وفي مدة TTL. حسبنا تكلفة البادئة عند إرسال بادئة من 100,000 رمز عشر مرات بفواصل زمنية مختلفة.

الأسعار من OpenAI ‏«Pricing» ‏(Standard، حتى 272K) ومن Anthropic ‏«Pricing» (رُوجعتا في 3 أكتوبر 2026). ‏100,000 رمز = 0.1 (بوحدات من مليون رمز). عند الإصابة يكون الطلب الأول كتابة والتسعة الباقية قراءات؛ وعند الإخفاق تكون العشرة كلها كتابات. قد تخفق OpenAI أيضًا بسبب توجيه الطلبات بين الأجهزة وعوامل مشابهة، لذا فإن صفوف الإصابة قيم في ظروف مواتية.

على سبيل المثال، تكلفة GPT-6.1 Sol كل 3 دقائق هي: 0.1 × $2.50 (كتابة واحدة) + 0.1 × $0.10 × 9 (تسع قراءات) = $0.25 + $0.09 = $0.34. ويُظهر الجدول ثلاثة أمور.

• بفواصل 5 دقائق أو أقل، يكون الفرق بين الاثنين صغيرًا (‎$0.34 مقابل ‎$0.43)، ويتوقف على سعر القراءة وحده.
• بفواصل بين 5 و30 دقيقة، تتفوّق مدة TTL البالغة 30 دقيقة لدى OpenAI. مع مدة 5 دقائق في Claude يصبح كل طلب كتابة بتكلفة ‎$2.50، أي أكثر من عدم استخدام التخزين المؤقت. والتحويل إلى ساعة يخفّضها إلى ‎$0.58.
• عندما يتجاوز الفاصل مدة TTL، يصبح التخزين المؤقت خاسرًا. عند طلب كل ساعتين، يكون عدم التخزين المؤقت بتكلفة ‎$2.00 هو الأرخص. في Claude لا تضع cache_control؛ وفي OpenAI ‏GPT-5.6 وما بعده استخدم وضع الصريح فقط دون نقاط قطع، فتتجنب رسوم الكتابة.

وبوجه خاص، لأن التخزين المؤقت مفعّل افتراضيًا في OpenAI ‏GPT-5.6 وما بعده، فإن البقاء في الوضع الضمني قد يعني دفع سعر الكتابة حتى لمدخلات لن ترسلها مرة أخرى. إذا كان عملك يرسل كثيرًا من المدخلات الطويلة التي تُستخدم مرة واحدة، فراجع cache_write_tokens في usage وقرّر ما إذا كنت ستنتقل إلى وضع الصريح فقط.

كيف يجتمع التخزين المؤقت مع التسعيرات الأخرى

• المعالجة الدفعية (Batch): تتضمن قائمة أسعار OpenAI أيضًا أسعار الإدخال المخزّن والكتابة في التخزين المؤقت لـBatch وFlex (‏GPT-6.1 Sol في Batch: إدخال ‎$1، وقراءة من التخزين المؤقت ‎$0.05، وكتابة فيه ‎$1.25). وتقول Anthropic إن مضاعفات التخزين المؤقت تجتمع مع خصم الدفعات البالغ 50%، لكن لأن طلبات الدفعات تُعالَج بالتوازي ودون ترتيب محدد، فإنها تصف إصابات التخزين المؤقت بأنها «best effort» (بأفضل جهد، دون ضمان).
• المدخلات الطويلة: في OpenAI، عندما تتجاوز المدخلات 272K رمز، تتضاعف أسعار الإدخال والقراءة من التخزين المؤقت والكتابة فيه (وتبقى المضاعفات كما هي). وفي Anthropic، تتقاضى نماذج Claude 4.6 وما بعدها السعر نفسه حتى مليون رمز.
• التسخين المسبق: في الحالتين تُحتسب كتابة التسخين المسبق بسعر الكتابة العادي. ولا يترتب على max_tokens: 0 في Claude أي رسوم مخرجات.

5. لماذا لا يعمل التخزين المؤقت للموجّهات: الأسباب الشائعة

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

مشكلات شائعة مع OpenAI

• لا توجد نقطة قطع مباشرة بعد البادئة المشتركة: يضع الوضع الضمني نقطة القطع في نهاية أحدث رسالة، لذا مع بنية «تعليمات ثابتة + رسالة مستخدم مختلفة كل مرة» يُكتب الجزء المتغيّر أيضًا ويخفق الطلب التالي. ضع نقطة قطع صريحة مباشرة بعد الجزء الثابت.
• الانتقال إلى وضع الصريح فقط في منتصف الطريق: لا يبحث هذا الوضع إلا عن نقاط القطع التي وضعتها، فلا يصيب المدخلات المخزّنة التي كُتبت في الوضع الضمني.
• الإلحاق بالرسالة نفسها: إذا أصبحت رسالة كانت تنتهي بـ«المحتوى أ» تنتهي بـ«المحتوى أ + المحتوى ب»، تقع نقطة القطع السابقة في منتصف رسالة فيحدث إخفاق. أضف المحتوى الجديد في رسالة جديدة.
• تغيير مستوى الاستدلال في منتصف الطريق: في نماذج GPT-6 يمكنك تغيير المستوى دون كسر التخزين المؤقت بترك reasoning.effort في الطلب كما هو وإلحاق configuration_update بعد المدخلات.
• تشغيل الضغط (compaction، أي ضغط السياق): تتغيّر البادئة فتنخفض نسبة الإصابة. ومع ذلك يشير الدليل إلى أن التكلفة الإجمالية قد تنخفض لأن المدخلات تتقلّص، وينصح بمقارنة التكلفة الإجمالية.

مشكلات شائعة مع Claude

• نقطة قطع على كتلة تتغيّر في كل مرة: لا تحدث الكتابة إلا في مواضع نقاط القطع، ولا تبحث القراءة إلا إلى الوراء عن مواضع كتابة سابقة. فإذا كانت نقطة القطع على كتلة تتغيّر في كل مرة، تدفع سعر الكتابة في كل مرة ولا تحصل على إصابة أبدًا. والتخزين المؤقت التلقائي يضع نقطة القطع على الكتلة الأخيرة أيضًا، فيقع في الفخ نفسه. ضع نقطة قطع صريحة على آخر كتلة لا تتغيّر.
• إضافة 20 كتلة أو أكثر في دور واحد: يغطي البحث عن الكتابات السابقة حتى 20 موضعًا إلى الوراء من نقطة القطع. فإذا نمت المحادثة كثيرًا دفعة واحدة، تقع الكتابة السابقة خارج هذه النافذة. احتفظ بنقطة قطع إضافية في موضع أبكر من الموجّه.
• إعادة كتابة موجّه النظام في منتصف الطريق: في النماذج المدعومة يمكنك إضافة تعليمات دون كسر التخزين المؤقت بترك system في المستوى الأعلى دون تغيير وإضافة رسالة بـ"role": "system" داخل messages.
• التبديل بين الوضع السريع (speed: "fast") والوضع القياسي: يُبطل ذلك التخزين المؤقت لموجّه النظام وللمحادثة.

6. كيف تتحقق من إصابات التخزين المؤقت: usage والتشخيص

ابدأ بـusage: معنى input_tokens مختلف

على المنصتين، يبيّن usage في الاستجابة مقدار ما قُرئ من التخزين المؤقت وما كُتب فيه. وما يجب الانتباه إليه هو أن input_tokens يحمل معنيين متعاكسين على المنصتين.

المصادر: OpenAI ‏«Prompt caching»، قسم Monitor cache performance؛ Anthropic ‏«Prompt caching»، قسم Tracking cache performance (رُوجعت في 3 أكتوبر 2026)

إذا قسمت على input_tokens في Claude كأنه إجمالي المدخلات، فستنحرف نسبة الإصابة والتكلفة كلتاهما انحرافًا كبيرًا. وعندما تضع أرقام الشركتين في لوحة متابعة واحدة، وحّد الإجماليات بالمعادلات أعلاه قبل المقارنة. ويوصي دليل OpenAI بحساب «نسبة الإصابة بالرموز» على أنها مجموع الرموز المقروءة من التخزين المؤقت مقسومًا على مجموع رموز الإدخال، مجمّعة حسب المستخدم أو اليوم وما إلى ذلك.

أما التكلفة، فهي في OpenAI: «(الإدخال − القراءة − الكتابة) × السعر + القراءة × السعر × 0.1 + الكتابة × السعر × 1.25»، وفي Claude: «input_tokens × السعر + القراءة × السعر × 0.1 + الكتابة × السعر × 1.25 (و2 لجزء الساعة)» (استبدل مضاعف القراءة بـ0.05 أو قيمة أخرى بحسب النموذج). ولدى OpenAI لوحة «Prompt Caching Dashboard» في صفحة الاستخدام، وتحيل وثائق Rate limits لدى Anthropic إلى صفحة Usage لمعرفة نسبة الإصابة.

ما الذي تتحقق منه بالترتيب عندما تكون القراءة صفرًا

1. هل الكتابة صفر أيضًا؟ في Claude، إذا كانت القيمتان صفرًا فالموجّه أقصر من الحد الأدنى أو أن cache_control مفقود. وفي OpenAI بوضع الصريح فقط، لا تحدث كتابة أيضًا إذا لم تضع أي نقطة قطع.
2. هل تظهر كتابة في كل طلب؟ نقطة القطع في موضع يتغيّر في كل مرة، أو أن شيئًا في البادئة يتغيّر في كل مرة. استخدم التشخيص الموضح أدناه لمعرفة ما تغيّر.
3. كم مضى على الطلب السابق؟ تحقّق مما إذا تجاوز الدقائق الخمس في Claude (بما في ذلك وقت توليد الاستجابة) أو الثلاثين دقيقة في OpenAI.

تشخيص OpenAI: ‏prompt_cache_diagnostics

في Responses API لدى OpenAI، وفي النماذج المدعومة من GPT-5.6 فصاعدًا، يؤدي تمرير معرّف استجابة سابقة في prompt_cache_options.comparison_response_id إلى وضع نتيجة مقارنة ذلك الطلب بالطلب الحالي في prompt_cache_diagnostics. وتذكر الوثائق أن ذلك لا يكلّف شيئًا إضافيًا ولا يُحتسب منفصلًا ضمن حدود المعدل.

// إضافة هدف للمقارنة في الطلب الثاني
{
  "model": "gpt-6.1-sol",
  "input": [ ...same prefix as the first request..., { "role": "user", "content": "السؤال التالي" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(ID of the first response)" }
}

// مثال لما يُعاد عند الإخفاق (مثال الوثائق: أُعيدت تسمية أداة)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

لـtype أربع قيم: cache_hit وcache_miss وcomparison_response_not_found (لا يوجد سجل للمقارنة أو انتهت صلاحيته) وunavailable (لا يمكن الوصول إلى نتيجة). وعند الإخفاق تكون قيمة reason واحدة من هذه التسع.

المصدر: OpenAI ‏«Prompt cache diagnostics»، قسم Fix a cache miss (رُوجع في 3 أكتوبر 2026)

تشخيص Claude: ‏diagnostics

في واجهة Claude البرمجية يجب أن تضمّن الحقل diagnostics في كل طلب، لأن الواجهة لا تحفظ بصمة المقارنة (قيم التجزئة وأعداد الرموز التقديرية) إلا للطلبات التي تتضمنه. في الدور الأول مرّر "previous_message_id": null، ثم مرّر بعد ذلك id الاستجابة السابقة.

// من الدور الثاني فصاعدًا
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(id of the previous response)" },
  "system": "...",
  "messages": [ ... ]
}

إذا كانت قيمة diagnostics في الاستجابة null، فلم يُعثر على اختلاف (أو لم تُجرَ مقارنة)؛ وتعني {"cache_miss_reason": null} أن المقارنة لم تنتهِ بعد؛ وإذا ظهر سبب، فهو يحدد أول موضع افترق فيه الطلبان. الأسباب ستة: model_changed وsystem_changed وtools_changed وmessages_changed وprevious_message_not_found وunavailable. وترافق أسبابَ *_changed قيمةُ cache_missed_input_tokens، وهي تقدير لمقدار ما ضاع.

وتنص وثائق Claude على قراءة التشخيص مع cache_read_input_tokens.

المصدر: Anthropic ‏«Cache diagnostics»، قسم Reading diagnostics alongside usage (رُوجع في 3 أكتوبر 2026)

لميزتي التشخيص كثير من القواسم المشتركة: كلتاهما تعيد أول اختلاف تجده فقط، لذا قارن مرة أخرى بعد إصلاحه. أما الفروق فهي أن تشخيص Claude يعمل في واجهة Claude البرمجية فقط (لا في Amazon Bedrock ولا Google Cloud ولا Claude Platform on AWS ولا Microsoft Foundry)، ولا يقارن إلا بطلبات من مساحة العمل نفسها. ولا تصف وثائق OpenAI أي خطوة لوسم الطلب السابق الذي ستجري المقارنة به. وفي Claude، إذا لم يتضمن الطلب السابق diagnostics هو الآخر، تحصل على previous_message_not_found.

7. أرقام نسبة الإصابة: أمثلة المزوّدين وبيانات الجهات الخارجية

تختلف دلالة أرقام نسبة إصابة التخزين المؤقت المتداولة اختلافًا كبيرًا بحسب من نشرها وفي أي ظروف. وفيما يلي نفصل بينها.

أرقام صادرة عن المزوّدين

• أمثلة في دليل OpenAI: حمل عمل تقييمي لمرة واحدة (باستخدام نموذج لغوي كبير مقيّمًا) مع نقطة قطع صريحة بعد معايير تقييم ثابتة بلغ «نسبة إصابة بالرموز تقارب 70%»، ووكيل يستدعي الأدوات مرارًا بلغ «أكثر من 90%». ويحذّر الدليل من أن هذه أمثلة لنتائج ممكنة وأن السقف يعتمد على حمل العمل.
• تعليقات العملاء في إعلان OpenAI (22 سبتمبر 2026): يقول فريق Manus إنه بعد إعادة التفكير في مواضع نقاط القطع ارتفعت نسبة الإصابة لديه في نماذج OpenAI من «نحو 85% إلى أكثر من 90% باستمرار» في أقل من أسبوع. ويذكر تعليق عن GitHub Copilot أنه خلال الأشهر القليلة الماضية خفّض نسبة المدخلات التي يجب إعادة معالجتها بأكثر من 50% مقارنة بخط الأساس السابق. وكلاهما اقتباس من عملاء نشرته OpenAI في صفحتها، لا قياس مستقل.
• Anthropic: لا تقدّم الوثائق أرقامًا فعلية لنسبة الإصابة. تتضمن صفحة Rate limits مثالًا حسابيًا: «بنسبة إصابة 80%، يعالج حد إدخال قدره مليونا رمز في الدقيقة فعليًا 10 ملايين رمز في الدقيقة»، لكنه حساب على افتراض، لا قياس.

بيانات الجهات الخارجية: ليست حكمًا مباشرًا على الأفضل

جمعت Requesty، وهي خدمة توجّه الطلبات إلى عدة واجهات برمجية للذكاء الاصطناعي، الطلبات التي مرت عبر بوابتها ونشرت نسب إصابة لشهر أبريل 2026 بلغت 77% لـAnthropic مباشرة (77.50% في الجدول) و36% لـOpenAI ‏(36.40%) («Prompt-cache hit rate per provider, April 2026»، المحدَّثة في 9 مايو). للوهلة الأولى يبدو أن Claude يصيب أكثر من ضعف ما يصيبه الآخر، لكن هناك أربعة أسباب تمنع استخدام هذه الأرقام في المقارنة التي يعرضها هذا المقال.

1. البيانات سابقة لتغيير OpenAI: أدخلت OpenAI الاحتفاظ لمدة 30 دقيقة ونقاط القطع الصريحة في 22 سبتمبر، وبيانات أبريل سابقة لذلك.
2. أحمال العمل مختلفة: هذه نتائج تطبيقات مستخدمين مختلفين ترسل موجّهات مختلفة بفواصل مختلفة عبر البوابة، لا الموجّه نفسه مرسلًا إلى الشركتين. وفي Claude لا تُحتسب إلا الطلبات التي أضاف فيها المستخدمون cache_control بأنفسهم.
3. المقام: تذكر الصفحة «cached_tokens ÷ input_tokens»، لكن كما شرحنا في القسم 6، لا يشمل input_tokens في Claude الرموز المخزّنة مؤقتًا. ولا توضح الصفحة كيف حوّلت القيم.
4. الصفحة تناقض نفسها: تضع Claude عبر Google Cloud ‏(Vertex) عند 24% في موضع، وعند 14% في موضع آخر.

بحسب بحثنا في 3 أكتوبر 2026، لم نجد أي قياس من جهة خارجية قارن بين نظامَي التخزين المؤقت في ظروف متماثلة. وفي النهاية، الطريقة الوحيدة لمعرفة ما إذا كان التخزين المؤقت يعمل في تطبيقك هي قياسه في بيانات استخدامك أنت. احسب نسبة الإصابة والتكلفة بالمعادلات الواردة في القسم 6، وإذا كان هناك إخفاق فاستخدم التشخيص لمعرفة السبب.

الخلاصة

يقوم التخزين المؤقت للموجّهات في OpenAI وClaude على الفكرة الأساسية نفسها: إعادة استخدام البادئة المتطابقة واحتساب القراءة بنحو 0.1 ضعف سعر الإدخال. الفرق أن OpenAI (‏GPT-5.6 وما بعده) يفعّله افتراضيًا، ويحتفظ به 30 دقيقة على الأقل، ويحتسب الكتابة بـ1.25 ضعف، بينما Claude لا يخزّن مؤقتًا إلا إذا أضفت cache_control، ويحتفظ بالتخزين 5 دقائق (مع خيار ساعة)، ويحتسب الكتابة بـ1.25 ضعف (ضعفان للساعة).

من حيث السعر، ولأن الكتابة أغلى، فإن التخزين المؤقت الذي لا يُقرأ أبدًا خسارة. يصبح تخزين الدقائق الخمس والثلاثين دقيقة مجديًا بعد قراءة واحدة، وتخزين الساعة في Claude بعد قراءتين. ومع فواصل بين 5 و30 دقيقة بين الطلبات تتفوق مدة الثلاثين دقيقة لدى OpenAI، وفي Claude يمنع اختيار الساعة انقلاب النتيجة. وإذا كانت طلباتك متباعدة أكثر من مدة TTL، فعدم التخزين المؤقت أرخص.

تحقّق من عمل التخزين المؤقت بالنظر إلى كميات القراءة والكتابة في usage. لا يغطي input_tokens في Claude إلا ما يأتي بعد نقطة القطع، فاحسب الإجمالي أولًا ثم نسبة الإصابة. وعند الإخفاق، يخبرك prompt_cache_diagnostics في OpenAI وdiagnostics في Claude بموضع اختلاف الطلب عن الطلب السابق. ولطرق أخرى لخفض التكاليف، راجع «كيف توفّر في تكلفة الذكاء الاصطناعي والرموز».

الأسئلة الشائعة

س. ما مدة TTL للتخزين المؤقت للموجّهات في OpenAI؟

ج. في GPT-5.6 وما بعده: 30 دقيقة على الأقل بعد آخر كتابة أو إعادة استخدام. ولا يقبل الإعداد prompt_cache_options.ttl إلا "30m"، ويقول الدليل إن التخزين المؤقت قد يستمر مدة أطول. وفي GPT-5.5 وما قبله يكون الاختيار عبر prompt_cache_retention: يستمر in_memory نحو 5 إلى 10 دقائق من عدم النشاط (حتى ساعة)، ويستمر 24h حتى 24 ساعة.

س. هل يمكن تمديد مدة TTL للتخزين المؤقت للموجّهات في Claude؟

ج. نعم، يمنحك "cache_control": {"type": "ephemeral", "ttl": "1h"} ساعة واحدة. تكلّف الكتابة ضعف سعر الإدخال، فلا يصبح ذلك مجديًا إلا إذا قُرئ التخزين المؤقت مرتين على الأقل. وإذا واصلت الاستخدام بفواصل أقل من 5 دقائق، يتجدد تخزين الدقائق الخمس مجانًا مع كل قراءة. وكلاهما يُحسب من بداية الطلب، لذا فإن الوقت المستغرق في توليد استجابة طويلة يُحتسب من مدة TTL.

س. هل يغيّر التخزين المؤقت الإجابات؟

ج. لا. تقول وثائق الشركتين إن التخزين المؤقت لا يؤثر في توليد المخرجات. ما يُحفظ هو الحساب الوسيط الناتج عن قراءة المدخلات، لا الإجابة نفسها. وكما هو الحال دون تخزين مؤقت، لا تُنتج المدخلات نفسها الإجابة نفسها دائمًا.

س. هل يمكن مسح التخزين المؤقت يدويًا؟

ج. لا تتيح ذلك أيٌّ من المنصتين. تقول OpenAI إن المدخلات تنتهي صلاحيتها وفق مدة TTL والإعدادات، وتقول Anthropic إنها تُحذف تلقائيًا بعد 5 دقائق على الأقل من عدم الاستخدام (أو ساعة إذا اخترت الساعة). وإذا أردت استبدال محتوى الموجّه، فغيّر البادئة وسيكتب الطلب التالي مدخلًا جديدًا.

المصادر

• وثائق واجهة OpenAI البرمجية: Prompt caching
• وثائق واجهة OpenAI البرمجية: Prompt cache diagnostics
• وثائق واجهة OpenAI البرمجية: Pricing
• OpenAI: Better prompt caching for GPT-6 (22 سبتمبر 2026)
• وثائق Claude Platform: Prompt caching
• وثائق Claude Platform: Cache diagnostics
• وثائق Claude Platform: Pricing
• وثائق Claude Platform: Rate limits
• Requesty: Prompt-cache hit rate per provider, April 2026

رُوجعت كل المصادر في نصها الأصلي في 3 أكتوبر 2026. قد تتغيّر الأسعار ومدد TTL والحدود الدنيا للطول مع إضافة نماذج جديدة، فتأكد منها في صفحة أسعار كل مزوّد قبل الاعتماد عليها. حسابات التكلفة في هذا المقال عمليات حسابية مبنية على الأسعار الرسمية، لا قياسات أجريناها باستدعاء الواجهات البرمجية بأنفسنا.