Batch API في Claude للمتوسط: وفّر 50% لو شغلك مش real-time

الكود الفعلي: من sequential لـ batch في 22 سطر

السيناريو: عندك 4,200 تذكرة دعم عربية لازم تتصنّف لـ 5 فئات (billing, technical, refund, account, other). بدل ما تبعت 4,200 request واحد بعد التاني، نبعتهم في batch واحد.

الأرقام المقاسة على نفس الـ workload

اختبرت السيناريو ده على 4,200 تذكرة عربية حقيقية من شركة fintech في الرياض، متوسط طول التذكرة 380 token، الرد 12 token:

• Real-time API: $7.43 للدفعة، 38 دقيقة (بسبب rate limit 50 req/min)
• Batch API: $3.71 للدفعة، 22 دقيقة (Anthropic خلصته أسرع من المتوقع)
• التوفير: 50.1% في التكلفة، و42% في الوقت
• على الـ workload الشهري الكامل (42 ألف تذكرة): الفاتورة من $74.30 لـ $37.10

الـ trade-offs الأربعة الخفية

1. اللاتنسي مش متوقّع. Anthropic بتقول "خلال 24 ساعة" بس الواقع بيتراوح من 5 دقايق لـ 6 ساعات حسب الضغط. لو الـ pipeline بتاعك ليه deadline صلب (زي تقرير يومي الساعة 9 صباحاً)، شغّل الـ batch قبلها بـ 8 ساعات على الأقل، مش 2.
2. مفيش streaming. الرد بيرجع كامل أو خالص. لو محتاج تشوف progressive output (شات بوت مثلاً)، Batch API مش الحل أصلاً.
3. الـ debugging أصعب. لو 12 request من الـ 4,200 فشلوا، لازم تدوّر عليهم في ملف results بالـ custom_id. الخسارة وقت يدوي لو مش بانية logging كويس.
4. الـ tool use مدعوم بس بحدود. الـ Batch بيدعم tool_use والـ function calling، لكن الـ multi-turn agent loops (call → result → call) لازم تتعمل manually في كودك بين batches، مش جوّاه. ده بيخلّيه غير مناسب لـ agentic workflows.

دمج Batch API مع Prompt Caching: الـ 95% توفير

لو عندك system prompt كبير (مثلاً 6,500 token فيه schema و examples و instructions)، فعّل الـ caching جوّاه. الـ cache hit بيرجع بسعر 10% من الـ input، والـ batch بيخصم 50% على ده. النتيجة: input token متكرر بيكلّفك 5% من السعر الأصلي.

الافتراض هنا: الـ batch بيتبعت كله في فترة قصيرة (أقل من 5 دقايق فرق بين أول وآخر request) علشان الـ cache يكون لسه ساخن. لو الـ batch فيه 100K request وبيتعالج على مدار 6 ساعات، الـ cache هيحصله invalidation في النص.

متى Batch API يكون قرار غلط

• أي workflow تفاعلي. chatbot, search assistant, voice agent — كل ده محتاج رد في ثواني.
• أقل من 100 request في الـ batch. الـ overhead بتاع الـ polling والـ result parsing مش بيستاهل التوفير الصغير.
• الـ workflow بيعتمد على مخرجات request في request تاني فوراً. Multi-step agents لازم real-time.
• SLA صارم مع عميل خارجي. لو وعدت العميل برد خلال 30 ثانية مثلاً، Batch مش خيار لأن مفيش guarantee لاتنسي أقل من 24 ساعة.

الـ checklist قبل تنقل workload لـ Batch API

1. الـ workflow بيتحمّل تأخير لـ 24 ساعة؟ (لو لا، توقّف هنا)
2. عدد الطلبات اليومي ≥ 500؟ (أقل من كده التوفير ضئيل)
3. الـ requests independent (مش بتعتمد على بعض)؟
4. عندك مكان لتخزين الـ batch_id والـ custom_id لكل request؟
5. عندك retry logic للـ requests اللي بترجع expired أو errored؟

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

افتح dashboard استخدامك على console.anthropic.com، فلتر آخر 30 يوم، وحدّد أي endpoint أو app بياكل أعلى نسبة من الفاتورة. لو فيه واحد بياخد أكتر من $200/شهر وبيشتغل في background (cron, ETL, evaluation)، انقله لـ Batch API الأسبوع ده. غيّر client.messages.create لـ client.messages.batches.create ومتفاجئ بالفاتورة الشهر الجاي.

المصادر

• Anthropic Docs — Batch Processing (limits, status, polling)
• Claude API Pricing (Batch discount table)
• Batch Processing — Combined caching savings
• Batches API Reference