Auto أو TokenLab Verified أو Official: اختيار فئة التسليم (Delivery Tier)

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

نقاط رئيسية

• يمكن خدمة الطلب من خلال مسار official أو مسار verified. يتم تسجيل الاختيار لكل طلب كـ resolvedDeliveryTier (إما verified أو official، وتكون القيمة null إذا كان السجل يسبق هذا التحديث).
• auto هي السياسة الافتراضية، وليست نوع مسار ثالث. فهي تحتفظ بالمسارات المتاحة وتقدر الحد الأقصى للتكلفة التي قد يتحملها الطلب قبل الإرسال.
• تعد وراثة السياسة على مستوى مساحة العمل (Workspace) ومفتاح API هي الإعداد الطبيعي. في قراءة الإنتاج بتاريخ 2026-09-11، كان لدى 5,536 مساحة عمل سياسة Auto صريحة، و217 ورثت الإعداد الافتراضي للنظام، وجميع مفاتيح API البالغ عددها 4,134 ورثت السياسة من مساحة العمل الخاصة بها. أظهرت قراءة لاحقة في ذلك الأسبوع أن 219 مفتاحاً ورثت السياسة. ظل العدد الصريح ثابتاً لأن مساحات العمل التي ورثت السياسة كانت حسابات تم إنشاؤها حديثاً ولم تقم بتعيين سياسة بعد. هذه الأرقام مأخوذة من قراءة إطلاق TokenLab 2.0 المسجلة في ملاحظات بروفة الإصدار الداخلي، والتي تمت ملاحظتها في 2026-09-11؛ تعامل معها كقراءة إنتاج داخلية، وليس كمعيار قياسي عام.
• تتطلب أهلية التسعير Official تطابقاً دقيقاً مع مسار Official. يظل تسليم Verified متاحاً عندما لا يتطابق أي مسار Official.
• يمكنك تجاوز اختيار التسليم لكل طلب باستخدام الترويسة X-TokenLab-Delivery-Policy. يغطي الإعداد الافتراضي لمساحة العمل الحالات الشائعة.

ما هي خيارات مستوى التسليم الثلاثة في الواقع

تعلن القنوات عن مستويات التسليم كـ VERIFIED و OFFICIAL. لا يمكن ربط سوى القنوات التي لديها مستوى تسليم عام نشط بربط نموذج المؤسسة. يمكن لمساحة العمل ربط نموذج منطقي بقناة معينة. يتم رفض هذا الربط ما لم تكن القناة نشطة، وغير محذوفة، وتعلن عن مستوى تسليم عام نشط. يجب أيضاً تمكين مسار للنموذج على تلك القناة.

يعني Official أن المسار يتم تقديمه بواسطة مسار المزود الرسمي، بينما يعني Verified مساراً تم التحقق منه بواسطة TokenLab. Auto هي السياسة التي تسمح للموجه بالاختيار من بين المسارات المتاحة؛ عندما نفحص طلباً بعد الإرسال، يخبرنا resolvedDeliveryTier ما إذا كان verified أو official هو من قام بخدمته. يكون هذا الحقل null عندما يسبق السجل هذه الميزة.

ما الذي يتغير عند اختيار مستوى التسليم

يؤدي اختيار مستوى معين إلى تغيير أهلية السعر، وسجلات الطلبات، والتقدير الذي تراه قبل الإرسال. يمكن تعديل التسعير لكل مستوى تسليم من خلال قواعد تعديل سعر التسليم على مستوى المؤسسة، ويتم تطبيع هذا التعديل والتحقق منه قبل تطبيقه. بعد الإطلاق، تستمر خيارات Verified أو Official الصريحة في التطبيق، بينما يتم تعيين الطلبات التي تسبق السياسة افتراضياً على Auto.

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

الخيار	ما الذي يتم تحسينه	متى تختار هذا الخيار	ما يمكنك التحقق منه لاحقاً
Auto	المسارات المتاحة وتقدير الحد الأقصى للتكلفة	تريد أن تختار السياسة الافتراضية من بين المسارات المتاحة	resolvedDeliveryTier يظهر المسار الذي خدم الطلب
TokenLab Verified	الوصول إلى مسارات TokenLab-verified عندما لا يكون Official متاحاً أو غير مطلوب	تحتاج إلى مسار تم التحقق منه، أو لا يتطابق أي مسار Official	resolvedDeliveryTier يظهر verified
Official	تطابق مسار Official الدقيق لأهلية التسعير الرسمية	تحتاج إلى أهلية التسعير الرسمية	resolvedDeliveryTier يظهر official

