בחירת המודלים החדשה של GitHub Copilot דורשת התאמה ידנית

לתת ל־AI לבחור לעצמו את המודל זה רעיון מצוין, עד שמגיע החיוב בסוף החודש. ברוב המקרים מפתחים מעדיפים להשאיר את ההגה בידיים של המערכת כדי לא להתעסק עם שמות של מודלים והגדרות מסובכות בכל פעם שצריך לכתוב פונקציה. אתמול, ב־14 בספטמבר 2026, פרסמה GitHub עדכון רשמי שמשנה את ברירת המחדל הזאת: מנגנון הניתוב האוטומטי של GitHub Copilot מתפצל מעכשיו לשלוש דרגות שונות. אם אתם מנהלים צוות פיתוח או כותבים קוד בעצמכם, כדאי שתבינו איך זה עובד לפני שהקרדיטים שלכם יתאדו על משימות פשוטות מדי. לא הייתי ממהר לסמוך על אלגוריתם שקובע לבד כמה כסף לשרוף על כל שאילתה בלי לשאול אתכם קודם.

השליטה חוזרת אליכם.

במדריך הזה נפרק בדיוק איך עובד הניתוב החדש, איפה מגדירים אותו בסביבת הפיתוח שלכם כדי לעצור בזבוז תקציבי, ואיך להימנע מהטעויות הנפוצות של בחירת מודלים אוטומטית. בסיום הקריאה תוכלו להגדיר תצורה שפויה ויציבה לכל חברי הצוות שלכם.

שלוש דרגות על אותו מאגר

המערכת החדשה מחלקת את הבחירה האוטומטית לשלוש מדיניויות: Efficiency, Balance ו־Intelligence. הרעיון שעומד מאחורי השינוי הוא לתת לכם להגדיר מראש איך המערכת תשקול עלות, איכות ומהירות תגובה עבור כל שאילתה שאתם שולחים אל Copilot. מצב Efficiency מתמקד בשמירה על עלויות נמוכות ומתאים למשימות מהירות וישירות שאינן דורשות חשיבה מעמיקה. מצב Balance מאזן בין שלושת הגורמים ונועד לעבודה היומיומית הרגילה של מתכנת ממוצע. מצב Intelligence מתעדף איכות מעל הכל, ומיועד למשימות מורכבות יותר שדורשות עומק ארכיטקטוני או ניתוח לוגי רחב היקף.

בפועל, כל שלושת המצבים ניגשים בדיוק לאותו מאגר מודלים זמין. המערכת בוחנת כל פרומפט באופן נפרד לחלוטין, ולפיכך הניתוב הוא דינמי לחלוטין ומשתנה משאילתה לשאילתה לפי הניתוח שמבצע האלגוריתם של GitHub. ההבדל בין הרמות אינו ברשימת המודלים הפתוחה בפניהן, אלא במשקל שהאלגוריתם מעניק לכל פרמטר בזמן קבלת ההחלטה על ניתוב הבקשה. מנגנון הבחירה שוקל עבור כל שאילתה ושאילתה את שלושת הפרמטרים במקביל: עלות כספית ישירה, איכות הפלט הצפויה, וזמן ההמתנה עד לקבלת התשובה מהשרת. כאשר משנים את הרמה בהגדרות, לא מחליפים את הכלים הזמינים בארגז, אלא רק מורים לאלגוריתם איזה משקל יחסי להעניק לכל אחד מהמדדים האלה בזמן שהוא בוחן את שורות הקוד או את השאלה שנשלחה אליו.

משימה פשוטה כמו הוספת docstring לפונקציה קיימת עשויה להשתמש במודל קטן ויעיל, גם כאשר הניתוב האוטומטי מוגדר למצב intelligence.הדוקומנטציה של GitHub

זה אומר שגם אם תבחרו במצב הגבוה ביותר, המערכת לא אמורה לבזבז משאבים כבדים על השלמת שורת קוד בסיסית. היא אמורה לזהות את אופי המשימה ולהתאים את הכלי המתאים מתוך רשימת המודלים הנתמכים, אבל את שיקול הדעת לגבי נקודת האיזון היא מעבירה אליכם. לדעתי, להשאיר את המערכת על מצב Intelligence קבוע זו טעות ניהולית שתעלה לכם ביוקר, כי המערכת תמיד תעדיף לפנק אתכם במודל כבד כשיש לה ספק. לפיכך, השאלה אינה רק מה המודל יודע לעשות, אלא עד כמה אתם מוכנים להסתכן בחיוב עודף כשאין צורך אמיתי בכוח חישוב מוגבר.

