Перенос продакшен-агента ИИ на GPT-5.6: в 2,2 раза быстрее и на 27% дешевле

Ploy делает продукт для автоматической сборки маркетинговых сайтов: агент планирует страницу, читает кодовую базу, пишет компоненты, генерирует изображения, делает скриншоты своей же работы и сам решает, когда закончить. Четыре месяца подряд (сначала на Opus 4.7, затем на Opus 4.8) команда тестировала против этого агента каждую новую флагманскую модель, и ни одна не превосходила Claude Opus. Вышедшая "сегодня утром" (по времени публикации поста) модель GPT-5.6 Sol от OpenAI стала первой, кто обошёл действующего чемпиона: в тестах она заканчивала сборку страницы более чем вдвое быстрее по времени (2,2×), обходилась на 27% дешевле и тратила примерно вдвое меньше токенов на вывод, при этом набирая не меньше баллов по качеству готовой работы.

Перед тем как поверить этим числам, команде пришлось чинить сам тестовый набор: бюджеты вызовов инструментов были откалиброваны под последовательный стиль Opus, а GPT-5.6 запускает вызовы параллельными пачками и упирался в лимиты даже там, где решал задачу правильно; исполнитель тестов не поддерживал пакетное чтение файлов, которым Opus почти не пользовался, а GPT-5.6, постоянно. Отдельно нашёлся набор тестов, где не был явно задан порог minScore и он молча наследовал значение по умолчанию 1.0, из-за этого GPT-5.6 "проваливал" случай с оценкой 0.98, а Opus проваливал случай, реально пройдя все отдельные проверки. Около трети сырых провалов в первом межмодельном прогоне объяснялись именно перекосом тестового харнесса, а не поведением модели.

По дизайну: на одной из парных задач Opus сгенерировал файл стилей globals.css на 17 957 символов со 174 CSS-переменными (в основном неиспользуемыми полными цветовыми шкалами), тогда как GPT-5.6 обошёлся 2508 символами и 45 переменными при сопоставимом (местами даже лучшем) итоговом виде страницы. Общее впечатление команды: GPT-5.6 отлично делает чистые, современные, чётко выстроенные по сетке макеты, но без явного управления скатывается к одному и тому же строгому, слегка безликому стилю, игнорируя уже заданную дизайн-систему.

Самая коварная проблема вскрылась на уровне вызовов инструментов. У инструмента для работы с кодом 25 параметров верхнего уровня, из которых обязателен только один (action). Claude присылает лишь два-три реально нужных параметра, остальные не указывает. GPT-5.6 присылает все 25 при каждом вызове, выдумывая правдоподобные значения для неиспользуемых полей: offset: 0, timeout: 120000, siteId в виде нулевого UUID. Проблема не в многословности, а в том, что выдуманное значение неотличимо от осмысленного: реализация чтения файла восприняла offset: 0 как настоящий параметр, из-за чего от 52% до 64% чтений файлов GPT-5.6 возвращали пустой результат, при этом инструмент всё равно рапортовал success: true, и модель не понимала, что читает пустоту. Ни изменение текста подсказки в схеме ("опускай неиспользуемые параметры"), ни явные пометки "OPTIONAL" по каждому полю, ни строгий режим OpenAI (strict mode) поведение не изменили, это оказалось особенностью того, как модель формирует вызовы функций на уровне архитектуры, а не что-то, что лечится промптом. Рабочим решением стала трансформация схемы на границе с провайдером: для моделей семейства OpenAI необязательные поля переписываются как обязательные, но допускающие null (через anyOf: [T, null]), так у модели появляется явный способ сказать "не использую это поле"; перед тем как вызов доходит до самого инструмента, null-значения вычищаются обратно, и код инструментов не меняется вовсе. После правки доля пустых чтений файлов упала с 52% до 0%, а число вызовов инструментов на ту же работу сократилось примерно на 30%, модель перестала перечитывать файлы, вернувшиеся пустыми.

