عندما يخبرك Claude Code بأن حصتك قد نفدت، فالانتظار حتى إعادة التعيين أو شراء خطة أكبر ليسا الخيارين الوحيدين.
إذا كنت تستخدم إلى جانب Claude Code أدوات مثل Codex وOpenCode، فقد تحدث أمور أخرى: كل وكيل (Agent) يحتاج إلى إعداد نموذجه الخاص، وخط متعطل قد يقاطع مهمة جارية، وفي نهاية الشهر لا تستطيع تحديد عدد الرموز (Token) التي استهلكتها كل مهمة فعليًا.
تجيب هذه المقالة على ثلاثة أسئلة: كيف تعرف ما إذا كنت تواجه نفادًا للحصة أو تحديدًا للمعدل (rate limiting) أو خطأ في الإعداد؛ وكيف توحّد الوصول إلى النماذج وتُعدّ خطوطًا احتياطية عبر وسيط API؛ وكيف تتحقق من الاستخدام وتقدّر التكلفة لكل جلسة.
الخلاصة: مع حساب رسمي واحد واستخدام خفيف، تكون القناة الرسمية أبسط عادة. أما وسيط API فيستحق عندما تحتاج إلى وصول موحّد إلى عدة نماذج، أو فوترة مركزية، أو تبديلًا احتياطيًا بين خطوط upstream مصرّح لك باستخدامها.
أولًا: تأكد قبل كل شيء — نفاد حصة، أم تحديد معدل، أم خطأ إعداد؟
الانتقال فورًا إلى خدمة وسيطة عند أول رسالة “فشل الطلب” يعقّد الأمور غالبًا. فالأخطاء المختلفة تتطلب معالجة مختلفة.
| ما تراه | السبب المحتمل | ما تفعله أولًا |
|---|---|---|
| رسالة صريحة بـ quota أو usage limit أو credit exhausted | نفاد حصة الخطة أو نافذة الاستخدام أو رصيد الحساب | تحقّق من وقت إعادة التعيين أو الرصيد، واستخدم خطًا احتياطيًا مصرّحًا به |
| HTTP 429 | قد يكون تحديد معدل أو نفاد حصة | اقرأ نص الخطأ كاملًا وترويسة Retry-After، ولا تحكم من رمز الحالة وحده |
| HTTP 401 أو 403 | مفتاح غير صالح أو صلاحيات ناقصة أو حالة تسجيل دخول معطوبة | تحقّق من المفتاح وصلاحيات الحساب وعنوان الواجهة |
| انتهاء مهلة أو فشل اتصال | مشكلة في الشبكة أو DNS أو الوكيل (proxy) أو انقطاع في upstream | اختبر الاتصال وحالة الخدمة قبل تبديل الخطوط |
| نموذج غير موجود أو معامل غير مدعوم | عدم تطابق اسم النموذج أو البروتوكول أو المعاملات | راجع قائمة النماذج ووثائق الواجهة |
بعض قيود المعدل تُستعاد خلال دقائق، وتكرار تبديل الخطوط قد يضيف مزيدًا من الطلبات الفاشلة. ما يهم فعلًا هو أن تعرف كم خطًا متاحًا لديك، ومتى تبدّل، وما إذا كانت المهمة الحالية ستستمر بعد التبديل.
ثانيًا: ما يستطيع وسيط API فعله وما لا يستطيعه
وسيط API (خدمة توجيه) يقف بين الوكلاء ومزوّدي النماذج. يرسل الوكلاء الطلبات إلى الوسيط، ثم يوجّهها الوسيط إلى نماذج upstream المُعدّة.
عادةً ما يبرع في أربع مهام:
- الوصول الموحّد: جميع الوكلاء تتشارك Base URL واحدًا وقائمة نماذج واحدة وسجل استخدام واحدًا.
- التبديل الاحتياطي (Failover): عند تحقق شروط إعادة المحاولة، تنتقل الطلبات من الخط الحالي إلى خط احتياطي.
- توجيه النماذج: اختيار النماذج وفق ترتيب الأولوية أو حالة الحصة أو نوع المهمة.
- تتبّع التكاليف: عرض الرموز (Token) وقراءات التخزين المؤقت وعدد الطلبات والمصروف في مكان واحد.
لا يمكنه استحداث حصة رسمية من لا شيء، ولن يمنح نموذجًا لا يدعمها أصلًا قدرات معالجة الصور أو استدعاء الأدوات أو السياق الطويل. كما لا يمكن استكمال بث انقطع بعد بدء الإخراج بسلاسة على نموذج آخر.
تجميع حسابات اشتراكات استهلاكية أو مشاركة ملفات تعريف الارتباط (cookie) أو استخدام مفاتيح مجهولة المصدر ينطوي على مخاطر أمنية للحساب وعلى مخاطر تتعلق بشروط مزودي الخدمة upstream. قبل اختيار خدمة، تأكد من أن النماذج ومصدر الوصول إلى API مشروعة وأنك تستخدم خطوط upstream مصرّحًا بها.
ثالثًا: إدارة عدة وكلاء دون تكرار الإعداد
Claude Code وCodex وOpenCode لا تتشارك تنسيق إعداد موحدًا. أضف بضعة نماذج، وستجد عناوين Base URL ومفاتيح API وأسماء النماذج متناثرة عبر ملفات مختلفة.
بعد ربط كل شيء بوسيط، تُركّز مصدر النماذج وتمنح كل وكيل نقطة الوصول الخاصة به. الخطوات المعتادة:
- أنشئ مفتاح API الخاص بك في الوسيط واضبط حدًا للاستخدام.
- تحقّق من البروتوكولات وأسماء النماذج وعنوان Base URL الذي تدعمه الخدمة فعلًا.
- املأ إعداد الوكيل واحتفظ بنسخة من الإعداد الأصلي للتراجع.
- أرسل طلب اختبار واحدًا بسيطًا قبل تشغيل المهام الفعلية.
- تأكد في صفحة الاستخدام من أن الطلب سُجّل بشكل صحيح.
بالنسبة للعملاء الذين يدعمون متغيرات بيئة Anthropic، يبدو الإعداد عادةً كالتالي:
export ANTHROPIC_BASE_URL="عنوان الواجهة الذي توفّره خدمتك فعلًا"
export ANTHROPIC_AUTH_TOKEN="مفتاح API الذي أنشأته بنفسك"تختلف أسماء المتغيرات والبروتوكولات وأساليب المصادقة بين العملاء، لذا اتبع الوثائق الحالية للعميل والوسيط معًا. لا تخلط بين عنوان بوابة محلية وعنوان خدمة إنتاج، ولا تلصق مفاتيح حقيقية أبدًا في لقطات الشاشة أو السجلات أو المقالات العامة.
لتجربة سريعة، عيّن المتغيرات في جلسة طرفية (Terminal) مستقلة بدلًا من كتابتها في ملفات إعداد دائمة، ولا تجعلها دائمة إلا بعد التأكد من أن كل شيء يعمل.
رابعًا: التبديل الاحتياطي ليس مجرد “تكديس مزيد من الحسابات”
التبديل الاحتياطي الحقيقي يجيب عن أسئلة محددة:
- ما الأخطاء التي تُعاد محاولتها، وما الأخطاء التي يجب أن تفشل فورًا؟
- عندما يتعطل الخط الحالي، بأي ترتيب تُختار الخطوط الاحتياطية؟
- هل تحافظ الجلسة على نموذجها وخطها، تجنبًا لعدم توافق السياق أو تنسيق الاستدلال؟
- ماذا يحدث عندما ينقطع البث بعد إرسال محتوى إلى العميل بالفعل؟
- هل يمكن أن تُنتج إعادة المحاولة طلبات مكررة ورسومًا إضافية؟
استراتيجيات التوجيه الشائعة:
- أساسي/احتياطي: تفضيل الخط الأساسي، والتبديل عند تحقق شروط الانتقال.
- التوزيع الدوري (Round-robin): توزيع الطلبات بالتناوب بين الخطوط المتاحة.
- الأقل استخدامًا: تفضيل الخط الأدنى استخدامًا في الوقت الحالي.
- الجدولة وفق نافذة الحصة: تنظيم الخطوط بناءً على الحصة المتبقية وأوقات إعادة التعيين.
- نيّة المهمة: إرسال البرمجة المعقدة إلى نماذج أقوى والتعديلات الصغيرة إلى نماذج أسرع وأرخص.
في المهام الطويلة، كثرة الخطوط لا تعني ثباتًا أعلى. الأهم أن تكون معالجة الأخطاء صريحة، وأن بروتوكولك واستدعاءات الأدوات مدعومة، وأن يكون هناك سجل طلبات قابل للتتبع.
خامسًا: كيف تحسب تكلفة كل مهمة
يجب أن يفرّق تتبّع التكاليف على الأقل بين رموز الإدخال ورموز الإخراج وقراءة التخزين المؤقت والكتابة إليه ورموز الاستدلال، وأن يوضّح مصدر الأسعار ووقت جمع البيانات.
لنفترض أن مهمة ما تستهلك 1 مليون رمز إدخال و100 ألف رمز إخراج، وبسعر إدخال X لكل مليون رمز وسعر إخراج Y لكل مليون رمز؛ فبتجاهل التخزين المؤقت والرسوم الأخرى تكون الصيغة التقديرية:
cost = (100 ÷ 100) × X + (10 ÷ 100) × Yعند مراجعة رصيد أو فاتورة حقيقية، تأكد أيضًا من:
- ما إذا كانت أسعار وحدة الإدخال والإخراج مختلفة؛
- ما إذا كانت قراءة التخزين المؤقت والكتابة إليه تُحتسبان بشكل منفصل؛
- ما إذا كانت رموز الاستدلال تُحتسب ضمن الإخراج؛
- كيف تُحتسب الطلبات الفاشلة وإعادة المحاولة التلقائية؛
- ما إذا كانت هناك رسوم خدمة أو فروق أسعار صرف أو معاملات مضاعِفة للنماذج؛
- ما إذا كانت الصفحة تعرض الخصم الفعلي أم تقديرًا بالأسعار المعلنة.
خطط الاشتراك والدفع حسب الاستخدام عبر API ليسا النظام المحاسبي نفسه. “تكلفة الجلسة” التي يعرضها الوسيط ليست بالضرورة النقد المغادر لحسابك البنكي مقابل تلك المهمة. القدرة على تصدير السجلات ومراجعتها سطرًا بسطر أنفع من رقم رصيد واحد.
سادسًا: سبعة أمور تحقق منها قبل اختيار خدمة وسيطة
1. توافق حقيقي للنماذج والبروتوكولات. لا تكتفِ بأسماء النماذج: تأكد من أن البث واستدعاء الأدوات ومعالجة الصور ومعاملات الاستدلال وطول السياق تلبي احتياجات مهامك.
2. أسعار يمكن حسابها فعلًا. جدول الأسعار الكامل يشمل الإدخال والإخراج والتخزين المؤقت والمعاملات المضاعِفة ورسوم الخدمة وقواعد الاسترداد، لا مجرد “خصومات تصل إلى نسبة معينة”.
3. معالجة أعطال شفافة. اعرف أي الأخطاء تُعاد محاولتها، وأين حدود التبديل، وهل توجد صفحة حالة مع سجل صيانة تاريخي.
4. كيف تُحفظ الطلبات والسجلات. تحقّق مما يُخزَّن — الرسائل والاستجابات وعناوين IP والمفاتيح وسجلات الطلبات — ولمدة كم، ومن يستطيع الوصول إليه.
5. هل يمكن تقييد المفاتيح وإلغاؤها. فضّل الخدمات التي توفر مفاتيح مستقلة وحدودًا للحصة وصلاحيات نماذج لكل مفتاح وإمكانية إلغاء في أي وقت.
6. هل يمكن التحقق من الاستخدام. الأفضل أن تتمكن من عرض السجلات حسب النموذج والمفتاح والجلسة والطلب، مع إمكانية التصدير.
7. هل تجد من تخاطبه عند حدوث مشكلة. شروط الخدمة والكيان المشغّل وقنوات الدعم وإشعارات الصيانة وإجراءات الاسترداد يجب أن تكون سهلة الوصول.
هذه المعلومات أهم من “الأرخص على الإنترنت” و”حظر مستحيل” و”استقرار مطلق”. الوعود التي لا يمكنك التحقق منها لا ينبغي أن تكون أساس القرار.
سابعًا: متى لا تحتاج إلى خدمة وسيطة أصلًا
إذا كنت تستخدم وكيلًا واحدًا وحسابًا رسميًا واحدًا، ولديك حصة وافرة، ولا تحتاج إلى استدعاءات عبر عدة نماذج، فالاتصال المباشر عبر القناة الرسمية يقلّل الحلقات الوسيطة.
إذا كانت تصادفك قيود معدل قصيرة ومتقطعة فقط، فقد يكفي التحقق من وقت إعادة التعيين وحالة الخدمة.
قيمة وسيط API هي خفض الكلفة الإدارية لتعدد النماذج والأدوات والخطوط. وهل يستحق الاستخدام يعتمد في النهاية على حجم استدعاءاتك ومتطلبات الاستقرار ودرجة حساسية بياناتك، وعلى قدرة المزوّد على توضيح أسعاره وسجلات تشغيله.
قبل الالتزام، يُنصح بالاختبار أولًا برصيد صغير ومشروع غير حساس: أرسل طلبًا بسيطًا، وراجع فاتورة واحدة، وحاكِ انقطاع الخط الأساسي مرة واحدة. فإذا اتضحت الأمور الثلاثة، انتقل به إلى العمل الرسمي.