# Gemini 4 Argon у GitHub Copilot: як обирати coding-модель і не збирати покемонів

> Gemini 4 Argon став GA у Copilot, а 19 жовтня GitHub прибирає шість старіших моделей. Замість гонитви за бенчмарками – практичний framework вибору моделі під свої coding-задачі.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/gemini-4-argon-copilot-model-selection

---

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-агентів загалом](/blog/ai-agent-evals), лише простіша. Створи 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 – [в окремій статті](/blog/claude-sonnet-5-5-coding).

## 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 назви моделі**. Краща архітектура – абстракції рівнів:

```ts
// Не 'gemini-4-argon' у 15 місцях коду, а policy-мапінг:
const MODEL_POLICY = {
  fast: '...',        // автодоповнення, класифікація, рутинні правки
  balanced: '...',    // більшість agent-задач
  'deep-review': '...', // складний дебаг, архітектурні рішення
} as const;
```

Коли модель деприкують (а її деприкують), ти міняєш один рядок policy, а не шукаєш згадки по всьому репозиторію. Якщо твій стек взагалі маршрутизує різні задачі різним моделям – подивись, як цю ідею доводить до межі [Haiku 5.5 і tiering маленьких моделей](/blog/claude-haiku-5-5-copilot).

## Як команди обирають модель неправильно

1. **Default за хайпом.** Нова модель → одразу default для команди, без жодного заміру на своїх задачах.
2. **Бенчмарк як істина.** Vendor-цифри – сигнал для «спробувати», не для «мігрувати».
3. **Hardcoded назви моделей** у скриптах, CI, агентських конфігах. Див. 19 жовтня.
4. **Один eval назавжди.** Моделі оновлюються; eval, якому пів року, вимірює минуле.
5. **Ігнорування вартості.** Модель, що розв'язує на 5% більше задач за 3× ціну, – не завжди апгрейд.

## Збери свій mini-eval сьогодні

Збери свій перший mini-eval сьогодні: візьми 10 закритих issues зі свого repo, прожени їх через дві моделі з picker (поточний default і Argon), запиши по кожній «змержив би без правок / з правками / не змержив би». Двадцять хвилин роботи – і в тебе буде більше даних про ці моделі для твого коду, ніж у всіх оглядачів разом.

Модель – це dependency. Онови її свідомо.