Вторая крупная переделка, кеширование промптов. У агента Ploy есть статический префикс промпта примерно на 29 тысяч токенов (схемы инструментов плюс системный промпт), одинаковый для любого диалога. У Anthropic точки кеша задаются через cache_control, и такой префикс кешируется на уровне всей организации: любой диалог, любое рабочее пространство используют одну общую запись кеша без ограничений по пропускной способности, доля попаданий в кеш держится на уровне 92-96%. GPT-5.6 поменял модель кеширования OpenAI: раньше неявное кеширование ловило частичные совпадения префикса, теперь, только записи на весь промпт целиком, привязанные к последнему сообщению. Новый диалог, разделяющий общий 29-тысячный префикс, кешировался на 0%: каждый диалог заново оплачивал весь префикс по некешированной ставке, а на GPT-5.6 любой некешированный запрос вдобавок несёт надбавку за запись в кеш в 1,25 раза. Явный механизм кеширования требует маркеров prompt_cache_breakpoint и обязательного ключа prompt_cache_key, который сам становится частью идентичности записи кеша: один и тот же промпт с разными ключами даёт ноль попаданий, а каждый ключ привязан к узлу кеша, который выдерживает около 15 запросов в минуту, после чего трафик уходит на другие, "холодные" узлы. Команда перебрала варианты: ключ на каждый диалог даёт 0% попаданий на первом вызове; один общий ключ на всех быстро упирается в лимит 15 запросов в минуту и тоже уходит в холодные узлы; ключ на уровне рабочего пространства клиента оказался золотой серединой. Промпт разбили на слои с точками кеша: запись A (инструменты плюс статический префикс) общая для всех сессий, запись B добавляет контекст рабочего пространства и обновляется только при его изменении (не требуя перезаписи всех 29 тысяч токенов), запись C, это цепочка конкретного диалога. Межпространственное использование статического префикса на OpenAI архитектурно невозможно (в отличие от общеорганизационного кеша Anthropic без разбивки по ключам): каждое рабочее пространство платит за одну холодную перезапись 29 тысяч токенов на окно простоя, около $0,18. После перестройки доля попаданий в кеш на первом вызове выросла примерно с 0% до 83,7%, объём некешированных входных токенов упал на 28%, а стоимость прогона тестов на GPT-5.6 в итоге оказалась ниже, чем на Opus, вся разница в цене, которая раньше казалась свойством модели, объяснялась неправильной настройкой кеша.

Третья и последняя правка касалась воспроизведения цепочки рассуждений. Responses API GPT-5.6 по умолчанию хранит рассуждения предыдущих шагов на стороне сервера и ссылается на них по идентификатору; из-за этого в реальных диалогах стали изредка возникать сбои с ошибкой вида "Item 'rs_...' not found". Решение, параметр store: false: он заставляет SDK запрашивать зашифрованное содержимое рассуждений и воспроизводить его самостоятельным блоком, а не ссылкой на состояние сервера. Отдельный вывод команды: пока рассуждения хранятся на стороне сервера, эффективный промпт может незаметно меняться выше по цепочке, даже если байты, которые отправляет клиент, строго дописываются в конец и не меняются.

По итогам всех правок GPT-5.6 Sol стал моделью по умолчанию во всех рабочих пространствах Ploy; попробовать сборку сайта можно бесплатно на ploy.ai.

Ключевые факты

