Gemini 3.8 Flash дороже по токенам? Оценка стоимости Agent в 2026

2 сентября 2026 года Google объявила о переводе Gemini 3.8 Flash в общий доступ и указала, что сложные длинные задачи могут расходовать больше токенов из-за дополнительных шагов рассуждения и повторных вызовов инструментов — это следует из официальной записи о выпуске Gemini API.

Симптом: цена одного запроса к Gemini 3.8 Flash близка к Gemini 3.7 Flash, но счёт Agent растёт после миграции.
Самое быстрое решение: простые задачи оставить на Gemini 3.7 Flash или включить низкую интенсивность рассуждения, а Gemini 3.8 Flash использовать для сложного кода после сравнения полной стоимости успешной доставки.

Эта статья предназначена для команд, которые оценивают переход на Gemini 3.8 Flash и опасаются неконтролируемого расхода Agent. Она также нужна FinOps- и платформенным инженерам, которым требуется отделить модельные расходы от инструментов и исполнителей, а командам AI Coding — от планируют ли они дополнительную ёмкость для Xcode, браузера и macOS.

Важно: близкая стоимость входных и выходных токенов не означает одинаковую стоимость задачи. В производственной системе платятся также за повторные запросы, возвращаемые результаты инструментов, ожидание исполнителя и ручную доработку.

Сначала зафиксируйте, что именно вы оплачиваете

Стоимость токенов Gemini 3.8 Flash нельзя оценивать по одной строке в тарифной таблице. Для Agent полезно разделить счёт на четыре независимых слоя:

1. входные токены — инструкция, история диалога, содержимое репозитория и результаты предыдущих действий;
2. выходные и thinking-токены — ответ модели, планирование, проверка промежуточных гипотез;
3. внешние действия — поиск, function calling, code execution, работа с файлами и браузером;
4. исполнение и доставка — время занятого Mac, сборка, симулятор, очередь и ручная проверка.

Официальная страница тарифов Gemini API должна быть источником актуальной цены, валюты, бесплатных лимитов и условий для конкретного типа запроса. Не переносите тариф из старого отчёта: Google может менять цены, доступность моделей и правила промо-периода.

Почему Gemini 3.8 Flash способен использовать больше токенов, чем Gemini 3.7 Flash? Не обязательно из-за изменения базовой цены. Причина может быть в большем числе внутренних шагов рассуждения, повторном уточнении плана и дополнительных итерациях с инструментами. В документации Google по thinking отдельно описывается управление интенсивностью рассуждения; поэтому сравнивать следует не только токены одного ответа, а весь путь до принятого результата.

Для коротких запросов задайте нижнюю границу рассуждения

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

Начните с трёх потоков:

• Gemini 3.7 Flash — если текущая версия уже проходит регрессионные тесты, а выигрыш от новой модели не измерен;
• Gemini 3.8 Flash с низкой интенсивностью — если нужны обновлённые возможности, но задача ограничена одним контекстом и небольшим числом изменений;
• Gemini 3.8 Flash с настройкой по умолчанию — если низкий режим часто приводит к неверному анализу или дополнительным ручным исправлениям.

Проверка должна выполняться на одинаковом наборе входных данных, одинаковом лимите инструментов и одинаковых критериях приёмки. В отчёт внесите:

• входные токены;
• выходные токены;
• thinking-токены, если они возвращаются или доступны в телеметрии;
• задержку до первого ответа и полное время задачи;
• факт принятия результата без ручной переделки;
• количество повторных вызовов.

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

Не смешивайте в одной метрике качество и расходы. Benchmark показывает поведение на конкретном тесте, но не доказывает, что в вашем репозитории задача завершится быстрее или с меньшим числом вызовов.

Для сложного кода считайте завершённую задачу, а не запрос

Перенос сложного репозитория с Gemini 3.7 Flash на Gemini 3.8 Flash нужно начинать с ограниченной выборки: межфайловая правка, анализ зависимостей, исправление тестов и изменение конфигурации сборки. Для каждого сценария создайте одинаковую стартовую ветку и сохраните итоговый diff.

Вторая таблица должна отражать не тариф, а производственный результат:

Для каждого провала назначьте категорию: неверный план, пропущенная зависимость, синтаксическая ошибка, неудачный тест, ошибка инструмента или лимит контекста. Это позволяет понять, за что именно вы платите дополнительные thinking-токены.

Плюсы переключения сложных задач на Gemini 3.8 Flash:

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

Минусы:

• более длинное рассуждение не гарантирует рабочий diff;
• неудачный цикл с инструментом добавляет и токены, и время исполнителя;
• результаты нельзя переносить между моделями без повторной проверки;
• рост качества на тестовом репозитории может не сохраниться на закрытом коде.

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

Переход можно считать подтверждённым только после сохранения артефактов: diff, логи тестов, трасса вызовов, расход токенов и отметка о ручном вмешательстве. Страница актуальных моделей Gemini API нужна для проверки идентификатора, статуса и поддерживаемых возможностей перед публикацией конфигурации.

Для инструментального Agent отделите циклы от результата

Function calling, поиск и выполнение кода превращают один запрос в цепочку. Модель предлагает действие, исполнитель возвращает результат, модель анализирует его и предлагает следующий шаг. При этом полученные данные могут снова войти в контекст. Документация по function calling и руководство по code execution полезны не как калькулятор итоговой цены, а как описание границ такого цикла.