החלטה של רגע הופכת לעלות קבועה.

איך להגדיר בכל סביבה

הפיצ'ר החדש נפרס בהדרגה בשלוש סביבות שונות: Visual Studio Code, ב־GitHub Copilot CLI ובאפליקציית הדסקטופ של GitHub Copilot. במקום להשאיר את המערכת על החלטות עיוורות שנקבעו מראש בצורה אקראית, מומלץ לקבוע מדיניות ברורה לצוות כבר עכשיו. לפיכך, נקודת המוצא ההגיונית לדעתי לרוב המפתחים היא לקבוע את מצב Balance כברירת מחדל, ולהחליף ידנית למצבים האחרים רק במשימות מוגדרות. לפי החברה, מצב Balance נועד לשקול יחד עלות, איכות ושיהוי ומתאים לעבודה שוטפת, ולכן בחירה זו מספקת פשרה סבירה בין קצב העבודה לבין איכות הפלט.

כדי ליישם את המדיניות הזו הלכה למעשה, כל מפתח בצוות צריך לעדכן את ההגדרות האישיות שלו בסביבת הפיתוח שבה הוא עובד. התהליך קצר ואינו דורש התקנות נוספות, אך מחייב משמעת עצמית של חברי הצוות עד ש־GitHub תאפשר ניהול ארגוני מרוכז. מפתחים שעובדים ישירות משורת הפקודה דרך ה־CLI יצטרכו לבדוק את הגדרות הניתוב דרך הפקודות המובנות, בעוד שמשתמשי הסביבה הגרפית באפליקציית הדסקטופ או בעורך הקוד יכולים לגשת לתפריט התצורה הישיר.

בשלב זה אין עדיין אפשרות להגדיר ברמת הארגון נעילה של המצבים עבור כל המפתחים. לפי ההודעה, GitHub מציגה את העדכון כצעד ראשון בדרך לשליטה נרחבת יותר ולאפשרות להתאים אישית את אופן פעולת הבחירה האוטומטית תוך הגברת השקיפות לפשרות הנעשות, אך נכון להיום כל מפתח שולט בהגדרה בסביבה המקומית שלו. מצב זה דורש תיאום פנימי בצוות כדי לוודא שמתכנתים זוטרים לא מפעילים מצב יקר באופן קבוע ללא סיבה.

התמחור וההנחה בחשבונית

החיוב שלכם אינו נקבע לפי המצב שבחרתם בתפריט ההגדרות, אלא לפי המודל שנבחר בפועל עבור כל פרומפט ופרומפט. אם הגדרתם את המערכת על מצב Intelligence אבל האלגוריתם ניתב שאילתה ספציפית למודל קל ומהיר, החיוב ייעשה לפי התעריף של המודל הקל בלבד. מנויים בתשלום ממשיכים לקבל הנחה של 10% על כל שימוש שמנותב דרך מנגנון הבחירה האוטומטי, מה שנועד לתמרץ משתמשים להשאיר את הניתוב פעיל במקום לבחור מודל ידנית מתוך התפריט.

ההנחה של 10% נשמעת טוב על הנייר, אבל היא יכולה להטעות מאוד בחישוב המצטבר. חיסכון צנוע של 10% על מודל פרימיום יקר במיוחד עדיין יעלה לכם הרבה יותר מאשר שימוש ישיר במודל בינוני חסכוני. תחשבו על זה כעל הנחה בחנות יוקרה: קניתם מוצר יקר בעשרה אחוז פחות, אבל עדיין שילמתם הון על משהו שאולי בכלל לא הייתם צריכים. אם מודל מתקדם גובה מחיר גבוה פי כמה לכל אלף טוקנים ביחס למודל בסיסי, ההנחה האמורה לא תציל את התקציב שלכם אם המערכת תחליט לנתב אליו רצף ארוך של שאלות.

