Michael Johnsonכשמפתחים משתמשים ב-Copilot דרך כלי צד שלישי, הנתונים הסטנדרטיים לפי סביבת פיתוח משולבת (IDE) עשויים שלא להראות מהיכן הגיעו הבקשות. ב-23 באוקטובר 2026 הוסיפה GitHub את השדה totals_by_client ל-Copilot usage metrics API. השדה מקבץ את השימוש במודלים לפי לקוח, ובהם OpenCode, Claude Code, Codex ו-Zed. עבור מנהלים, זו דרך לראות חלק מהפעילות מחוץ לעורך ולדון בצורה מבוססת יותר בכללים הפנימיים לשימוש בבינה מלאכותית.
מה כולל הפילוח החדש
כל פריט ב-totals_by_client מציין את הלקוח, את מספר הקריאות המוצלחות למודל, את מספר המפגשים ואת נפח אסימוני ה-prompt והפלט, לצד הממוצע שלהם לקריאה. השדה המקונן totals_by_model מפלח את המדדים האלה לפי מודל ומציג את אופן הבחירה: המשתמש בחר את המודל ישירות, בחירה אוטומטית הופעלה או שהמוצר הקצה את המודל.
השדה נוסף לדוחות יומיים ולדוחות של 28 ימים עבור נתוני ארגון Enterprise, ארגון ומשתמשים ברמות האלה. בדוח המצטבר ל-28 ימים, הפילוח לפי לקוח מופיע עבור כל יום. זהו שינוי תוספתי: השדות הקודמים נשמרים, וכשאין נתונים המערך נותר ריק. GitHub פירטה את השינויים בהכרזה על הפילוח החדש של מדדי השימוש.
על אילו שאלות הנתונים יכולים לענות
צוותים יכולים להשוות את נפח הבקשות והאסימונים שהגיעו דרך כלים שונים, ולהחליט באילו אינטגרציות לתמוך או אילו לכלול בכללים הארגוניים. לדוגמה, עלייה בשיעור של OpenCode בדוח עשויה לרמוז שמפתחים משתמשים ב-Copilot כספק מודלים מחוץ לסביבת הפיתוח המשולבת. השוואת לקוחות ומודלים מסייעת לבדוק אילו מודלים יוצרים בפועל את עיקר העומס.
לניתוח תקציבי כדאי להתחיל באסימונים ובמספר הקריאות, ולאחר מכן להשוות אותם לתנאי התמחור התקפים. request_count סופר קריאות למודל, לא הנחיות משתמש: הנחיה אחת יכולה להוביל לכמה קריאות. לכן השדה מתאים לניתוח העומס על שירות המודלים, אך לא לספירה ישירה של האינטראקציות של המפתחים.
איך לשלב את המדד בתהליך העבודה
- בדקו את ההרשאות. יש להפעיל את המדיניות Copilot usage metrics. בעלי הרשאות מתאימות של Enterprise או ארגון, מנהלי חיוב ותפקידים בעלי הרשאת צפייה במדדים הרלוונטיים יכולים לקבל את הדוחות.
- השוו תקופות זהות. השתמשו בדוח היומי כדי לבדוק שינויים לאחר הפעלת כלי, ובדוח ל-28 ימים כדי לזהות דפוסי פעילות יציבים. בכל דוח הפרידו בין קריאות, אסימונים ומפגשים: אלה מדדים שונים של עומס.
- קבעו ספים לבדיקה. לדוגמה, סמנו לקוח ששיעור האסימונים או הקריאות שלו גדל במידה ניכרת לעומת התקופה הקודמת שלו. קבעו את הסף בהתאם לדרישות שלכם ולעומס הבסיסי; GitHub אינה קובעת סף אחיד.
- השוו את הדוח להגדרות הגישה. אפשר להשתמש בפילוח החדש כבסיס לדיון בתמיכה בכלים ובניהולם. הדוחות מתארים שימוש שנרשם, אך אינם מחליפים בדיקת הרשאות או מיפוי של האינטגרציות.
תיעוד Copilot usage metrics API הרשמי מפרט את הדוחות, את דרישות ההרשאה ואת הפילוחים הזמינים. לפני אוטומציה, בדקו בו את המבנה העדכני של הדוח הנדרש והשתמשו בהרשאות המתאימות.
מה המשמעות של תווית הלקוח
GitHub מזהה את הלקוח לפי integration ID שהכלי מעביר עם הבקשה. החברה מבהירה שהקיבוץ מספק זיהוי משוער: הערך מסייע לצבירת התעבורה, אך כשלעצמו אינו מאמת את זהות המשתמש או את האותנטיות של היישום. לקוחות לא מוכרים משויכים לקבוצה other, וערכים שאי אפשר לנרמל עשויים להופיע כ-unknown.
יש גם מקרים מיוחדים: קריאות של Copilot code review ושל Copilot cloud agent מקבלות את מצב הבחירה product_selected, משום שהמוצר הוא שבוחר במודל; בסקירת קוד, המודל עשוי להיות מוצג כ-unknown. חשוב להביא זאת בחשבון כשמשווים פילוחים לפי מודל בין כלים.
בשורה התחתונה, totals_by_client מצמצם את הפער במעקב אחר קריאות Copilot דרך שרתים וכלים חיצוניים, ומספק למנהלים נתונים חדשים לניתוח עומסים ולקבלת החלטות על תמיכה. כדי להפוך את הפילוח לתמונה אמינה של השימוש, השוו אותו להרשאות ולמקורות פנימיים אחרים, והתייחסו לשמות הלקוחות כאל קטגוריות תעבורה — לא כהוכחה לזהות.