GPT-6 Astra восстанавливает Electron-приложение: результаты и расходы через OpenAI, OpenRouter и TeamoRouter

В предыдущей статье я сравнивал SVG с пеликаном и фламинго, полученные через несколько API-сервисов. В комментариях заметили, что одна картинка — слишком простая задача для проверки того, какая модель работает за сторонним API. В комментариях предположили, что на задачах минут на пятнадцать, с большим контекстом, посредник может подменять модель, а результат от этого становится хуже. На этот раз я выбрал задачу с последовательным чтением файлов, написанием кода и запуском тестов: разобрать дистрибутив Pomotroid, заново реализовать настольный помодоро-таймер, а затем добавить импорт и экспорт состояния. Для сравнения с официальным API OpenAI взял два известных сервиса — OpenRouter и TeamoRouter.

Что показал предыдущий тест

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

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

Почему именно настольный помодоро-таймер

В качестве исходного приложения я выбрал Pomotroid v0.13.0. Он написан на Electron: интерфейс на HTML, CSS и JavaScript работает как настольное приложение благодаря Chromium и Node.js. Код, который предстояло разобрать, находится в архиве app.asar внутри дистрибутива.

Помодоро-таймер кажется простым, но его логика не сводится к вычитанию единицы каждую секунду. Останавливается ли отсчёт на паузе? Меняется ли номер цикла при сбросе? Когда включается короткий перерыв, а когда длинный? Сохраняются ли настройки? Всё это можно проверить. Такая задача лучше, чем просьба нарисовать красивую страницу, показывает, согласованы ли код и переходы между состояниями.

Эксперимент 1. Разобрать дистрибутив и восстановить основные функции

Код, приложение и автоматические проверки запускались в изолированном Linux-окружении в Docker. На вход подавался дистрибутив для Windows, а восстановленное приложение работало под Linux.

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

You are reconstructing a small desktop timer from the supplied Pomotroid v0.13.0 release artifact. Work only in the provided isolated workspace. You have the supplied local tools, starter project, and dependencies. Do not use the internet, upstream source repositories, prior-run outputs, or any evaluator files. Analyze the shipped JavaScript application; this is not a native machine-code decompilation task.

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

Во всех трёх случаях использовался Responses API с параметром reasoning_effort, установленным в high, без потоковой передачи и автоматических повторов HTTP-запросов. В OpenAI и TeamoRouter запрашивалась модель gpt-6-astra, в OpenRouter — openai/gpt-6-astra.

Второе задание выдавалось только после отметки о завершении базовой версии и получения скриншота запущенного приложения. Через официальный API эта точка была достигнута за 6 мин 23,1 с, через OpenRouter — за 6 мин 49,1 с, через TeamoRouter — за 8 мин 46,6 с.

Эксперимент 2. Добавить импорт и экспорт состояния

На втором этапе работа продолжалась с уже написанным кодом, без перезапуска с нуля. Нужно было добавить доступный из интерфейса импорт и экспорт JSON. Ещё один фрагмент исходного задания:

Add a user-accessible JSON export/import feature for the timer state. This is an extension requested for the benchmark, not a claim about a feature in Pomotroid v0.13.0.

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

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

Результат у всех трёх — 9 пройденных проверок, 70/70. Из них 40 баллов приходятся на базовую логику таймера, 10 — на сохранение настроек, 20 — на импорт и экспорт. Ещё 30 баллов отведены под ручную оценку, которая пока не выставлена, поэтому результат здесь не 100/100.

Ниже — скриншоты трёх готовых приложений после запуска. Пропорции изображений сохранены.

Рис. 1. Официальный API OpenAI. Слева таймер, справа настройки, сверху — кнопка Export / Import. Результат автоматических проверок — 70/70.

Рис. 2. TeamoRouter. Слева таймер, справа постоянно видимая панель настроек, под таймером — кнопка запуска и значки сброса и перехода к следующему этапу.

Рис. 3. OpenRouter. Таймер и настройки расположены рядом, сверху — кнопка Export / Import. Результат автоматических проверок — 70/70.

Результаты, время и фактические расходы

В таблице указано полное время от начала задания до сдачи результата, включая ожидание ответов модели и выполнение инструментов. На три запуска пришлось соответственно 29, 33 и 27 API-запросов. Все завершились с HTTP 200; автоматических повторов не было, вручную код по ходу работы никто не правил.

Таблица 1. Три завершённых запуска одной задачи. Расходы указаны в долларах США.

По числу API-запросов, вызовов инструментов, выходных токенов и итоговой стоимости OpenRouter оказался ближе к официальному API OpenAI. На мой взгляд, это даёт основания предполагать, что он использовал ту же модель. TeamoRouter израсходовал больше токенов, чем OpenRouter, и сделал больше API-запросов и вызовов инструментов.

У TeamoRouter сумма списаний за 33 запроса составила $1.67290892, у OpenRouter за 27 запросов — $5.710904. В кабинете OpenAI для выделенного ключа указано $5.82 за все 29 запросов.

TeamoRouter обошёлся примерно на $4.15 дешевле официального API и на $4.04 дешевле OpenRouter. При этом он потратил на 4 мин 13,0 с больше, чем официальный API, и на 3 мин 57,4 с больше, чем OpenRouter. В этом запуске более низкий тариф компенсировал дополнительный расход токенов, хотя времени потребовалось больше.

В задаче восстановления помодоро-таймера OpenRouter оказался ближе к официальному API по показателям выполнения, а преимущество TeamoRouter заметнее в стоимости. Если в повседневной разработке важнее общая цена такой задачи, TeamoRouter имеет смысл попробовать. Если важнее быстрее получить результат и потратить меньше токенов, в этом сравнении лучше показали себя официальный API и OpenRouter.

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