Prompt Caching: قلّل تكلفة Claude 90% على system prompt المتكرر

إزاي تشغّله — كود Python شغّال

أول call هتلاقي cache_creation_input_tokens = 8000 و cache_read_input_tokens = 0. ثاني call على نفس الـ system خلال 5 دقايق هتلاقي cache_read_input_tokens = 8000 و cache_creation = 0. ده دليلك إن الـ caching فعّال.

الأرقام الفعلية — قبل وبعد

الافتراضات: Claude Sonnet 4.6 بسعر $3 لكل مليون توكن input، system prompt بحجم 8000 توكن، 1000 طلب في الساعة موزّعة بالتساوي خلال النافذة.

• بدون caching: 8000 × 1000 × 3 ÷ 1,000,000 = $24/ساعة على الـ system prompt لوحده.
• مع caching: request واحد write (8000 × $3.75/M = $0.030) + 999 reads (8000 × 999 × $0.30/M = $2.40). الإجمالي: $2.43/ساعة.
• الفرق: توفير 89.9% — يعني $21.57 في الساعة، أو حوالي $517 في اليوم، أو ~$15,500 شهريًا على نفس الـ workload.

الافتراض إن الطلبات متقاربة زمنيًا. لو الفجوات بين الطلبات بتعدي 5 دقايق بشكل متكرّر، الـ cache هيتكسر ويتعمل write جديد كل مرة، وفي الحالة دي الفايدة بتقل بشكل ملحوظ.

الـ trade-offs اللي مش بيقولولكش عليها

• بتكسب: 90% خصم على الجزء المتكرّر من الـ input، وده غالبًا 70 إلى 90% من إجمالي حجم الـ prompt في تطبيقات RAG ومحادثات الدعم.
• بتخسر 25% على الـ write الأولي. لو طلب واحد فقط في الـ 5 دقايق وميتكرّرش، الـ caching بيتكلّف 1.25× بدون ما تحصل على read واحد يستهلك الـ cache.
• بتخسر مرونة في التحديث. أي تغيير في الـ cached block — حتى مسافة واحدة أو فاصلة — بيكسر الـ cache ويفرض write جديد. لو بتولّد system prompts ديناميكيًا، خلّي الجزء الديناميكي خارج الـ cache breakpoint.
• تعقيد الـ debugging: الـ usage object فيه حقول جديدة لازم تتابعها. لو نسيت تطبعها، هتفتكر إنك بتدفع كامل من غير ما تكتشف إن الـ cache مش شغّال أصلاً.

متى لا تستخدم Prompt Caching

• system prompt قصير (أقل من 1024 توكن): الـ API هيتجاهل الـ cache_control بصمت. مفيش فايدة ولا ضرر، لكن لا تتوقع توفير.
• طلبات متفرقة (rate أقل من واحد كل 5 دقايق): هتدفع write زيادة كل مرة بدون قراءات كافية. الـ break-even بيحصل بعد قراءة واحدة فقط في نفس النافذة، فلو مش متأكد من التكرار اعمل قياس قبل التفعيل.
• محتوى ديناميكي بالكامل: لو الـ system بيتغيّر كل request (مثلاً context محسوب per-user ومش بيتكرّر بين مستخدمين)، مفيش جزء ثابت يستحق التخزين أصلًا.
• تجارب A/B على system prompts متعددة: كل variant بيفرض cache write مستقل. خلّي التفعيل بعد ما تثبّت النسخة النهائية.

المصادر

• Anthropic — Prompt Caching Documentation
• Anthropic — API Pricing
• Finout — Anthropic API Pricing 2026 Guide
• MindStudio — How Prompt Caching Affects Claude Limits

الخطوة التالية

افتح أكبر system prompt شغّال عندك في الإنتاج دلوقتي. عدّ توكناته بـ client.messages.count_tokens أو tokenizer مباشر. لو الناتج فوق 1024 توكن، ضيف cache_control: { type: "ephemeral" } على آخر content block ثابت في الـ system. شغّل 5 طلبات متتالية على API الإنتاج، واطبع usage.cache_read_input_tokens بعد كل طلب. لو الرقم طلع فوق صفر من ثاني طلب، أنت كسبت 90% من تكلفة الـ system prompt — والباقي هندسة طبيعية فوق ده.