تخفض واجهة برمجة تطبيقات prompt-caching API الجديدة الخاصة بـ Claude Opus 5 فواتير الرموز (tokens) لتطبيقات الدردشة بشكل كبير، وذلك من خلال السماح للنموذج بتخطي إعادة قراءة النصوص غير المتغيرة. تدفع الطلبات الأولى رسومًا إضافية بسيطة؛ ولكن كل طلب لاحق يكلف تقريبًا عُشر السعر الأساسي، مما يحول المصروف المتكرر إلى رسوم تُدفع لمرة واحدة.
لماذا يدفع المطورون مرتين مقابل الكلمات نفسها
تعيد معظم واجهات المحادثة بناء المطالبة (prompt) بالكامل في كل دورة: حيث تنتقل مطالبة النظام المكونة من 8,000 رمز، وملفات PDF المرفقة، وسجل الحوار الكامل معًا إلى النموذج في كل مرة يطرح فيها المستخدم سؤالاً متابعاً. يعيد النموذج معالجة كل رمز حتى وإن كان الجزء الأكبر من ذلك النص لا يتغير أبدًا. وبالأسعار الحالية، يمكن لهذا التكرار أن يهيمن على تكلفة البوت النشط.
كيف يغير التخزين المؤقت (cache) الحسابات
تنشئ واجهة برمجة التطبيقات إدخال تخزين مؤقت لكل "كتلة" (block) من الرموز حتى نقطة توقف محددة. عندما يحتوي الطلب التالي على نفس الكتلة في البداية، تقوم الخدمة بقراءتها من التخزين المؤقت بدلاً من تحويلها إلى رموز مرة أخرى. ويعكس تقسيم الأسعار العمل الذي تم توفيره:
- كتابة في التخزين المؤقت – مدة بقاء (TTL) لمدة 5 دقائق: 1.25 × السعر الأساسي
- كتابة في التخزين المؤقت – مدة بقاء (TTL) لمدة ساعة واحدة: 2 × السعر الأساسي
- قراءة من التخزين المؤقت (hit): 0.1 × السعر الأساسي
من الناحية العملية، تكلف الاستدعاء الأول لكتلة جديدة أكثر قليلاً من الطلب العادي. أما كل استدعاء لاحق يصيب التخزين المؤقت (cache hit) فيكون أرخص بنسبة 90%، لذا ينخفض صافي الإنفاق بشكل حاد مع تعمق المحادثة.
"القاعدة الذهبية" لهيكلة المطالبات (prompts)
تعتمد فعالية التخزين المؤقت على مكان وضع المحتوى الثابت مقابل المحتوى الديناميكي. ضع كل ما يظل ثابتًا في المقدمة، وانقل الأجزاء المتغيرة باستمرار إلى النهاية. الترتيب الموثوق يكون كالتالي:
- Tools – تعريفات أي وظائف خارجية قد يستدعيها النموذج.
- System instructions – السلوك رفيع المستوى الذي تريد من النموذج اتباعه.
- Documents – السياق الطويل مثل ملفات PDF، أو قواعد المعرفة، أو مقتطفات السياسات.
- User questions – الاستعلام المباشر الذي يتغير في كل دورة.
إذا قمت بتعديل أي رمز قبل نقطة التوقف، فسيتم إبطال إدخال التخزين المؤقت ويجب على النموذج إعادة معالجة كل ما يليه.
حدود خفية يجب عليك احترامها
- الحد الأدنى لحجم الكتلة – يقوم Opus 5 فقط بتخزين الكتل التي تحتوي على 512 رمزًا على الأقل. أي شيء أصغر من ذلك سيفشل في دخول التخزين المؤقت تمامًا.
- خطأ الطابع الزمني – إدراج طابع زمني متغير داخل كتلة مخزنة يضمن عدم حدوث "إصابة" (miss)، لأن نص الكتلة لن يتطابق تمامًا أبدًا.
- مراجعة لآخر 20 كتلة – تفحص الخدمة آخر 20 كتلة فقط بحثًا عن تطابق. الجلسات الطويلة التي تقفز للأمام بسرعة قد تتجاوز نافذة التخزين المؤقت.
- الطلبات المتوازية – إرسال عدة طلبات متطابقة في اللحظة نفسها سيؤدي جميعها إلى عدم العثور على التخزين المؤقت (miss)، لأن التخزين المؤقت يتم ملؤه فقط بعد انتهاء الطلب الأول. قم بـ "تسخين" التخزين المؤقت باستدعاء واحد، ثم أصدر البقية.
رؤية التوفير في استجابة الـ API الخاصة بك
تعرض كل استجابة ثلاثة عدادات للرموز:
cache_read_input_tokens– الرموز التي جاءت من إصابة التخزين المؤقت (cache hit).cache_creation_input_tokens– الرموز المكتوبة في التخزين المؤقت في هذا الطلب.input_tokens– الرموز الجديدة التي لم يتم تخزينها مؤقتًا.
اجمع الأرقام الثلاثة معًا للحصول على إجمالي الرموز التي نظر فيها النموذج في تلك الدورة. إذا كان كلا حقلي التخزين المؤقت صفرًا، فقد فشل الطلب في العثور على التخزين المؤقت؛ تحقق من حجم الكتلة ومكان وضع نقطة التوقف.
الخلاصة: من خلال وضع السياق غير القابل للتغيير في المقدمة والسماح لواجهة برمجة تطبيقات prompt-caching API الخاصة بـ Claude Opus 5 بالقيام بالعمل الشاق، فإنك تحول مصروف الرموز المتكرر إلى رسوم تُدفع لمرة واحدة. والنتيجة هي خفض هائل في التكلفة لأي chatbot يشير بشكل متكرر إلى نفس مطالبة النظام أو مجموعة المستندات — بشرط أن تحترم الحد الأدنى للرموز، وتتجنب العلامات القابلة للتغيير داخل الكتل المخزنة، وتحافظ على المحتوى المؤهل للتخزين المؤقت ضمن نطاق الـ 20 كتلة.