Prompt Caching في Claude للمحترف: وفّر 90% من تكلفة الـ API و 6x من زمن الاستجابة

الكود الكامل

التكلفة الفعلية للـ request التاني: 30000 × 0.1 + 28 = 3028 توكن effective بدل 30028. توفير 90% بالضبط على الـ input.

الأرقام الحقيقية: قياسات من الإنتاج

قياسات حقيقية من تطبيق دعم فني عربي على Claude Sonnet 4.6 خلال أسبوع كامل، حجم العمل 18,000 طلب يومي، system prompt = 28K توكن (تعليمات + 12 مثال few-shot + scheme المنتجات):

• Cache hit rate: 87% (الـ 13% الباقية أوقات بعد سكون > 5 دقائق صباحاً).
• التكلفة الأسبوعية قبل: $1,512.
• التكلفة الأسبوعية بعد: $187. خفض 87.6%.
• Time-to-first-token قبل (P50): 2.1 ثانية.
• Time-to-first-token بعد (P50): 0.32 ثانية. تحسّن 6.5x.
• P95 latency قبل: 4.8 ثانية. بعد: 0.91 ثانية.

الأسعار الرسمية على Sonnet 4.6 (مايو 2026):

• Input عادي: $3 / MTok.
• Cache write (5-min TTL): $3.75 / MTok (مضاعف 1.25x).
• Cache write (1-hour TTL): $6 / MTok (مضاعف 2x).
• Cache read: $0.30 / MTok (مضاعف 0.1x).

4 Trade-offs حقيقية لا يقولها أحد

1. Cache write أغلى من الـ input العادي بـ 25%. أول request بيبني الـ cache بيكلف 1.25x. لو الـ prompt بيتغير كل request ولا تكرر فيه، أنت بتدفع زيادة بدون فايدة. القاعدة: تحتاج 3 hits على نفس الـ cache على الأقل علشان توفر فعلاً (break-even عند ~2.5).

2. ترتيب الـ blocks مهم للغاية. Anthropic بتطابق الـ cache من البداية (prefix matching). لو حطيت متغير في النص الثابت — حتى تعديل بسيط زي timestamp في أول الـ system — كل اللي بعده بيفقد الـ cache. ضع المتغيرات دائماً في آخر الـ messages، لا في الـ system.

3. حد أدنى للـ cache. 1024 توكن على Sonnet 4.6 و Opus، 2048 على Haiku 4.5. أي prompt أصغر، الـ cache_control بيتجاهل بصمت وبتدفع عادي بدون أي تنبيه.

4. TTL محدود = hit rate حساس للسكون. الافتراضي 5 دقايق فقط. لو طلبات تطبيقك متفرقة (مثلاً مرة كل 10 دقايق متوسط)، hit rate بينزل قرب الصفر. الحل: extended cache بـ 1 ساعة، لكن مقابل 2x سعر cache write — حسبة بسيطة قبل ما تفعّله.

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

التقنية دي بتفشل أو ما تنفعش في الحالات دي:

• Prompt قصير (< 1024 توكن). الـ cache مش هيتفعّل أصلاً.
• Workload نادر التكرار — batch processing لمرة واحدة في الشهر، أو سكربت بيشتغل كل 6 ساعات.
• System prompt بيتغير في كل request (مثلاً بتحقن timestamp أو user-specific data في أوله). انقل المتغيرات للـ messages.
• A/B testing على prompts كتير مختلفة بالتوازي، ولا واحد منهم بيوصل لـ 3 hits خلال 5 دقايق.
• التطبيق يستخدم Streaming + توكنز قليلة جداً في الـ output. الـ TTFT تحسّن مش هيبان للمستخدم لأنه أصلاً بيشوف أول كلمة قبل ما يعرف فيه delay.

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

افتح أكبر endpoint عندك بيستهلك Claude الآن. اطبع الـ system array في 5 requests متتالية وقارن — الجزء اللي ما اتغيرش هو cache candidate. حطّ "cache_control": {"type": "ephemeral"} على آخر block منه. شغّله 100 request متتالية في خلال دقيقتين، اقرأ response.usage.cache_read_input_tokens. لو الرقم > 0 من الـ request الثاني، أنت كسبت. ابعتلي رقم hit rate الفعلي بعد أول 7 أيام إنتاج.

المصادر

• Anthropic Docs — Prompt Caching
• Anthropic News — Prompt Caching Launch (2024)
• Anthropic — Pricing (Sonnet 4.6 / Opus / Haiku)
• Anthropic — Models specifications
• Anthropic API Reference — Messages endpoint