13 жовтня Gemini 4 Argon став generally available у GitHub Copilot – для планів Pro+, Max, Business і Enterprise, практично на всіх поверхнях від VS Code до Xcode, з usage-based білінгом за прайсом провайдера. GitHub позиціонує модель для «складних coding-, agentic- і reasoning-задач». Але головний урок тижня не в новій моделі: 19 жовтня GitHub одночасно прибирає шість старіших. Модель у 2026 – це dependency з власним lifecycle, і обирати її треба власним eval-ом, а не стрічкою Twitter.
Argon у Copilot: що саме з'явилось
Gemini 4 Argon доступний у VS Code, Visual Studio, Copilot CLI, coding agent, Copilot app, JetBrains IDE, Xcode та Eclipse. Розкочується поступово, тож у твоєму picker може з'явитися не одразу. Для Business/Enterprise модель вмикається за замовчуванням, якщо адміністратор не вимкнув її через model policy.
GitHub пише (vendor-заява з їхнього early testing, не незалежний бенчмарк): «у ранньому тестуванні Gemini 4 Argon розв'язав більше задач, ніж попередні моделі Gemini, на кожному coding-бенчмарку, з найбільшим приростом у Copilot CLI; модель ретельно перевіряє свою роботу, тестуючи крайні випадки перед завершенням».
Звучить добре. Але «краще за попередні Gemini» – це порівняння всередині однієї родини, виміряне самим вендором на власних задачах. Причина спробувати – так. Причина міняти default у всій компанії – ні.
Як обирати модель: не за Twitter
Процедура та сама, що ми описували для оцінки AI-агентів загалом, лише простіша. Створи 20–50 реальних задач зі свого repo:
- fix bug (із закритих issues);
- add test до наявного коду;
- refactor компонента;
- update API між версіями;
- investigate CI failure.
Для кожної моделі-кандидата виміряй чотири речі:
| Метрика | Питання |
|---|---|
| Task completion | Скільки задач завершено без людини |
| Human corrections | Скільки правок потрібно до merge |
| Latency | Скільки чекаєш на результат |
| Total cost | Токени × ціна, включно з ретраями |
І п'яту, найнедооціненішу: regression rate – як часто «готове» рішення ламає щось сусіднє.
Після цього вибір моделі перестає бути релігійним питанням і стає інженерним рішенням із цифрами. Детальніший розбір цього підходу на прикладі Sonnet 5.5 – в окремій статті.
Model churn – уже норма
Тепер про головне. 19 жовтня GitHub прибирає з Copilot одразу шість моделей: Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini і Grok 4.5. Користувачів автоматично переводять на рекомендовані заміни (Gemini 3.7 Flash → Gemini 3.8 Flash, GPT-5.5 → GPT-5.6 Sol тощо), якщо адміністратор не вимкнув global default.
Задумайся: модель, яку твоя команда могла обрати default-ом пів року тому, за місяць перестане існувати. Це не виняток – це нова норма життєвого циклу.
Практичний висновок: не будуй процеси навколо hardcoded назви моделі. Краща архітектура – абстракції рівнів:
// Не 'gemini-4-argon' у 15 місцях коду, а policy-мапінг:
const MODEL_POLICY = {
fast: '...', // автодоповнення, класифікація, рутинні правки
balanced: '...', // більшість agent-задач
'deep-review': '...', // складний дебаг, архітектурні рішення
} as const;Коли модель деприкують (а її деприкують), ти міняєш один рядок policy, а не шукаєш згадки по всьому репозиторію. Якщо твій стек взагалі маршрутизує різні задачі різним моделям – подивись, як цю ідею доводить до межі Haiku 5.5 і tiering маленьких моделей.
Як команди обирають модель неправильно
- Default за хайпом. Нова модель → одразу default для команди, без жодного заміру на своїх задачах.
- Бенчмарк як істина. Vendor-цифри – сигнал для «спробувати», не для «мігрувати».
- Hardcoded назви моделей у скриптах, CI, агентських конфігах. Див. 19 жовтня.
- Один eval назавжди. Моделі оновлюються; eval, якому пів року, вимірює минуле.
- Ігнорування вартості. Модель, що розв'язує на 5% більше задач за 3× ціну, – не завжди апгрейд.
Збери свій mini-eval сьогодні
Збери свій перший mini-eval сьогодні: візьми 10 закритих issues зі свого repo, прожени їх через дві моделі з picker (поточний default і Argon), запиши по кожній «змержив би без правок / з правками / не змержив би». Двадцять хвилин роботи – і в тебе буде більше даних про ці моделі для твого коду, ніж у всіх оглядачів разом.
Модель – це dependency. Онови її свідомо.