Claude Code يعيد محاولة معالجة أخطاء تجاوز معدل الطلبات (Rate-Limit) لمفاتيح API، وليس لخطط Max
يمكن لجلسة Claude Code الخاصة بك أن تتوقف فوراً بسبب خطأ واحد.
إذا كنت تستخدم مفتاح API، يقوم النظام بإعادة محاولة الطلب. أما إذا كنت تستخدم خطة Max، فستنتهي الجلسة.
لقد قمت بعمل هندسة عكسية (decompiled) لملف Claude Code الثنائي (الإصدار 2.1.179) لمعرفة السبب. المنطق بسيط؛ حيث يتحقق الكود من طريقة الدفع الخاصة بك قبل اتخاذ قرار بإعادة محاولة معالجة خطأ 429.
يعمل المنطق على النحو التالي:
- مفاتيح API: يقوم النظام بإعادة محاولة معالجة الخطأ.
- حسابات Enterprise: يقوم النظام بإعادة محاولة معالجة الخطأ.
- خطط Pro و Max: لا يقوم النظام بإعادة المحاولة، مما يؤدي إلى توقف عملك بسبب الخطأ.
يحدث هذا لأن العميل (client) يحدد نوع اشتراكك؛ حيث يتعرف على رمز OAuth الخاص بك ويتجاوز مسار إعادة المحاولة.
هناك سبب لهذا التصميم؛ فخطأ 429 في الاشتراكات يعني غالباً أنك وصلت إلى حد الاستخدام للساعات القليلة القادمة. وإعادة محاولة تجاوز حد الاستخدام أمر غير مجدٍ، بل ويؤدي إلى هدر الموارد.
ولكن هناك مشكلة في هذا النهج.
تأتي قيود Anthropic بنوعين:
- نوافذ استخدام طويلة (بالساعات).
- قيود قصيرة لكل دقيقة (بالثواني).
يعامل الكود كلا النوعين بنفس الطريقة، فهو لا يفرق بين حد يستمر لساعات وحد يستمر لثانيتين فقط.
عندما تصطدم بحد قصير لكل دقيقة في خطة Max، فإنك تفقد عملية التشغيل بأكملها. بينما لو كنت تستخدم مفتاح API، لانتظر النظام ثانيتين ثم نجح في الطلب.
وهذا يعني أن موثوقية عملك تعتمد على فئة الفوترة الخاصة بك.
إذا كنت تبني تدفقات عمل الوكلاء (agentic workflows) بناءً على اشتراك، فأنت تضع ثقتك في نظام يستسلم بسهولة. فما هو مجرد انقطاع عابر لمدة ثانيتين قد يتحول بالنسبة لك إلى مهمة فاشلة، بينما يمثل للآخرين مجرد توقف بسيط.
يمكنك اختبار ذلك بنفسك؛ راقب سجلاتك (logs) بحثاً عن الترويسة (header) المسماة anthropic-ratelimit-unified-status.
- إذا كنت تستخدم مفتاحاً بنظام الدفع حسب الاستخدام (metered key)، فسترى عمليات إعادة المحاولة.
- إذا كنت تستخدم Max، فسترى الجلسة تتوقف.
الموثوقية هي جزء مما تشتريه. وفي هذه الحالة، تتغير القواعد بصمت بناءً على طريقة الدفع الخاصة بك.
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi