Copilot отключит четыре модели: как подготовить рабочие процессы к 2 октября

3 сентября GitHub сообщил, что 2 октября планирует убрать из Copilot четыре модели: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code и Claude Opus 4.7. GitHub перечислил функции Copilot, которых коснётся изменение: Chat, правки внутри редактора, режим вопросов, агентный режим и дополнение кода. Поэтому командам стоит готовиться не к простой смене названия в списке, а к проверке всех мест, где выбор модели влияет на ежедневную разработку.

GitHub предлагает следующие направления перехода: с Gemini 3.5 Flash и Gemini 3.6 Flash — на Gemini 3.8 Flash, с Kimi K2.7 Code — на Kimi K3, с Claude Opus 4.7 — на Claude Opus 5. Это именно рекомендации по миграции, а не обещание полного совпадения. Новая модель может иначе следовать инструкциям, выбирать объём ответа, работать с контекстом и инструментами, отвечать быстрее или медленнее. Даже при одинаковых тарифных ставках стоимость результата, который разработчик действительно сможет использовать, может различаться.

Сначала найдите все зависимости

Начать полезно с короткой инвентаризации. Явный выбор модели в окне чата — лишь самый заметный случай. Модель также может быть задана в настройках организации или предприятия, выбрана по умолчанию для новых разговоров, закреплена в автоматизации либо неявно зависеть от доступности в конкретном клиенте. Отдельно нужно проверить интеграции и рабочие процессы, о которых GitHub прямо просит позаботиться до 2 октября.

Для каждой зависимости стоит записать владельца, используемую функцию Copilot, клиент и его версию, текущую модель, источник настройки и допустимый запасной вариант. Такая карта быстро выявляет две разные категории риска. В первой старая модель названа напрямую, поэтому после её отключения процесс может перестать работать ожидаемым образом. Во второй конкретного имени нет, но результат зависит от административной политики, версии расширения или набора моделей, доступных тарифному плану.

Особое внимание требуется компаниям с Copilot Business или Enterprise. Альтернативную модель может понадобиться отдельно разрешить в правилах доступа. Настройку способен принудительно задать владелец предприятия, передать её организации или оставить унаследованной от Default availability. При этом Kimi K3 относится к моделям с открытыми весами: для Business и Enterprise они по умолчанию отключены независимо от Default availability, хотя при отсутствии других ограничений администратор может разрешить их явно. Проверять следует не только панель управления, но и список моделей, который действительно видит пользователь.

Со 2 сентября управляемые предприятием настройки позволяют назначить любую доступную модель основной для новых разговоров и переопределить её для отдельной команды предприятия. GitHub объявил эту возможность общедоступной для Business и Enterprise в приложении Copilot, командной строке и VS Code. Распространять это утверждение на другие среды нельзя: основная модель, явный выбор пользователя и автоматический выбор остаются разными механизмами.

Проверяйте на собственных задачах, а не по названию

Продуктовая документация GitHub предупреждает, что модели различаются качеством, уместностью ответов, задержкой, склонностью к ошибочным утверждениям и пригодностью для разных задач. Но это общая справка, а не независимое сравнение и не испытание на кодовой базе конкретной компании. Надёжный выбор требует воспроизвести реальные рабочие задания.

Для проверки подойдёт небольшой набор уже завершённых задач, по которым команда знает приемлемый результат: объяснение незнакомого участка кода, локальная правка, исправление ошибки с тестом, создание тестов по существующему поведению и многошаговая задача для агента. Из примеров нужно удалить секреты и нестабильные внешние зависимости. Затем один и тот же исходный контекст и одинаковую формулировку дают старой модели и предполагаемой замене.

Сравнивать полезно не красоту ответа, а пригодность результата к работе. Собирается ли проект? Проходят ли относящиеся к задаче тесты? Не расширилась ли правка без необходимости? Сколько замечаний оставил рецензент и сколько ручных исправлений потребовалось, прежде чем результат можно было использовать? Какова задержка на типичной задаче? Если функция расходует кредиты, сколько их ушло на работу, результат которой команда признала пригодным? Заранее заданные критерии защищают от выбора по одному эффектному примеру.

В исходных материалах нет результатов испытаний на кодовой базе конкретной команды, поэтому приписывать рекомендуемым моделям выигрыш в скорости, точности или цене нельзя. Итоги внутренней проверки стоит хранить вместе с датой, версией клиента, сценарием и настройками: без этого сравнение трудно повторить после очередного обновления.

Учитывайте клиент и доступность