كيف تقوم الفرق عادةً بتهيئة سياسة مستوى التسليم

أرقام القراءة في هذا القسم مأخوذة من قراءة إطلاق TokenLab 2.0 المسجلة في ملاحظات بروفة الإصدار الداخلي، والتي تمت ملاحظتها في 2026-09-11؛ تعامل معها كقراءة إنتاج داخلية، وليس كمعيار قياسي عام.

الإعداد الافتراضي هو الوراثة، وليس إجراءً لكل طلب. في قراءة الإنتاج بتاريخ 2026-09-11، رأينا 5,536 مساحة عمل بسياسة Auto صريحة، بينما ورثت 217 مساحة أخرى الإعداد الافتراضي للنظام. ورثت جميع مفاتيح API البالغ عددها 4,134 السياسة من مساحة العمل الخاصة بها، لذا لم تكن العملاء القدامى بحاجة إلى ترويسة جديدة. هذا النمط منطقي لأن سياسة مساحة العمل تغطي الحالة الشائعة، ويظل تجاوز الطلب الفردي هو الاستثناء.

أظهرت قراءة لاحقة في نفس الأسبوع 5,536 سياسة صريحة و219 موروثة، بينما ظل العدد الصريح ثابتاً وتحرك العدد الموروث من 217 إلى 219. كانت مساحات العمل الموروثة تلك حسابات تم إنشاؤها حديثاً لم تقم بتعيين سياسة بعد، لذا تتحرك هذه الأعداد مع إنشاء الحسابات. لم يكن تعيين السياسة عملية ترحيل أبداً، ولم يتم تشغيل أي ملء خلفي مجمع لسياسة مساحة العمل أو المفتاح عند الإطلاق، ولم تكن المفاتيح الموروثة بحاجة إلى أي تغيير في العميل.

لا تزال قواعد الربط سارية عندما تربط مساحة العمل نموذجاً منطقياً بقناة معينة. يتم رفض الربط ما لم تكن القناة نشطة، وغير محذوفة، وتعلن عن مستوى تسليم عام نشط. يجب أيضاً وجود مسار ممكّن للنموذج على تلك القناة. لا يمكن ربط قناة بربط نموذج مؤسسة إلا بينما يكون إعلان السجل (Registry declaration) الخاص بها ACTIVE وسجلها الخاص ACTIVE مع عدم وجود طابع زمني للحذف، لذا لا يمكن تثبيت قناة متوقفة أو متقاعدة.

تثبيت نموذج منطقي بقناة معينة هو الطريقة التي تعبر بها مساحة العمل عن "Official دائماً" لهذا النموذج دون المساس بالطلبات الفردية. الطلبات التي تسبق سياسة التسليم يتم تعيينها افتراضياً على Auto. لم يكن هناك حاجة إلى تغيير في العميل، ولم يتم إجراء أي ملء خلفي مجمع لسياسة مساحة العمل أو المفتاح عند الإطلاق. للحصول على سياق على مستوى النموذج، قم بإقران ذلك بـ دليل مركز بيانات النموذج.

كيفية التحقق من مستوى التسليم الذي خدم الطلب

عند انتهاء الطلب، اقرأ resolvedDeliveryTier في سجل الطلب؛ القيمة هي verified أو official، والقيمة null تعني أن السجل يسبق هذا الحقل. يحمل الطلب أيضاً requestedDeliveryPolicy، الذي يسجل ما طلبه المتصل وهو قابل للقيم الفارغة عندما يتم تطبيق الإعداد الافتراضي لمساحة العمل.

لتجاوز المستوى لطلب واحد، أضف الترويسة X-TokenLab-Delivery-Policy؛ القيم المقبولة هي auto و verified و official. إليك الترويسة بمفردها:

# أضف هذه الترويسة إلى طلب Claude Sonnet 5
X-TokenLab-Delivery-Policy: verified

على سبيل المثال، يستهدف استدعاء cURL هذا Claude Sonnet 5 ويطلب official:

curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'

بعد الاستدعاء، يحمل سجل الطلب الخاص بذلك الاستدعاء:

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

يتضمن سجل الطلب أيضاً حقول الاستخدام، ويوضح دليل وحدة تحكم الطلبات مكان وجود ذلك السجل وأسماء الحقول الحالية للاستخدام.

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

عندما تختار Auto مستوى تسليم لم تتوقعه

عندما تختار Auto مستوى لم تتوقعه، اقرأ resolvedDeliveryTier في الطلب وقارنه بالقنوات التي ربطتها مؤسستك. ثم قم إما بربط النموذج بالقناة التي تريدها أو تجاوز المستوى لذلك الطلب. هذا يبقي السياسة الافتراضية بسيطة مع منحك طريقة ملموسة لتصحيح مسار مفاجئ.

القيود

الأرقام هنا هي قراءة في لحظة زمنية من 2026-09-11، وسوف تتغير بمرور الوقت. تعتمد توفر مستويات التسليم على المسارات النشطة لنموذجك ومؤسستك. يمكن رفض ربط مساحة العمل إذا كانت القناة غير نشطة، أو محذوفة، أو تفتقر إلى مستوى تسليم عام نشط، أو ليس لديها مسار ممكّن للنموذج. يعتمد تعديل السعر لكل مستوى تسليم على قواعد مؤسستك الخاصة. لا يمكننا تقديم مقارنة عالمية لأن البيانات المصدرية لا توفر واحدة. يتم حل قرار التسليم بعد اختيار المسار، لذا فإن المستوى الذي تحصل عليه يعتمد على المسارات الممكّنة لمؤسستك في تلك اللحظة.

الأسئلة الشائعة

ما الذي تختاره Auto فعلياً؟

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

لماذا قد يكلف مسار Verified أكثر من مسار Official؟

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

هل يجب علي تعيين مستوى تسليم في كل طلب؟

لا. تعد وراثة السياسة على مستوى مساحة العمل ومفتاح API هي الإعداد الطبيعي. في قراءة الإنتاج بتاريخ 2026-09-11، كان لدى 5,536 مساحة عمل سياسة Auto صريحة، و217 ورثت الإعداد الافتراضي للنظام، وجميع مفاتيح API البالغ عددها 4,134 ورثت السياسة من مساحة العمل الخاصة بها. تحرك العدد الموروث إلى 219 في وقت لاحق من ذلك الأسبوع مع إنشاء حسابات جديدة. هذه الأرقام مأخوذة من قراءة إطلاق TokenLab 2.0 المسجلة في ملاحظات بروفة الإصدار الداخلي، والتي تمت ملاحظتها في 2026-09-11؛ تعامل معها كقراءة إنتاج داخلية، وليس كمعيار قياسي عام. يمكنك تجاوز اختيار التسليم لكل طلب، لكن الإعداد الافتراضي لمساحة العمل يغطي الحالات الشائعة.

كيف أعرف أي مستوى خدم طلباً مكتملاً؟

اقرأ resolvedDeliveryTier في سجل الطلب. القيمة هي verified أو official، وتكون null عندما يسبق السجل هذا الحقل. يظهر requestedDeliveryPolicy ما طلبه المتصل، وهو قابل للقيم الفارغة عندما يتم تطبيق الإعداد الافتراضي لمساحة العمل. توضح وحدة تحكم الطلبات ودليل وحدة تحكم الطلبات مكان وجود ذلك السجل.

ماذا يحدث إذا طلبت مستوى ليس له مسار ممكّن؟

تجيب البوابة بـ delivery_tier_unavailable. ولا تعود تلقائياً إلى مستوى آخر. اقرأ سجل الطلب، ثم قم إما بتمكين مسار مطابق أو تغيير السياسة المطلوبة.

قم بإنشاء مفتاح API وقارن المستوى الذي تحصل عليه بالمستوى الذي توقعته؛ يوضح دليل وحدة تحكم الطلبات مكان وجود ذلك السجل.