Ploy перевела продакшен-агента для сборки сайтов с Claude Opus 4.8 на GPT-5.6 Sol: сборка страницы стала быстрее в 2,2 раза, дешевле на 27%, при вдвое меньшем расходе токенов на вывод.
Треть сырых провалов в межмодельных тестах объяснялась перекосом самого тестового харнесса (лимиты вызовов и пороги оценки, подогнанные под Opus), а не реальным поведением GPT-5.6.
GPT-5.6 заполнял все 25 параметров инструмента выдуманными значениями (например offset: 0), из-за чего 52-64% чтений файлов молча возвращали пустоту; помогла только трансформация схемы на границе с провайдером, а не правки в тексте промпта.
Смена модели кеширования у OpenAI (переход на явные ключи prompt_cache_key вместо частичного совпадения префикса) сначала обнулила попадания в кеш; ключ на уровне рабочего пространства поднял долю попаданий до 83,7% и убрал всю кажущуюся разницу в цене между моделями.
Серверное хранение цепочки рассуждений в Responses API вызывало случайные сбои диалогов; фикс, флаг store: false, переводящий рассуждения в самодостаточные зашифрованные блоки на стороне клиента.

Почему это важно

Кейс показывает, что даже при использовании универсального SDK (Vercel AI SDK) переход между провайдерами моделей, это не замена одной строчки конфигурации. То, что команда привыкла считать "поведением модели", на деле оказалось набором специфичных для провайдера особенностей: как модель заполняет необязательные параметры инструментов, как работает кеш промпта, как воспроизводятся её собственные рассуждения между ходами диалога. Заявленные цифры (2,2× и минус 27% к цене) стали достижимы только после того, как все эти слои были переосмыслены под новую модель.

Кому это важно

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

Как это применить

Прежде чем доверять сравнительным оценкам двух моделей, разберите провалившиеся случаи по трассам вызовов, а не по итоговому баллу, тестовый харнесс почти всегда незаметно подогнан под модель, на которой он разрабатывался. Проверьте, как новая модель заполняет необязательные поля в схемах ваших инструментов: для моделей OpenAI может понадобиться сделать поля обязательными, но допускающими null (anyOf: [T, null]), и вычищать null перед выполнением вызова. Пересобирайте стратегию кеширования промпта отдельно под каждого провайдера: у Anthropic кеш общеорганизационный без разбивки по ключам, у OpenAI кеш привязан к prompt_cache_key и узлам с лимитом около 15 запросов в минуту, ключ на уровне рабочего пространства клиента обычно работает лучше, чем ключ на диалог или один общий ключ. При переходе на Responses API GPT-5.6 задавайте store: false, чтобы не зависеть от серверного состояния рассуждений между ходами.

Можно ли доверять

Материал, это блог самой Ploy, компании, продающей продукт на основе этого агента, поэтому цифры (2,2×, 27%, 83,7% попаданий в кеш), это внутренние, не проверенные независимо результаты собственного тестового набора компании, а не сторонний бенчмарк. Вместе с тем в посте много конкретных технических деталей, код трансформации схемы, точные проценты пустых чтений файлов, устройство узлов кеша с лимитом запросов в минуту, что говорит скорее о честном инженерном разборе, чем о чистом маркетинге; тем не менее выводы о превосходстве GPT-5.6 над Opus стоит воспринимать именно как заявление вендора, заинтересованного в этом результате.

Риски и подводные камни

Главный риск, слепо доверять межмодельным оценкам: невидимый порог оценки (minScore по умолчанию 1.0) и лимиты вызовов, откалиброванные под старую модель, искажали результаты далеко не в одну сторону. Ещё один риск, выдуманные значения параметров инструментов, неотличимые от настоящих: тул-код возвращал success: true даже при пустом чтении файла, и без ручной трассировки проблему было не заметить. Наивная стратегия кеширования (общий или per-диалог ключ) способна незаметно обнулить весь эффект от кеша и создать иллюзию, что новая модель дороже, хотя дело в конфигурации. Наконец, серверное хранение цепочки рассуждений означает, что эффективный промпт может меняться выше по цепочке независимо от клиента, даже когда отправляемые байты строго дописываются в конец диалога.

«Если вы сравниваете модели по стоимости, а у одной из них холодный кеш, вы сравниваете не модели, а свои настройки.»

— блог Ploy (ploy.ai)