Мы перевели продакшн-агента на GPT-5.6: в 2 раза быстрее, на 27% дешевле
Команда Ploy перевела своего рабочего AI-агента (строит маркетинговые сайты) с Claude Opus на новый GPT-5.6 Sol. Результат: скорость выросла в 2,2 раза, цена упала на 27%, качество осталось на уровне. Главная проблема — GPT-5.6 присылает ВСЕ параметры инструментов (25 из 25), даже выдуманные, что ломало чтение файлов в 52% случаев. Решили через переписывание схем: optional → required but nullable.
Первый публичный кейс миграции продакшн-агента на GPT-5.6 с цифрами, проблемами и фиксами. Если вы строите AI-агента с tool-calling, вы столкнётесь с теми же граблями — и теперь знаете, как их обойти.
Как мы мигрировали продакшн-агента на GPT-5.6
Команда Ploy (строит маркетинговые сайты через AI) четыре месяца держала в основе своего агента Claude Opus — ни одна новая модель не проходила их бар качества. Пока не вышел GPT-5.6 Sol.
Результаты миграции
После head-to-head тестов цифры оказались убедительными: - Скорость: в 2,2 раза быстрее - Цена: -27% - Объём кода: в два раза меньше токенов вывода, вдвое компактнее CSS (2,5K символов вместо 18K у Opus, 45 CSS-переменных вместо 174) - Качество: на уровне или выше Opus
Но переход оказался нетривиальным.
Проблема № 1: модель заполняет ВСЁ
Их code-инструмент принимает 25 параметров, из них обязателен только action. Claude присылал 2–3 нужных и опускал остальные. GPT-5.6 присылает все 25, забивая неиспользуемые выдуманными значениями вроде offset: 0, timeout: 120000, siteId: "00000000-...".
Тул не мог отличить настоящий offset: 0 от придуманного → 52–64% чтений файлов возвращали пустоту. При этом API отвечал success: true, модель не понимала, что читает пустоту, и делала больше вызовов.
Промпты не помогли. Директива «omit unused parameters» всё равно давала 25 из 25. Strict mode OpenAI ничего не изменил.
Решение: переписать схемы. Для OpenAI optional-поля превращаются в required but nullable через anyOf: [T, null]. Модель видит явный способ сказать «не используется» (null), null'ы зачищаются перед вызовом тула. Пустые чтения упали с 52% до 0%, вызовов стало на ~30% меньше.
Проблема № 2: параллельные вызовы
Opus делал последовательные вызовы инструментов, GPT-5.6 — параллельные. Их бюджеты инструментов не выдерживали (и это было ложными отказами). Треть первых фейлов пришлась на допущения eval-харнеса, а не на поведение модели.
Проблема № 3: стиль по умолчанию
GPT-5.6 тяготеет к «чистым, строго сеточным» лейаутам. Без сильного steering он игнорировал существующие дизайн-системы → выдавал generic, хоть и аккуратные страницы. Команда Ploy доработала промпты до нужного уровня brand-adherence.
Что ещё различается
- Prompt caching: у провайдеров разная логика
- Reasoning replay: разные способы воспроизведения цепочек между раундами
Вывод: GPT-5.6 Sol — первая модель за четыре месяца, которая превзошла Opus по их метрикам. Но провайдеры сильно отличаются на уровне tool-calling, кеширования, стиля генерации. Если вы пилите продакшн-агента — готовьтесь переписывать не только промпты, но и схемы инструментов, eval-харнессы и steering.
Ключевые выводы
- GPT-5.6 Sol — первая модель за 4 месяца, обогнавшая Claude Opus по метрикам production-агента Ploy (скорость +2.2x, цена -27%, качество ≥)
- GPT-5.6 присылает ВСЕ параметры tool-вызовов, включая выдуманные значения → 52% чтений файлов были пустыми из-за невозможности отличить реальный offset:0 от придуманного
- Промпты ('omit unused parameters') и strict mode не решили проблему; рабочий фикс — переписать схемы: optional → required but nullable (anyOf:[T, null]), зачистка null'ов перед вызовом
- Треть первых отказов в eval'ах — не модель, а допущения харнеса (параллельные вызовы, батчевые чтения) → надо триажить трейсы, а не слепо верить pass rate
- GPT-5.6 пишет вдвое меньше кода (2.5K vs 18K CSS), но по умолчанию тяготеет к generic-дизайну → требует сильного steering для brand-adherence
Автор: Артём Ковалёв · Источник: hnrss.org
**Наконец-то живой production-кейс с цифрами, а не маркетинговый флафф.** Ploy четыре месяца держали Opus, потому что ничто не проходило их бар — и вот GPT-5.6 прошёл. В два раза быстрее, на четверть дешевле, вдвое компактнее код. Но дьявол в деталях.
Самая жесть — GPT-5.6 заполняет *все* поля инструментов, даже если они optional. Claude присылал 2–3 нужных, GPT — все 25, придумывая значения. Из-за этого половина чтений файлов была пустой, модель не понимала, что читает пустоту, и делала больше вызовов. Промпты не помогли, strict mode — тоже. Помогло только переписывание схем: optional превратили в required-but-nullable, модель теперь присылает null вместо выдумки. После этого пустые чтения упали до нуля.
Второй момент: eval'ы врут, если не триажить трейсы. Треть их первых фейлов — это не модель плохая, а харнес заточен под стиль Opus (последовательные вызовы вместо параллельных, игнорирование батчевых чтений). Если тестируете новую модель против старой, смотрите логи — иначе eval будет наказывать за «непохожесть», а не за реальные косяки.
Третье: GPT-5.6 генерирует чистые, сеточные лейауты по умолчанию. Без сильного steering игнорирует дизайн-систему и выдаёт generic. Opus был более «послушным» в этом смысле. Команда Ploy допилила промпты, но это отдельная работа.
**Практический вывод**: если строите агента с tool-calling, готовьтесь переписывать не только промпты, но и схемы инструментов, харнессы, steering. Провайдеры отличаются не на уровне «чуть лучше текст», а на уровне архитектурных допущений. И это нормально — просто надо знать заранее.
Комментарии