תיאור ההשקה והיכולות המוצהרות נשען על המקורות הראשוניים והטכניים המופיעים בסוף הכתבה.
ניתוח PRESS AIהמשמעות לעסקים והמלצות היישום הן ניתוח מקצועי של PRESS AI — לא הבטחה של היצרן.
עובדות — מה קרה
ב־14 בספטמבר 2026 הודיעה GitHub על שלוש רמות חדשות לבחירת מודל אוטומטית ב־Copilot: Efficiency, שמעדיפה עלות נמוכה; Balance, שמשקללת עלות, איכות וזמן תגובה; ו־Intelligence, שנותנת עדיפות לאיכות במשימות מורכבות.
הבחירה אינה קובעת מודל יחיד וקבוע. לפי GitHub, כל שלוש הרמות משתמשות באותה קבוצת מודלים זמינה, ו־Copilot מעריך כל בקשה בנפרד כדי לנתב אותה למודל מתאים. גם ברמת Intelligence, בקשה פשוטה עשויה לעבור למודל קטן ומהיר.
זהו שינוי במנגנון הניתוב, לא השקה של מודל חדש. הרעיון הוא לאפשר למשתמש לומר למערכת איזו פשרה הוא מעדיף, בזמן שהמערכת ממשיכה להחליט איזה מודל מתאים לכל משימה בפועל.
עובדות — איך הבחירה האוטומטית עובדת
התיעוד הרשמי מתאר שני שיקולים מרכזיים בניתוב: מורכבות המשימה, ומצב המערכות והזמינות בזמן אמת. המטרה היא לשמור מודלים יקרים וחזקים יותר למקרים שבאמת דורשים אותם, ולהשתמש במודלים יעילים יותר בפעולות שגרתיות.
הרמה שנבחרה משנה את העדפת הניתוב, אך אינה מבטלת מגבלות אחרות. Copilot בוחר רק מתוך המודלים הזמינים בתוכנית של המשתמש ושאינם חסומים במדיניות הארגון, בדרישות תושבות נתונים או בהגבלות תאימות אחרות.
GitHub מציינת שאפשר לראות איזה מודל שימש בפועל לכל תשובה. המיקום משתנה בין הממשקים: למשל ליד בורר המודל באפליקציית Copilot, במסוף ב־Copilot CLI או באמצעות מעבר על התשובה בממשקים נתמכים.
עובדות — זמינות, עלות ותנאים
ההשקה נמצאת בתהליך פריסה ל־Visual Studio Code, ל־Copilot CLI ולאפליקציית GitHub Copilot. התיעוד מבהיר שרמות הבחירה עצמן זמינות בשלושת הממשקים האלה; בחירה אוטומטית ללא שלוש הרמות זמינה גם בממשקי Copilot נוספים.
הבחירה האוטומטית זמינה בכל תוכניות GitHub Copilot, אך קבוצת המודלים בפועל תלויה בתוכנית ובמדיניות. לכן שני משתמשים שבחרו אותה רמה אינם בהכרח מקבלים גישה לאותם מודלים או לאותו מסלול ניתוב.
לא הוכרז מחיר קבוע חדש עבור הרמות. החיוב נקבע לפי המודל ש־Auto בחר, ללא קשר לשם הרמה, ומשתמשים בתוכניות בתשלום ממשיכים לקבל הנחה של 10% על שימוש המחויב דרך Auto. רשימת המודלים והתנאים עשויה להשתנות.
ניתוח PRESS AI — למה זה חשוב
הניתוח של PRESS AI: המהלך מסמן מעבר מבחירת מודל ידנית לניהול מדיניות. במקום שכל עובד ילמד רשימה משתנה של שמות ומחירים, אפשר להגדיר כיוון כללי ולתת למערכת לנתב כל משימה. זו הפשטה שימושית, במיוחד לצוותים שמבצעים הרבה משימות שונות.
לעסק, היתרון האפשרי אינו רק נוחות. משימות קצרות כמו הסבר קוד או כתיבת תיעוד אינן תמיד מצדיקות מודל יקר, בעוד תיקון מורכב או תכנון ארכיטקטורה עשויים להצדיק עדיפות לאיכות. ניתוב טוב יכול לצמצם בזבוז בלי להפוך את בחירת המודל לעבודה בפני עצמה.
אבל השם של הרמה אינו מדד ביצוע. Efficiency לא מבטיחה שהעלות הכוללת תהיה הנמוכה ביותר, ו־Intelligence לא מבטיחה תוצאה נכונה. כדי לדעת אם נוצר ערך, צריך למדוד זמן, שימוש מחויב, תיקונים נדרשים ואיכות תוצר על משימות אמיתיות.
מה זה לא אומר
העדפת Intelligence אינה הוראה להשתמש תמיד במודל הגדול ביותר. GitHub אומרת במפורש שגם בקשה פשוטה יכולה להיות מנותבת למודל קטן יותר. באותה מידה, Efficiency אינה מבטיחה שכל בקשה תגיע למודל הזול ביותר אם המערכת מעריכה שנדרש מודל מסוג אחר.
הבחירה האוטומטית גם אינה מחליפה ביקורת קוד, בדיקות אבטחה או אחריות מקצועית. המערכת בוחרת מנוע; היא אינה יודעת לבדה מהו הסיכון העסקי של שינוי, אילו דרישות רגולטוריות חלות או מי צריך לאשר פעולה בלתי הפיכה.
ולבסוף, הרמות אינן תקציב ארגוני קשיח. אם צוות רוצה תקרות שימוש, הרשאות או הגבלות על מודלים, עליו להגדיר אותן בכלי הניהול ובמדיניות המתאימה. העדפת ניתוב היא שכבה אחת בתוך ממשל AI רחב יותר.
מה כדאי לעשות עכשיו
למשתמש יחיד, אפשר להתחיל ב־Balance למשימות יום־יומיות ולעבור ל־Efficiency או Intelligence כאשר יש סיבה ברורה. לאחר כל תשובה, בדקו איזה מודל נבחר והאם התוצאה הצדיקה את זמן התגובה ואת השימוש המחויב.
לצוות, כדאי להריץ ניסוי קטן על קבוצה קבועה של משימות: תיעוד, תיקון באג, כתיבת בדיקות ושינוי רב־קבצים. משווים בין הרמות לפי אותם קריטריונים, ולא לפי תחושת בטן או איכות של דוגמה אחת.
אם הרמות עדיין אינן מופיעות, זכרו שההשקה מדורגת. ודאו שהממשק נתמך ומעודכן, ובארגון בדקו שהמודלים הרלוונטיים אינם חסומים במדיניות. אל תשנו מדיניות רק כדי לראות אפשרות חדשה לפני שבדקתם את השלכות הנתונים והעלות.
- בחרו 10–20 משימות מייצגות
- תעדו מודל שנבחר, זמן, שימוש ותיקונים
- בדקו איכות עם אדם שמכיר את הקוד
- קבעו ברירת מחדל רק אחרי השוואה
השורה התחתונה
GitHub נותנת למשתמשים דרך פשוטה יותר לבטא את העדיפות שלהם בין עלות, זמן ואיכות, בלי לנהל ידנית כל בחירת מודל. זה יכול להפוך עבודה מרובת מודלים לנגישה ומסודרת יותר.
הערך האמיתי ייקבע לפי התוצאות, לא לפי שם הרמה. התחילו ב־Balance, מדדו כמה משימות אמיתיות, והשוו לפני שאתם מאמצים ברירת מחדל לצוות שלם.
רוצים להבין את הנושא — או ממש לדעת לבנות תהליך כזה?
אפשר להתחיל בשיעור הפתוח ולהבין את המושגים. הקורס מיועד למי שרוצה לראות תהליך, לתרגל ולבנות אב־טיפוס מוגבל ובטוח.
המקורות שעליהם נשענת הכתבה
מומלץ לפתוח את המקורות, לבדוק את תאריך העדכון ולקרוא את המגבלות הטכניות לפני החלטה מקצועית.