45fd01a15e
Владелец возразил на моё утверждение, что gemini-3.7-flash не существует.
Он прав, утверждение было неверным, и я повторил его в четырёх заданиях.
gemini-3.7-flash — настоящее семейство, уровень усилия у неё отдельный
параметр. В интерфейсе Antigravity это видно прямо: пункт «Gemini 3.7
Flash» с вложенным выбором Low/Medium/High. В коде это отражено:
_display_to_cli разбирает «Gemini 3.7 Flash (High)» в пару
("gemini-3.7-flash", "high"). Меня ввела в заблуждение первая колонка
вывода agy models со склеенными идентификаторами.
Настоящий дефект был в коде: _model_supported_efforts вызывала
discover_models() БЕЗ профиля, то есть в глобальном окружении без входа.
Карта поддерживаемых усилий оставалась пустой, подстановка уровня по
умолчанию не срабатывала, и agy отвергал вызов с «requires --effort» —
при совершенно настоящей модели.
profile_id проведён через agy_generate в _model_supported_efforts.
Проверено исполнением: gemini-3.7-flash без указания усилия отрабатывает
и возвращает ответ.
Моки в test_antigravity_concurrency приведены к терпимости по kwargs.
Добавлена поправка agents/inbox/2026-08-24-CORRECTION-gemini-model-names.md:
ложное утверждение попало в A9, A11, A18 и B8, и без опровержения кто-то
чинил бы несуществующую проблему или сломал рабочую конфигурацию.
Тесты: 359 passed, ruff чисто.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.1 KiB
Поправка: gemini-3.7-flash — настоящая модель
Дата
2026-08-24
Кому
Обоим исполнителям. Отменяет утверждение, повторённое в четырёх заданиях.
Что было сказано неверно
В заданиях A9, A11, A18 и B8 ревьюер написал, что модели gemini-3.7-flash у провайдера не существует и что она «попала в конфигурацию через литерал в коде». Формулировки вроде:
у живого провайдера
gemini-3.7-flashне существует
Это неверно. Утверждение опровергнуто владельцем и проверено исполнением.
Как есть на самом деле
gemini-3.7-flash — настоящее семейство моделей. Уровень усилия у неё отдельный параметр, а не часть имени. В интерфейсе Antigravity это видно прямо: пункт «Gemini 3.7 Flash» с вложенным выбором Low / Medium / High.
В коде это уже отражено: _display_to_cli разбирает Gemini 3.7 Flash (High) в пару ("gemini-3.7-flash", "high").
Меня ввёл в заблуждение вывод agy models: в первой колонке он печатает склеенные идентификаторы вида gemini-3.7-flash-high. Я принял их за настоящие имена моделей, а флаг --model ожидает базовое имя плюс --effort.
Настоящий дефект — и он исправлен
Ошибка была не в конфигурации, а в коде.
_model_supported_efforts вызывала discover_models() без профиля — то есть в глобальном окружении, где вход agy не выполнен. Карта поддерживаемых усилий оставалась пустой, подстановка уровня по умолчанию не срабатывала, и agy отвергал вызов:
invalid model selection (--model "gemini-3.7-flash" --effort ""):
--model gemini-3.7-flash requires --effort (available: low, medium, high)
Исправлено: profile_id проведён через agy_generate в _model_supported_efforts. Проверено исполнением — gemini-3.7-flash без указания усилия отрабатывает и возвращает ответ.
Что из этого следует
- Конфигурацию владельца по этому поводу править не нужно.
gemini-3.7-flashу ролиorchestratorиgemini-3.6-flash-highу ролиfast— оба варианта допустимы. - Валидация моделей не должна отвергать базовые имена без суффикса усилия. Если сравниваете с обнаруженным списком, учитывайте, что там склеенные идентификаторы, а в конфигурации может стоять базовое имя.
- Требование не подставлять модели литералом остаётся в силе — оно верное и связано с другим: списки вида
["grok-3","grok-2"]и["gemini-2.5-pro", …]в коде действительно были выдуманы, иgemini-2.5-*у провайдера действительно нет.
Почему это записано отдельным документом
Задания читаются как справочный материал, и ложное утверждение в четырёх из них означало бы, что кто-то починит несуществующую проблему или сломает рабочую конфигурацию. Ошибка ревьюера, а не исполнителей.