ההבדל מתחדד כשבוחנים את היקף הפעילות החודשי של עשרות מתכנתים. פער של כמה סנטים בודדים לכל פרומפט מצטבר במהירות לסכומים משמעותיים בחשבון החודשי של הארגון. במקום להסתמך רק על ההנחה האוטומטית, יש לבחון בקפידה אילו משימות באמת מצדיקות מודלים עתירי פרמטרים. חשוב לזכור שמי שבוחר מודלים ידנית כלל אינו נהנה מההנחה הזאת, ולכן הבחירה האוטומטית נשארת אטרקטיבית על הנייר, בתנאי שלא מאפשרים לה להתפזר לכיוון הדרגה היקרה ביותר ללא בקרה.

המלכודת של מצב Intelligence

הבעיה הגדולה ביותר במערכת הנוכחית היא היעדר שליטה בתקציב. בדוקומנטציה של GitHub לא תמצאו אפשרות להגדיר תקרת מחיר קשיחה לשאילתה בודדת, ואין שום דרך להגביל את המכפיל המקסימלי שהמערכת יכולה להקצות. כשאתם מפעילים מצב Intelligence, אתם נותנים לאלגוריתם צ'ק פתוח לבחור במודל היקר ביותר ברשימה אם הוא מזהה את המשימה כמורכבת מספיק, מבלי להתחשב במצב החשבון שלכם. מנהלי מערכת אמנם יכולים לחסום מודלים ספציפיים במדיניות הארגונית כדי שהמערכת לא תיגש אליהם כלל, אך אין הגדרת סף מחיר כספית אוטומטית, וההחלטה הכלכלית מבין המודלים המורשים נותרת כולה בידי האלגוריתם.

פרומפטים שכוללים קבצים ארוכים, עצים מורכבים של פרויקטים או הנחיות מסועפות יישלחו כמעט תמיד למודלים היקרים ביותר במאגר. בלי מנגנון התרעה, בלי חלון אישור מראש ובלי יכולת לקבוע תקציב גג לפרומפט, החשבונית החודשית עלולה לקפוץ בסדרי גודל בלי שתשימו לב לכך בזמן אמת. זהו סיכון ממשי שראשי צוותים חייבים לנהל בעצמם באמצעות נהלי עבודה קפדניים. כאשר מפתחים מריצים שאילתות מורכבות הכוללות קטעי קוד נרחבים להשוואה, המערכת מזהה זאת מיידית כמשימת איכות ומנתבת אותה לרף הגבוה ביותר ללא שום התרעה על העלות הצפויה.

התלות בשיקול הדעת של האלגוריתם חושפת את התקציב לתנודתיות שקשה לחזות מראש. כאשר מפתח עובד על בעיה אלגוריתמית סבוכה ושולח עשרות בקשות ברצף, כולן עלולות להיות מנותבות למודל היקר ביותר ללא שום מעצור טכנולוגי. בהיעדר כלי ניטור שמציגים בזמן אמת כמה עלתה כל שאילתה שנשלחה זה עתה, ההפתעה תגיע רק בדו"ח השימוש החודשי. זו הסיבה שבגללה מומלץ להגביל את השימוש במצב זה רק למקרים שבהם מוצו כל האפשרויות האחרות.

איפה זה עדיין לא עובד

מנגנון הבחירה האוטומטי הכללי זמין בכלי JetBrains ונפרס ב־Visual Studio, אבל חלוקת הניתוב החדשה לשלוש דרגות עדיין נפרסת כרגע רק ב־VS Code, ב־CLI ובאפליקציית הדסקטופ של Copilot. ב־GitHub לא פרסמו מתי שלוש הדרגות החדשות יגיעו לסביבות הנוספות, כך שמפתחים בסביבות אלו נאלצים להמשיך להשתמש במנגנון ללא אפשרות הכוונון המשולשת. המשמעות היא שצוותים מבוזרים המשתמשים בכלי פיתוח שונים יתקשו לאכוף מדיניות אחידה בכל הפרויקטים שלהם.

בנוסף, יש את העניין המקומי שלנו. צוותים שכותבים פרומפטים או הערות בקוד בעברית צריכים לקחת בחשבון שטוקניזציה בעברית מנפחת את גודל הקלט הנשלח למערכת, למרות שלפי הדוקומנטציה של GitHub החלטות הניתוב נקבעות לפי מהות המשימה ולא לפי שפת הבקשה. עם זאת, כל טוקן נוסף עדיין נספר ישירות בחיוב החודשי עבור המודל שנבחר. עד שלא נראה נתונים רשמיים וספי החלטה ברורים, אל תמהרו לחלק למערכת סמכויות תקציביות מלאות.