В справочнике GitHub как выводимые модели, так и предложенные альтернативы отмечены как общедоступные. Однако такая отметка не означает, что модель появится в любой функции, тарифе и клиенте. Новым моделям могут потребоваться обновлённые среды разработки или расширения. На момент проверки материалов для Kimi K3 была указана минимальная версия VS Code 1.131, для Claude Opus 5 — VS Code 1.128.0. Таблица названа предварительной, а часть значений для Gemini 3.8 Flash ещё не определена.

Следовательно, обновление клиента должно входить в план миграции, но его нельзя проводить вслепую на всех рабочих местах. Сначала альтернативу проверяют на поддерживаемой версии в тестовой группе. Затем подтверждают, что модель доступна участникам с нужными планами и правилами, а необходимые функции — чат, правки, агентный режим или дополнение кода — ведут себя приемлемо именно в используемой среде.

Автоматический выбор модели можно испытать как запасной вариант. Режим Auto учитывает доступность, состояние систем и сложность задачи, но всё равно подчиняется тарифу и административным правилам. Набор используемых им моделей меняется, поэтому Auto не воспроизводит поведение процесса, рассчитанного на одну закреплённую модель. В поддерживаемых интерфейсах можно увидеть, какая модель была выбрана фактически; это полезно заносить в журнал испытаний и разборов сбоев.

Цена — часть проверки, а не готовый ответ

Опубликованные GitHub ставки на 6 сентября показывают заметный разброс. За миллион токенов для Gemini 3.5 Flash указаны $1,50 за ввод, $0,15 за кэшированный ввод и $9 за вывод. Для Gemini 3.6 Flash и Gemini 3.8 Flash ставки совпадают: $0,75, $0,075 и $3,75 соответственно. У Kimi K2.7 Code это $0,95, $0,19 и $4, а у Kimi K3 — $3, $0,30 и $15. Для Claude Opus 4.7 и Claude Opus 5 указаны одинаковые значения: $5 за ввод, $0,50 за кэшированный ввод, $6,25 за запись в кэш и $25 за вывод.

Эти цифры — изменяемый тарифный снимок, а не прогноз счёта. Итог зависит от объёма контекста и ответа, использования кэша, функции Copilot и условий плана. Один кредит ИИ соответствует $0,01, при этом дополнение кода и подсказки следующего изменения такие кредиты не расходуют. Поэтому равная ставка у старой и новой модели ещё не доказывает ни равного расхода, ни одинаковой стоимости успешно выполненной задачи. Перед принятием решения и тем более перед утверждением бюджета цены следует проверить заново.

Переход без резкого переключения

После лабораторного сравнения разумно провести ограниченное внедрение. Небольшая группа разработчиков получает новую модель для выбранных сценариев, а команда наблюдает за качеством принятых изменений, временем ожидания, объёмом доработки и расходом кредитов там, где они учитываются. В испытание стоит включить не только удачные типовые запросы, но и длинный контекст, вызов инструментов агентом, неоднозначные требования и отказ внешней зависимости.

До расширения группы нужен понятный резервный путь: другая разрешённая модель либо Auto, если его изменчивость приемлема для конкретной работы. Следует заранее назначить человека, который сможет изменить политику доступа, и проверить, что откат не требует клиента, которого нет у сотрудников. Это особенно важно для автоматизации: незаметная смена модели способна сохранить формальную работоспособность, но изменить ответы и объём последующей проверки человеком.

После общего переключения работа не заканчивается. Нужно подтвердить модель, фактически доступную пользователям, повторить несколько контрольных задач и просмотреть ошибки интеграций. GitHub сообщает, что после вывода моделей удалять их вручную не потребуется. Однако команде всё равно полезно убрать устаревшие ссылки из внутренних инструкций и конфигураций, чтобы они не вводили в заблуждение при следующем изменении.

Что успеть до 2 октября

Практический порядок действий выглядит так:

1. Найти явные и неявные зависимости от четырёх выводимых моделей во всех заявленных GitHub сценариях.
2. Проверить правила предприятия и организации, список моделей у реального пользователя, тариф и версии клиентов.
3. Подобрать рекомендуемую альтернативу и как минимум один допустимый запасной вариант, не считая их заранее равноценными.
4. Воспроизвести набор ранее успешно выполненных задач и оценить корректность, задержку, труд рецензента и фактические затраты.
5. Провести ограниченное внедрение, зафиксировать условия возврата и только затем расширять переход.
6. После отключения перепроверить рабочие процессы и удалить устаревшие упоминания из документации.

Главный риск этой миграции — не исчезновение четырёх пунктов из меню, а скрытые предположения о том, где и как выбирается модель. Если выявить их заранее и испытать замену на собственной работе, обязательное изменение превращается в управляемое обновление, а не в эксперимент в день отключения.