В вашем журнале нужен минимум следующий набор полей:

• идентификатор задачи и версии модели;
• номер итерации;
• размер входа и ответа;
• название инструмента и размер его результата;
• причина следующего вызова;
• успешное условие остановки;
• ошибка, тайм-аут или повтор;
• стоимость внешнего исполнителя;
• время занятости среды.

Расчёт делайте по формуле:

полная стоимость Agent = токены всех запросов + стоимость внешних операций + стоимость исполнения + ручная доработка.

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

Наиболее частые источники перерасхода:

• инструмент возвращает весь файл вместо нужного фрагмента;
• Agent повторяет поиск, не сохраняя уже проверенный результат;
• ошибка схемы вызывает повторный function call;
• тест падает, но модель получает слишком мало контекста и повторяет неверный план;
• завершение не формализовано, поэтому Agent продолжает проверку после выполнения задачи.

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

Для длинных задач планируйте ёмкость по времени и восстановлению

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

Соберите для каждой очереди четыре наблюдаемых показателя:

• длительность от постановки до принятого результата;
• число модельных и инструментальных раундов;
• число восстановлений после ошибки;
• время ожидания исполнителя и фактическое время его работы.

Затем разделите маршруты:

• базовый: короткие задачи с предсказуемым контекстом — Gemini 3.7 Flash или Gemini 3.8 Flash в низком режиме;
• сложный: межфайловые изменения и тестовый цикл — Gemini 3.8 Flash после регрессии;
• критичный: релизные изменения и миграции — двойной маршрут с возможностью отката и ручным подтверждением.

Триггером повторного расчёта должны быть не только изменения цены. Пересматривайте модель после изменения режима по умолчанию, правил thinking, поддержки инструментов, статуса модели или завершения промо-периода. Следите за журналом изменений Gemini API, а устаревшие идентификаторы проверяйте по странице вывода моделей из эксплуатации.

Для Mac отделите вычисление модели от выполнения доставки

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

Потребуется ли после перехода на Gemini 3.8 Flash больше Mac-ресурсов? Не автоматически. Быстрый ответ модели может уменьшить простой между шагами, но дополнительное рассуждение может, наоборот, увеличить число действий. Считайте не токены, а фактическое время занятости Mac, пик параллельных сборок, объём диска, число активных симуляторов и очередь ожидания.

Для чисто аналитических задач достаточно не менять пул Mac и измерить, не появились ли новые вызовы инструментов. Для реальной доставки выделяйте изолированную среду, если Agent одновременно меняет файлы, запускает Xcode и работает с браузером. Отдельная среда особенно важна при несовместимых версиях зависимостей и при необходимости сохранить воспроизводимое состояние проекта.

Если вы планируете такую инфраструктуру, сначала сопоставьте сценарии с описанием возможностей удалённого Mac, а вопросы по изоляции и доступу проверьте в справочных материалах kvmsync. Это позволит не смешивать стоимость Gemini API с тарифом исполнительной машины.

Проведите миграцию по проверяемому маршруту

Перед расширением трафика пройдите этот список. Каждый пункт должен иметь владельца и сохранённый артефакт.

• [ ] Зафиксируйте версии Gemini 3.7 Flash и Gemini 3.8 Flash, параметры thinking и идентификаторы инструментов.
• [ ] Подготовьте одинаковые входные данные, права доступа, лимиты и критерии успешного результата.
• [ ] Запишите для каждого запуска входные, выходные и thinking-токены отдельно.
• [ ] Сохраните все tool calls, ответы исполнителей, ошибки, повторы и причины остановки.
• [ ] Измерьте время до принятого результата, ручную доработку и очередь Mac.
• [ ] Разделите короткие, сложные, фоновые и критичные задачи в маршрутизаторе.
• [ ] Проверьте, не возвращают ли инструменты лишние файлы, логи или результаты поиска.
• [ ] Запустите регрессию на закрытом репозитории, а не только на публичном benchmark.
• [ ] Установите условие отката на Gemini 3.7 Flash при росте полной стоимости или падении качества.
• [ ] Повторите расчёт после изменения тарифов, режима рассуждения, статуса модели или условий промо.

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

Модельный счёт — не единственная причина роста расходов. У текущей схемы без раздельного учёта обычно есть три слабых места: повторные вызовы незаметно смешиваются с успешными, Mac простаивает в очереди или блокируется длинной сборкой, а общая стоимость Agent становится неясной из-за ручной доработки. Для временного пилота или проверки реального Xcode-потока аренда Mac в kvmsync может быть практичнее покупки отдельной машины: вы проверяете исполнительную нагрузку отдельно от Gemini API и не привязываете эксперимент к постоянной конфигурации. При постоянном стабильном тяжёлом использовании или необходимости физических периферийных устройств собственный Mac может оказаться рациональнее; сравнить доступные условия можно на странице аренды Mac.

После этого оцените не только токены, но и всю цепочку: модель, инструменты, повторы, человеческое время и Mac. Именно такая разбивка покажет, действительно ли Gemini 3.8 Flash дороже для вашего Agent или более глубокое рассуждение снижает стоимость завершённой задачи. Последняя проверка данных выполнена 3 сентября 2026 года по моделям Gemini API, документации thinking, тарифной странице и журналу релизов Google; при изменении официальных условий расчёт необходимо обновить.