حدود المعدل

الحد

النطاق	الحد
لكل مفتاح API	60 طلبًا في الدقيقة

يُطبَّق الحد لكل مفتاح، لا لكل مساحة عمل، لذا يحصل كل مفتاح ضمن مساحة العمل نفسها على حصته الخاصة من 60 طلبًا في الدقيقة بدلاً من مشاركة حصة واحدة. وهو حد لعدد الطلبات، لا لعدد الرموز: فالطلب الواحد الذي يولّد استجابة طويلة جدًا يُحسب مثل الطلب الذي يولّد استجابة قصيرة جدًا، ولا فرق بين البث وعدمه في كيفية احتساب الطلب.

هذا الحد موجود بشكل أساسي كإجراء وقائي ضد الحلقات الجامحة، كحلقة إعادة محاولة بلا تراجع، أو خلل يطلق طلبًا مع كل ضغطة مفتاح، لا كسقف ذي معنى للاستخدام المشروع. حركة التطبيق العادية، حتى استخدام دردشة نشط إلى حد ما، تظل دون هذا الحد بمسافة كبيرة.

تجاوز الحد

الطلب الذي يتجاوز الحد يحصل على 429 فورًا، دون وضعه في قائمة انتظار أو تأخيره، بنفس غلاف الخطأ المستخدم لأي خطأ آخر:

HTTP/1.1 429 Too Many Requests

{"error": {"message": "Rate limit exceeded. Please slow down and retry.", "type": "rate_limit_error"}}

تُعاد النافذة الزمنية على أساس متجدد، لذا فإن الاستجابة الصحيحة لخطأ 429 هي توقف قصير قبل إعادة المحاولة، لا التبديل إلى مفتاح مختلف أو افتراض أن شيئًا ما معطّل. خطأ 429 واحد في منتصف اندفاع نشاط أمر طبيعي ومتوقع؛ أما تكرار 429 عبر اندفاعات منفصلة كثيرة فهو مؤشر على أن نمط الطلبات نفسه يحتاج إلى استراتيجية تراجع، وهو ما يُشرَح أدناه.

التراجع الصحيح

إعادة محاولة خطأ 429 فورًا، في حلقة ضيقة، تجعل الوضع أسوأ لا أفضل: فهي تُبقي معدل الطلبات عند نفس المستوى الذي تجاوز الحد، لذا تفشل كل إعادة محاولة بنفس الطريقة. تأخير قصير، ويُفضَّل أن يتزايد، بين المحاولات (بضع مئات من الملي ثانية، يتضاعف مع كل فشل متتالٍ، حتى سقف معقول) يحل تقريبًا كل خطأ 429 خلال محاولة أو محاولتين دون التأثير بشكل ملموس على زمن استجابة ظاهر للمستخدم في طلب عادي.

# Python: minimal retry with exponential backoff
import time

for attempt in range(4):
    try:
        response = client.chat.completions.create(model="tai-4.1", messages=messages)
        break
    except Exception as e:
        if attempt == 3:
            raise
        time.sleep(0.5 * (2 ** attempt))

حزم OpenAI SDK الرسمية تطبّق بالفعل سلوك إعادة المحاولة مع التراجع لهذا النوع تحديدًا من الأخطاء العابرة بشكل افتراضي؛ إذا كنت تستخدم إحداها، فمن المرجح أن هذا مُعالَج بالفعل نيابة عنك دون أي كود إضافي، ولن ترى استثناءً مرفوعًا إلا بعد استنفاد حصة إعادة المحاولة الخاصة بها.

إذا كانت 60 في الدقيقة منخفضة فعليًا

بالنسبة لمعظم التطبيقات، حجم الطلبات محدود بطبيعته بمدى سرعة قدرة إنسان أو حلقة وكيل على توليد الطلبات فعليًا، ونادرًا ما تكون 60 في الدقيقة قيدًا حقيقيًا. إذا كانت حالة استخدام مشروعة تصطدم بالحد باستمرار، فأول ما يستحق التحقق منه هو ما إذا كان يمكن تجميع الطلبات أو دمجها، بإرسال طلبات أقل وأكبر بدلاً من طلبات صغيرة كثيرة لنفس المهمة الأساسية، قبل افتراض أن الحد نفسه يحتاج إلى تغيير.