Michael Johnsonإذا استخدم المطوّر Copilot عبر أداة خارجية، فقد لا تُظهر الإحصاءات المعتادة الخاصة ببيئة التطوير المتكاملة مصدر الطلبات. في 23 أكتوبر 2026، أضافت GitHub الحقل totals_by_client إلى Copilot usage metrics API، وهو يجمع استخدام النماذج بحسب العملاء، بما في ذلك OpenCode وClaude Code وCodex وZed. ويتيح ذلك للمسؤولين الاطلاع على جانب من النشاط خارج المحرر، ومناقشة القواعد الداخلية لاستخدام الذكاء الاصطناعي على نحو أدق.
ما الذي يتضمنه التقسيم الجديد
يتضمن كل عنصر في totals_by_client اسم العميل، وعدد استدعاءات النماذج الناجحة، وعدد الجلسات، وحجم رموز الإدخال والإخراج ومتوسط عددها لكل استدعاء. ويقسّم الحقل المتداخل totals_by_model هذه المؤشرات بحسب النموذج، ويعرض نمط الاختيار: هل اختار المستخدم النموذج مباشرة، أم جرى اختياره تلقائيًا، أم عيّنه المنتج.
أُضيف الحقل إلى تقارير يوم واحد و28 يومًا على مستوى المؤسسة والمنظمة، وكذلك إلى التقارير المخصصة للمستخدمين ضمن هذين المستويين. وفي التقرير التجميعي ذي الـ28 يومًا، يظهر التفصيل حسب العميل لكل يوم. والتغيير إضافي؛ إذ تبقى الحقول السابقة كما هي، بينما تظل المصفوفة فارغة عند غياب البيانات. وقد شرحت GitHub التفاصيل في إعلان إضافة تقسيم الاستخدام الجديد.
ما الأسئلة التي تجيب عنها البيانات
يمكن للفريق مقارنة حجم الطلبات والرموز الواردة عبر الأدوات المختلفة، واتخاذ قرار بشأن عمليات التكامل التي ينبغي دعمها أو إدراجها ضمن قواعد الشركة. فعلى سبيل المثال، قد تشير زيادة حصة OpenCode في التقرير إلى أن المطوّرين يستخدمون Copilot مزوّدًا للنماذج خارج بيئة التطوير المتكاملة. كما تساعد مقارنة العملاء والنماذج في التحقق من النماذج التي تُشكّل فعليًا معظم الحمل.
لتحليل الميزانية، من المفيد البدء بعدد الرموز والاستدعاءات، ثم مقارنتها بشروط الفوترة المعمول بها. يحصي request_count استدعاءات النماذج، لا مطالبات المستخدمين؛ فقد تؤدي مطالبة واحدة إلى عدة استدعاءات. لذا يصلح هذا الحقل لتحليل الحمل على خدمة النماذج، لكنه لا يصلح لاحتساب تفاعلات المطوّرين مباشرة.
كيفية دمج المقياس في سير العمل
- تحقق من إمكانية الوصول. يجب تفعيل سياسة مقاييس استخدام Copilot. ويمكن لمالكي المؤسسة أو المنظمة المخوّلين، ومديري الفوترة، والأدوار التي تملك إذن عرض المقاييس المعنية، الحصول على التقارير.
- قارن فترات متماثلة. استخدم تقرير اليوم الواحد للتحقق من التغييرات بعد تفعيل أداة، وتقرير الـ28 يومًا لرصد التوزيع المستقر للنشاط. وافصل بين الاستدعاءات والرموز والجلسات في كل تقرير، فهي مقاييس مختلفة للحمل.
- حدّد عتبات للمراجعة. على سبيل المثال، ضع علامة على العميل الذي ترتفع حصته من الرموز أو الاستدعاءات بوضوح مقارنة بفترته السابقة. اختر العتبة بما يناسب متطلباتك والحمل الأساسي؛ إذ لا تحدد GitHub عتبة موحدة.
- طابق التقرير مع إعدادات الوصول. يمكن استخدام التفاصيل الجديدة مدخلًا لمناقشة دعم الأدوات وإدارتها. لكن التقارير تصف الاستخدام المسجّل، ولا تحل محل التحقق من الأذونات أو جرد عمليات التكامل.
تشرح الوثائق الرسمية لواجهة Copilot usage metrics API التقارير ومتطلبات الأذونات والتقسيمات المتاحة. تحقّق من المخطط الحالي للتقرير المطلوب قبل أتمتة العمل، واستخدم أذونات الوصول المناسبة.
ما دلالة تسمية العميل
تحدد GitHub العميل استنادًا إلى معرّف التكامل الذي ترسله الأداة مع الطلب. وتصف الشركة هذا التجميع صراحةً بأنه تحديد تقريبي: فالقيمة تساعد على تجميع حركة المرور، لكنها لا تثبت بمفردها هوية المستخدم أو أصالة التطبيق. وتُدرج العملاء غير المعروفين ضمن المجموعة other، وقد تظهر القيم التي يتعذر توحيدها على هيئة unknown.
وهناك حالات خاصة أيضًا: تحصل استدعاءات Copilot code review وCopilot cloud agent على نمط الاختيار product_selected لأن المنتج هو من يختار النموذج؛ وفي مراجعة الشيفرة، قد يظهر النموذج على أنه unknown. وينبغي مراعاة ذلك عند مقارنة تقسيمات النماذج بين الأدوات.
الخلاصة عملية: يسد totals_by_client فجوة في تتبع استدعاءات Copilot على الخادم من الأدوات الخارجية، ويمنح المسؤولين بيانات جديدة لتحليل الحمل واتخاذ قرارات الدعم. ولتحويل هذا التفصيل إلى صورة موثوقة للاستخدام، قارنه بالأذونات والمصادر الداخلية الأخرى، وتعامل مع أسماء العملاء باعتبارها فئات لحركة المرور، لا دليلًا قاطعًا على الهوية.