Симптом: бюджет Gemini 3.5 Flash Computer Use выглядит как одна строка расходов на API, хотя агенту ещё нужны среда выполнения, обработка экранного состояния и контроль действий.
Быстрое решение: считайте отдельно вызовы модели, среду, цикл «состояние экрана — действие — результат», повторы, ручные проверки и изоляцию. Для задач только в браузере сначала оцените лёгкую изолированную среду; облачный Mac рассматривайте, если нужно проверять macOS, Safari или системные взаимодействия.
Материал предназначен для разработчиков, которые переводят прототип Computer Use в постоянный запуск, и для QA- и платформенных инженеров, составляющих бюджет с учётом повторов и ручной проверки.
Он также пригодится командам, которым нужно проверить взаимодействие с приложениями macOS и понять, оправдывает ли их сценарий отдельная Mac-среда.
Разложите стоимость Gemini 3.5 Flash Computer Use по статьям
Какие расходы учитывать при развёртывании Gemini 3.5 Flash Computer Use? Не сводите оценку к цене обращения к модели. Computer Use не предоставляет готовый удалённый рабочий стол: клиентская часть принимает предложенные моделью действия, исполняет их в целевой среде и возвращает новое состояние интерфейса. Поэтому помимо вызовов Gemini API вам нужно учитывать исполнительный контур и его обслуживание. Такой принцип описан в документации по реализации Computer Use и в официальном объявлении о Computer Use для Gemini 3.5 Flash.
Соберите карту затрат из отдельных категорий:
- Модельные вызовы: данные на входе, ответ модели и обращения, которые потребовались для завершения сценария.
- Среда выполнения: браузер, контейнер, виртуальная машина или Mac, где исполняются действия.
- Рабочий цикл: получение состояния экрана, передача его модели, выполнение действия и возврат результата.
- Эксплуатация: управление сессиями и доступом, перезапуски, наблюдение за ошибками, обслуживание сценариев и работа оператора.
Ставку и применимые правила расчёта берите из актуальной официальной страницы цен Gemini API. Не переносите тариф из старой статьи или другого продукта: цена, доступные режимы и правила учёта могут отличаться. В расчётной таблице сохраните ссылку на тариф и дату проверки. Если вы не можете подтвердить применимую ставку для выбранной модели и режима, оставьте поле незаполненным, пока не проверите источник, — не подставляйте условную цену.
Отдельно выясните, как в вашем случае учитываются токены и экранные изображения. В официальном описании учёта токенов указано, какие данные использования проверять; особенности обработки изображений рассматриваются в руководстве по пониманию изображений. Не считайте снимок экрана бесплатным вложением лишь потому, что в журнале вам проще заметить текст запроса. Учитывайте фактические данные, которые передаются в каждом цикле.
Рабочая формула для собственной оценки может выглядеть так:
Оценка выполнения = модельные расходы за все обращения + доля расходов на среду + стоимость повторов и наблюдения + стоимость ручной проверки и поддержки.
Заполняйте слагаемые по отдельности. Если среда тарифицируется по времени, распределяйте её стоимость с учётом фактической работы, а не только количества API-запросов. Если среда постоянно запущена для тестирования, запишите также время готовности и простоя: иначе расчёт покажет лишь активные действия и скроет расходы на ожидание.
Свяжите стоимость модели с циклом действий
Как скриншоты и повторы меняют расходы AI Agent? Они влияют на бюджет, когда приводят к дополнительным обращениям или передаче нового состояния экрана. Поэтому в тестах фиксируйте не только итоговый статус, но и число обращений, данные использования, количество обработанных состояний, повторы и вмешательства человека. Для тарифа сверяйтесь с официальной страницей цен, а фактические данные использования сопоставляйте с правилами учёта токенов.
| Что измерять | Как получить значение для расчёта | Почему нельзя заменить измерение предположением |
|---|---|---|
| Тариф и правила учёта | Проверить выбранную модель и режим на актуальной странице цен | Ставки и применимые правила могут меняться и различаться |
| Данные модели и изображений | Сохранять сведения об использовании для реальных запусков | Похожие текстовые инструкции могут сопровождаться разным экранным состоянием |
| Обращения в цикле | Считать вызовы API для каждого выполненного задания | Новое состояние интерфейса может потребовать дополнительного обращения |
| Повторы | Записывать причину каждой повторной попытки | Сбой исполнителя и неоднозначный ответ модели требуют разных исправлений |
| Среда и время работы | Фиксировать тип среды и время её использования | Счёт API сам по себе не показывает инфраструктурные расходы |
| Ручная проверка | Учитывать остановленные задачи и время оператора | Трудозатраты команды не отражаются в расходах на модель |
Для каждого запуска сохраняйте идентификатор теста, версию модели, параметры входа, результат и причину отказа или повтора. Сравнивайте стоимость одного завершённого сценария, а не только цену отдельного запроса. В журнале также полезно различать повтор действия в среде и полный повтор цикла с новой передачей состояния модели: у этих событий разные причины и последствия для бюджета.
Проверяйте, что используете актуальную запись модели, а не похожее название или устаревшую конфигурацию. В официальном списке моделей Gemini можно сверить сведения о моделях; тариф и допустимые режимы использования проверяйте отдельно. Эти проверки решают разные задачи: наличие модели в списке не заменяет проверку цены.
При росте параллельности могут возникнуть ограничения пропускной способности API, даже если среда ещё способна обслуживать новые задачи. Сверьте проектные ограничения с официальной документацией по лимитам запросов. Не планируйте параллельность выше подтверждённых лимитов. Кроме того, учитывайте, что ожидание в очереди не обязательно освобождает среду: сессия может оставаться активной, пока задача ждёт обращения к модели или оператора.
Снимки экрана и дополнительные циклы нужно оценивать на реальных примерах. Сценарий, в котором агенту достаточно прочитать страницу и выполнить одно действие, отличается от сценария с переходами, проверкой результата и возвратом после ошибки. Не закладывайте универсальный множитель на «сложность задачи»: сохраните выборку типичных сценариев, измерьте использование отдельно и подставляйте собственные значения в расчёт.
Выберите среду по целевому интерфейсу
Нужна ли полноценная настольная среда, если агент работает только в браузере? Не обязательно. Для ограниченных веб-сценариев сначала оцените браузер в изолированной среде. Вам всё равно придётся управлять сессиями, защищать учётные данные, контролировать доступ и разбирать сбои, но сам факт использования Computer Use не означает, что проекту нужен облачный Mac.
Решение меняется, когда объект тестирования выходит за пределы веб-страницы. Если агент должен взаимодействовать с нативным приложением macOS, проверять системное разрешение, работать в Safari или учитывать поведение системного окна, контейнер с браузером может не воспроизвести целевую среду. В таком случае Mac стоит включить в оценку, но это не делает его обязательной платформой для каждого агента.
| Среда | Когда её оценивать | Что придётся обслуживать | Ограничение |
|---|---|---|---|
| Изолированный браузер | Сценарии ограничены веб-страницами и управляемым профилем браузера | Версии браузера, очистку сессий, секреты и журналы | Не подтверждает работу нативных приложений macOS |
| Контейнер или виртуальная машина | Нужны раздельные тестовые среды и контролируемый запуск | Образы, обновления, лимиты ресурсов, сетевые правила и восстановление | Возможности интерфейса зависят от выбранной среды |
| Облачный Mac | Цель — macOS, Safari или системные действия | Учётные записи, разрешения, состояние сессии и изоляцию задач | Избыточен, если все сценарии ограничены браузером |
Преимущество браузерного варианта — более узкая область обслуживания и возможность начать без имитации всей операционной системы. Его недостаток — невозможность подтвердить поведение нативного интерфейса. Виртуальная машина помогает выделить тестовую среду, но команде придётся следить за её обновлениями и состоянием. Mac уместен именно тогда, когда этого требует целевой интерфейс; он не исправит ошибки сценария, нестабильность сайта или неверную обработку пользовательских данных.
До выбора инфраструктуры составьте перечень проверяемых интерфейсов. Отметьте, нужен ли конкретный браузер, нативное приложение, системное окно, локальный файл или подтверждение со стороны операционной системы. Затем проверьте, что исполнитель способен выполнить нужное действие и вернуть результат модели. Это помогает избежать лишних расходов на среду, которая не решит фактическую проблему.
Если вы пока определяете, какие услуги и варианты среды вообще подходят вашему сценарию, используйте обзор решений Macstripe как дополнительный ориентир, а не как замену технической проверке. Сначала сопоставьте требуемый интерфейс с возможностями исполнителя, затем решайте, нужна ли вам отдельная Mac-среда.
Учтите повторы, подтверждения и сопровождение
Повторная попытка — не одна универсальная статья расходов. Разделите причины: действие не выполнилось в среде; интерфейс изменился; модель получила недостаточно ясное состояние и предложила новое действие. Для каждой причины записывайте, что повторяется: команда исполнителя, получение нового состояния или весь цикл с дополнительным вызовом API.
Сбои входа и истёкшие сессии учитывайте отдельно. Когда сайт требует повторной авторизации, агент может остановиться, запросить помощь человека или продолжить в пределах заранее определённых правил. В расчёте опишите все исходы, которые возможны в вашем сценарии. Не считайте авторизацию постоянным свойством среды: доступность учётных данных, политика сервиса и срок действия сессии могут измениться.
Установите отдельное правило для действий с последствиями. Удаление данных, отправку формы и изменение настроек нельзя автоматически считать эквивалентом безвредного клика. Решите, при каких условиях выполнение приостанавливается до подтверждения, какой контекст получает оператор и как записывается его решение. Порядок взаимодействия клиента с моделью и вопросы безопасной реализации описаны в документации по Computer Use; требования к подтверждениям вы задаёте с учётом своего риска и процесса.
Не подставляйте в прогноз неподтверждённую «среднюю долю ошибок». Сначала запустите реальные сценарии, классифицируйте повторы и ручные остановки, а затем используйте наблюдения как основание оценки.
Ручная проверка требует не только времени специалиста. Команде нужно организовать очередь остановленных задач, назначить ответственного, передать оператору достаточный контекст и определить, как возобновить выполнение после решения. Если эти шаги выполняются вручную, занесите их в эксплуатационные расходы, даже когда они не видны в счёте API. Иначе стоимость может выглядеть небольшой, пока нагрузка на QA и поддержку не станет заметной.
При последующем пересчёте не смешивайте причины ошибок в один показатель. Отдельно анализируйте неудачный вход, изменение интерфейса, сбой исполнителя, неясное экранное состояние и необходимость подтверждения. После изменения модели, браузера, интерфейса или правил доступа обновите тестовую выборку: старые наблюдения могут уже не описывать новую конфигурацию.
Составьте оценку для разных режимов работы
Сценарии оценки — не готовые тарифные пакеты. Это разные наборы переменных. При редком эксперименте важны стоимость завершённого задания и настройка процесса. Для регрессионных проверок добавьте подготовку тестовых данных, повторяемость среды и обслуживание сценариев. При параллельной работе учитывайте одновременные сессии, разделение среды, пропускную способность и очередь ручных проверок.
| Режим оценки | Какие значения внести | Что проверить перед расширением |
|---|---|---|
| Редкий эксперимент | Использование модели, экранные данные, время работы среды и остановки | Стоимость одного завершённого сценария с настройкой и ручным контролем |
| Регрессионные проверки | Набор тестов, частоту изменений, причины повторов и обслуживание | Как меняются расходы при повторном запуске и сопровождении набора |
| Параллельные задачи | Одновременные сессии, лимиты API, занятость среды и очередь подтверждений | Где возникает ограничение: в API, исполнителе или доступности операторов |
Для каждого значения указывайте происхождение. Цену связывайте с актуальной официальной страницей и датой проверки. Использование модели подтверждайте журналом реального запуска. Время работы и обслуживания среды берите из данных вашей инфраструктуры. Трудозатраты на ручную проверку фиксируйте отдельно. Тогда измеренные значения не смешаются с предположениями, а пересчёт после изменения тарифа или сценария не потребует строить бюджет заново.
Перед масштабированием проверьте и цену, и пропускную способность: это разные ограничения. Если вы увеличиваете число исполнителей, убедитесь, что API допускает необходимый режим запросов, а среда не остаётся занятой в ожидании. В противном случае деньги будут расходоваться на резервирование среды без соответствующего роста числа завершённых задач. Запишите, какое ограничение вы проверили и по какому источнику.
Зафиксируйте критерии перехода к Mac
Прежде чем расширять бюджет или менять среду, проверьте модель на настоящих задачах. Отмечайте пункты только тогда, когда можете подтвердить их журналом, документацией или результатом теста.
- [ ] Я перечислил целевые интерфейсы и отделил браузерные действия от сценариев, требующих macOS, Safari или системных разрешений.
- [ ] Я проверил актуальный тариф выбранной модели в официальной документации и сохранил дату проверки.
- [ ] Я записываю данные использования, число обращений и состояние интерфейса для завершённых и незавершённых задач.
- [ ] Я разделяю повторы по причинам и не подставляю неподтверждённый общий показатель ошибок.
- [ ] Я учёл время работы и простоя среды, обслуживание, изоляцию сессий и обработку секретов.
- [ ] Я определил, какие действия требуют подтверждения человека и как учитывается время проверки.
- [ ] Я сверил необходимую параллельность с ограничениями API и возможностями исполнителя.
- [ ] Я проверил представительную выборку на целевом интерфейсе и сравнил успешные выполнения, отказы и восстановление после ошибок.
Когда облачный Mac нужен для тестирования Computer Use Agent? Рассматривайте его, если ваши реальные задачи требуют приложения macOS, Safari или системного взаимодействия, а текущая среда не воспроизводит эти условия. Сначала зафиксируйте, какие сценарии не покрывает браузерный вариант, как часто они запускаются и сколько ручной проверки требуют. Если нативные задачи пока составляют небольшую часть тестов или сам сценарий нестабилен, сначала исправьте исполнитель и проверьте выборку, а не переносите на Mac весь процесс без оценки.
Облачный Mac не нужен агенту, который работает только с веб-страницами в подходящей изолированной среде. Но замена целевой macOS браузерным контейнером оставляет непроверенными нативные приложения, системные разрешения и поведение Safari. С другой стороны, облачная среда не устранит ошибки логики и не сделает сайт стабильнее. Сопоставьте покрытие macOS, надёжность сценариев, требования к изоляции и нагрузку на обслуживание.
Если вам нужна Mac-среда только для проверки нативных сценариев или периодических прогонов, аренда у Macstripe может избавить от обслуживания собственной машины, которая простаивает между тестами. Перед выбором проверьте параметры и срок на странице выбора конфигурации Macstripe, а затем сравните их с вашими измерениями. При длительной непрерывной нагрузке или необходимости физического подключения к конкретному оборудованию собственная инфраструктура может оказаться подходящей альтернативой.
Заполните расчёт своими данными, отделите измеренные значения от предположений и повторите оценку после проверки текущего тарифа. Если ваши тесты действительно требуют macOS, переходите к сравнению облачного Mac с остальными вариантами; если нет, оставьте среду проще и направьте усилия на надёжность цикла, обработку ошибок и контроль доступа.
