Чому GitHub Copilot тепер витрачає менше токенів на однакові завдання кодування?

GitHub змінив підхід Copilot до контексту в чотирьох системах. Оновлення скоротили споживання токенів, не знижуючи якість виконання завдань.

GitHub Copilot — це агент штучного інтелекту для кодування. Він працює у терміналах і редакторах, а також у процесах код-рев'ю. 2 вересня 2026 року команда опублікувала детальний розбір чотирьох внутрішніх змін. Вони зменшують кількість токенів, які бачить і генерує модель, зберігаючи рівень успішного завершення завдань.

Стаття належить Еріку Крістенсену та Напалісу Кліціюс. Ці інженери працюють над агентним фреймворком, що живить Copilot CLI, програму Copilot і Copilot code review. Вони пояснюють: ранні спроби скоротити окремі відповіді інструментів дали зворотний ефект. Утиліта RTK стискала вивід оболонки. Але коли модель потребувала вилучених рядків, вона повторно відкривала оригінальний вивід або перезапускала команду. Ці кроки відновлення додавали черги і переносили більше контексту вперед. Окрема відповідь ставала коротшою. Проте повне завдання споживало більше токенів і тривало довше.

Пастка локальних метрик

Кількість токенів на виклик інструменту виглядає очевидною мірою ефективності. Команда виявила: це помилкова ціль. У їхніх бенчмарках агресивне стиснення виводу змушувало модель повторювати роботу або читати повний збережений вивід. Це підвищувало кінцеві витрати і знижувало успішність завдань. Наприклад, рання версія стискала вивід git diff. Бенчмарки показували: агенти повторно відкривали оригінальний diff для відновлення втраченої інформації. Цей фільтр прибрали.

Урок: зміну ефективності треба оцінювати по всьому завданню — від запиту користувача до фінального результату. Мета стала проста — вилучати лише те, чого модель ніколи не використовувала.

Стискаємо шум, зберігаємо корисну інформацію

Аналіз запусків бенчмарків показав: вивід установки, збірки, тестів та лінтингу часто містить повторюваний шум. Вивід типу source та результати довільних команд частіше несуть інформацію, потрібну агенту. Цей аналіз лежав у основі селективного компресора з тричастковою політикою.

Зберігаємо вивід типу source та довільний. Команди на кшталт cat і git diff повертаються без змін. Те саме стосується git show і довільних скриптів. Реорганізовуємо результати пошуку без втрати вмісту. Збіги та списки файлів від інструментів типу grep групуються ефективніше, зберігаючи кожен результат. Стискаємо повторюваний шум вибірково. Вивід установки та збірки стискається лише при суттєвій економії. Вивід тестів і прогресу підпорядковується тому ж правилу.

Коли вивід стискається, агент все ще може отримати повний оригінал безпосереднім шляхом відновлення. Команда відстежувала: чи відкривав агент збережений оригінал, чи перезапускав команди, чи повторював дослідження, чи звужував пошук, чи робив додаткові ходи. Часте відновлення вказувало б на те, що компресор вилучив щось цінне. У офлайн-завданнях, де спрацювало стиснення, статистично значущої регресії успішності не виявлено. Агенти майже ніколи не відкривали збережені оригінали. У онлайн-експерименті середні витрати незначно зменшилися без суттєвої регресії в відстежуваних метриках якості.

Прибираємо форматування, а не інформацію

Інструмент view читає вміст файлів у контекст. Раніше view додавав номер до кожного рядка перед показом моделі. Попередні інструменти редагування використовували ці номера для таргетингу змін. Поточні інструменти замість цього порівнюють оточуючий код і не використовують номера рядків. Префікси залишилися, хоча нормальний робочий процес їх не вимагав.

Кожен префікс був малий. Але повторений через кожен рядок і кожен прочитаний файл, він накопичувався протягом сесії. Тому його прибрали. Номери рядків залишаються корисними у diff-ах і коротких уривках. Тут вони були марнотратними, бо приклеювалися до кожного читання файлу без служіння поточному процесу редагування.

Видалення зменшило витрати на інференс моделі приблизно на 5% у офлайн бенчмарках агентного кодування. Успішність залишилася в межах очікуваної дисперсії між запусками. Помилки редагування не зросли. Онлайн-експеримент з користувачами Copilot CLI скоротив середні щоденні витрати на інференс на користувача приблизно на 3%. Це сталося без суттєвої регресії в метриках якості та задоволеності. Для розробників це означає: більше контекстного вікна доступне для власної роботи, а не для форматування, яке агент не використовує.

Стискаємо промпти, не стискаючи намір

Промпти несуть інструкції, що форму

Джерела, за якими написано статтю

  • "GitHub Blog
    https://github.blog/ai-and-ml/github-copilot/how-we-make-ai-coding-more-cost-efficient-without-sacrificing-task-quality/"

Читайте також