Michael Johnsonהחל מ־3 בנובמבר 2026, מנהלי ארגונים וחברות יכולים לראות בנפרד בדוחות GitHub Copilot שימוש במפתחות משלהם ובמודלים ארגוניים. העדכון של Copilot usage metrics API מסייע להבחין בין בקשות למודלים שמתארחים ב־GitHub לבין שימוש ב־BYOK — הבאת מפתח משלכם — או במודל שהוגדר על ידי הארגון.
עבור חברות, מדובר בשינוי מעשי באופן המעקב: אפשר להפריד בין הוצאות לספק חיצוני ולהפעלה מקומית לבין שימוש במודלים ש־GitHub מפעילה. מנהלים ומנהלי מערכת מקבלים תמונה שימושית יותר לפיקוח על דרכי השימוש ב־AI בצוותים. GitHub מציינת שהשדות החדשים מפרידים את BYOK מנתוני הסיכום הקיימים, בלי לשנות את המונים עצמם.
אילו תרחישים ה־API מציג בנפרד
GitHub מבחינה בין שני מקרים של BYOK. ב־BYOK מקומי, מפתחים מגדירים מפתח משלהם או מודל מקומי ב־Copilot CLI או באפליקציית GitHub Copilot; הבקשה נשלחת ישירות לספק או לשרת המקומי. עבור בקשות כאלה נוספו שדה משתמש used_local_byok, נתוני צבירה totals_by_local_byok ומונים של משתמשים פעילים המשתמשים ב־BYOK מקומי.
GitHub מונה בין המודלים והכלים המקומיים את Ollama, Foundry Local, LM Studio ו־llama-server. שדות הפירוט החדשים של BYOK מקומי חלים על Copilot CLI ועל אפליקציית Copilot: הם מפרטים הפעלות, בקשות, הנחיות ואסימונים לפי סוג ה־BYOK וממשק השימוש, אם הספק מעביר את הנתונים המתאימים. שימוש ב־BYOK מקומי אינו מפורט לפי שם המודל, ולכן הדוח מציג את עצם הפעילות ואת היקפה, אך לא את המודל המקומי המסוים.
התרחיש השני הוא מודל מותאם אישית לארגון, שמנהל מערכת מגדיר בהגדרות הארגון או החברה, והבקשות אליו נשלחות דרך GitHub לספק. עבורו הוסיפה GitHub את השדה הבוליאני is_custom_enterprise_model לרשומות המודלים בתוך totals_by_client. מכיוון שהבקשות נצפות בצד השרת, השדה חל על לקוחות שונים, לרבות סביבות פיתוח משולבות (IDE).
מה ישתנה בעבודה עם הדוחות
בעבר, שימוש ב־BYOK עלול היה להתערבב במדדים של מודלים המתארחים ב־Copilot, במיוחד כשהיו למודלים שמות דומים. השדות החדשים מאפשרים להפריד בין הקטגוריות בעת בדיקת נהלים פנימיים וניתוח השימוש. GitHub מציינת שהנתונים זמינים בדוחות לתקופות של יום אחד ו־28 ימים, ברמת המשתמש ובנתוני צבירה של הארגון או החברה.
כדאי למנהלי מערכת להתחיל בשאלה שעליה הדוח אמור לענות: מי משתמש במפתח משלו, איזה חלק מהבקשות מגיע למודלים מקומיים, וכיצד הדבר משפיע על אומדן העלויות. לאחר מכן אפשר להשוות בין השדות החדשים למדדים הקיימים ולנהלים הפנימיים בנושא BYOK. כך מתקבלת תשתית ממוקדת יותר לדיון בבחירת מודלים ובתשלום, בהשוואה למונה כללי של פעילות Copilot.
הגישה למדדים תלויה בתפקיד: ה־API מיועד לבעלי חברות, למנהלי חיוב של חברות, לבעלי ארגונים ולמשתמשים בעלי הרשאת View Copilot Metrics. בנוסף, יש להפעיל את מדיניות השימוש במדדי Copilot. הנתונים משקפים פעילות שנרשמה, ולא את איכות התשובות או את התאמת המודל למשימה מסוימת.
מדוע לשני המדדים החדשים יש רמות דיוק שונות
ל־BYOK מקומי יש מגבלת מדידה ברורה: GitHub מחשבת את השדות שלו על סמך טלמטריה מצד הלקוח. אם הטלמטריה מושבתת, מספר הבקשות הללו יהיה נמוך מהמספר בפועל; חלק מהספקים המקומיים גם אינם מדווחים על מספר האסימונים. לכן הנתונים מועילים לזיהוי השימוש ולהערכת היקפו, אך אינם מלאים לצורך התאמה פיננסית מדויקת.
מודלים מותאמים אישית לארגונים נמדדים בצד השרת, ולפי GitHub אינם מושפעים ממגבלת הטלמטריה הזאת. אותו מודל עשוי להופיע בשתי שורות נפרדות אם נעשה בו שימוש הן כמודל מתארח של Copilot והן כמודל מותאם אישית לארגון. ההפרדה מונעת איחוד של ערוצים שונים רק משום ששמותיהם זהים.
יש גם היבט הקשור לזמן: GitHub אינה מוסיפה את השדה is_custom_enterprise_model לדוחות עבור ימים שקדמו להפצת העדכון. אין להניח שאפשר להשוות אוטומטית נתונים היסטוריים לקטגוריות החדשות; לצורך ניתוח מגמות, סמנו את מועד המעבר והשוו תקופות תוך התחשבות בשינוי במבנה הנתונים.
העדכון מסייע לארגונים לסווג בצורה מדויקת יותר את השימוש ב־Copilot עם מודלים משלהם או מודלים מקומיים. לצורך תקצוב BYOK מקומי עדיין צריך להביא בחשבון נתוני טלמטריה חסרים מצד הלקוח ונתונים מהספק, ואילו מודלים מותאמים אישית לארגונים קיבלו בדוח סימון נפרד שמבוסס על נתוני שרת.
