خطأ request_too_large من Anthropic: المعنى والسبب والحل

قد يتسع الطلب داخل نافذة السياق، ثم يتجاوز لكن حد حجم البيانات المرسلة. فالخطأ 413 يقيس جسم الطلب بعد ترميزه، بما فيه المرفقات.

بقلم فريق benchr · · تم التحقق من توثيق أخطاء API لدى Anthropic في 12 يونيو 2026

AnthropicHTTP 413الخطورة: متوسطةحجم الطلب

بايتات، لا توكنز

يختلف حد التوكنات عن حد حجم الطلب. يظهر تجاوز نافذة السياق بعد أن تقبل الخدمة الطلب وتفحص محتواه، أما الخطأ 413 فيظهر عند مقارنة حجم جسم الطلب بالحد المسموح لكل نقطة وصول. في واجهة Messages المباشرة يبلغ الحد 32 ميغابايت، وقد ترفض Cloudflare الطلب قبل وصوله إلى خوادم Anthropic.

قد يتسع النص داخل نافذة السياق ولكن يتجاوز الطلب حد الميغابايت، لأن المقياسين مختلفان. ويظهر ذلك غالباً مع المرفقات؛ فترميز الملفات بصيغة base64 يزيد حجمها بنحو الثلث، وقد تتجاوز مجموعة صور مع سجل محادثة طويل الحد رغم أن عدد التوكنات مقبول.

الحد حسب نقطة الوصول

سقوف حجم الطلب لدى Anthropic بحسب النقطة، وفق توثيق أخطاء API
النقطةأقصى حجم للطلب
Messages API32 ميغابايت
Token Counting API32 ميغابايت
Batch API256 ميغابايت
Files API500 ميغابايت

تستخدم واجهة عدّ التوكنات حد الحجم نفسه الخاص بـMessages، ولذلك لا يمكن إرسال طلب ضخم إليها لمجرد قياسه. احسب حجم جسم الطلب في تطبيقك قبل الإرسال.

محتوى الرد

{
  "type": "error",
  "error": {
    "type": "request_too_large",
    "message": "Request exceeds the maximum allowed number of bytes."
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

المظروف نفسه لكل خطأ من Anthropic: فرّع بناءً على حقل type، وفي كود الـ SDK التقط صنف الاستثناء المعنون للحالة بدل مطابقة نص الرسالة. تحمل الردود ترويسة request-id مسبوقة بـ req_ تكشفها الـ SDKs؛ اقتبسها إن تحوّل الإخفاق إلى محادثة دعم.

قلّص أو انقل

يبدأ الحل بقياس لن يفعله الـ SDK نيابةً عنك، فمكتبات العميل ترسل ما تسلّمها إياه. وتحسم دالة واحدة في غلافك الأمر:

# Python: قِس الجسم قبل أن تفعل الحافة
import json

CAP_MB = 32  # سقف Messages API، بالبايتات لا التوكنز

def body_size_mb(payload: dict) -> float:
    return len(json.dumps(payload).encode("utf-8")) / 1_048_576

size = body_size_mb(payload)
if size >= CAP_MB:
    # المتهم المعتاد: صور base64 مضمّنة داخل كتل المحتوى
    reroute(payload)  # الأصول إلى Files API، والدفعات إلى Batch

حين يعود الرقم كبيراً، يكون المتهم غالباً وسائط مضمّنة، وخريطة النقل تتبع الجدول أعلاه. الأصول الكبيرة مكانها Files API بسقفه البالغ 500 ميغابايت، تُرفع مرة وتُشار إليها من الرسالة بدل لصقها فيها. والمهام بالدفعات مكانها Batch API، الذي يأخذ 256 ميغابايت لكل طلب ويعمل بخصم 50% على تسعير Claude القياسي. توجّه وثائق Anthropic أيضاً العمل الطويل، خاصةً ما يتجاوز 10 دقائق، نحو البث أو Batch API بدل استدعاء متزامن واحد ضخم.

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

أسئلة شائعة

لماذا وصلني خطأ 413 وتوكنزي تتّسع في النافذة؟

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

هل يحميني الـ SDK من الطلبات الضخمة؟

لا. مكتبات العميل ترسل ما تعطيها، والرفض يقع عند الحافة. قِس len(json.dumps(payload).encode()) قبل الإرسال وأعد توجيه كل ما يقترب من 32 ميغابايت.

أين مكان الملفات الكبيرة؟

في Files API، الذي يقبل حتى 500 ميغابايت. ارفع الملف مرة واحدة، وأشر إليه من رسائلك، فتبقى حمولة Messages صغيرة مهما ثقُلت المادة المصدر.

سجل التغييرات

  • — نُشر. تم التحقق من سقوف البايتات لكل نقطة، وحدّ Cloudflare، وشكل الرد، وفق توثيق أخطاء API لدى Anthropic.

المراجع

  • Anthropic API errors — platform.claude.com/docs/en/api/errors (تم التحقق في 12 يونيو 2026)
  • benchr api-errors.json، السجل المُهيكَل لهذا الخطأ