GPT-5.4 в Codex: модель общего назначения становится coding agent
Почему объединение reasoning, coding, Tool Search и computer use меняет роль специализированных моделей и agent harness.

Одна модель вместо двух привычных ролей

5 марта 2026 года OpenAI выпустила GPT‑5.4 в ChatGPT, API и Codex. Формально это обновление основной линейки GPT. Для разработки интереснее другое: впервые mainline reasoning-модель получила coding-возможности GPT‑5.3‑Codex и одновременно сохранила более широкий профиль — работу с документами, вебом, программными средами и инструментами.

В официальной документации GPT‑5.4 модель описана как frontier-модель для сложной профессиональной работы. Там же перечислены hosted shell, Apply Patch, Skills, computer use, MCP и Tool Search. То есть перед нами не «чат-модель, которая научилась писать функции», а основание для многошагового agentic workflow.

раньше
general model   |   coding model

теперь
reasoning + coding + tools + execution
                    ↓
              frontier model

Отсюда возникает неудобный для прежней классификации вопрос: нужна ли coding agent отдельная специализированная модель для программирования, если основная модель уже умеет исследовать проект, менять код и пользоваться окружением?

Почему coding-модели вообще стали отдельным классом

Работа с репозиторием плохо помещается в формат «вопрос — ответ». Агенту нужно найти точки входа, проследить flow через несколько слоёв, изменить связанные файлы, запустить команды и пересмотреть решение после ошибки. На длинной задаче он ещё должен помнить исходную цель после десятка промежуточных действий.

Поэтому специализированная модель была логичным выбором. GPT‑5.3‑Codex официально позиционируется как модель, оптимизированная для agentic coding в Codex и похожих средах. Её естественная территория — repository, terminal, implementation и tests.

ChatGPT / general model
вопросы → исследование → объяснение

Codex / coding model
repository → terminal → code → tests

GPT‑5.3‑Codex увеличила единицу делегирования от класса или файла до инженерной задачи. GPT‑5.4 делает следующий ход: переносит эту способность в основную модель вместо того, чтобы оставлять её отдельной специализацией.

Coding становится базовой способностью

Для меня это главный смысл релиза. Программирование постепенно переезжает из отдельной ветки каталога моделей в набор базовых возможностей frontier-модели — рядом с reasoning, vision и tool use.

Такой переход соответствует реальной инженерной работе. Интеграция нового платёжного провайдера начинается не с написания PHP-класса. Сначала нужно прочитать документацию API, найти существующие payment adapters, понять правила idempotency, проверить обработку webhook и выяснить, где хранятся credentials. Затем появляются код, конфигурация, тесты и проверка приложения.

документация → архитектура → код → terminal
       → тесты → приложение → проверка

Модель, сильная только в генерации кода, видит один участок этого маршрута. General-purpose модель потенциально способна пройти весь путь без смены исполнителя и потери накопленного контекста.

Центр тяжести смещается к инструментам

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

Набор инструментов GPT‑5.4 в Responses API хорошо показывает новый масштаб: web search и file search соседствуют с code interpreter, shell, Apply Patch, computer use, MCP и Tool Search. Последний особенно полезен в средах с большим каталогом возможностей: агент может подгружать релевантную часть набора, а не держать описания всех интеграций в каждом запросе.

решить, что узнать
        ↓
выбрать инструмент
        ↓
выполнить действие
        ↓
интерпретировать результат
        ↓
скорректировать следующий шаг

Здесь code generation становится одним действием внутри loop. Качество агента всё чаще определяется tool orchestration: насколько аккуратно модель получает evidence и меняет решение после наблюдения.

Computer use выводит агента за пределы репозитория

GPT‑5.4 поддерживает computer use: модель может работать с программным интерфейсом через визуальное состояние, мышь и клавиатуру. Для coding agent это означает доступ к ещё одному feedback loop.

Например, агент меняет форму в Filament, запускает Laravel, открывает admin panel, создаёт запись и видит, что modal закрывается без success notification. PHPUnit может быть зелёным, а статический анализ — чистым. Проблема обнаруживается только при использовании приложения.

edit → test → run application
  ↑                 ↓
  └── fix ← observe UI

Computer Use в Cursor Cloud Agents уже показал тот же сдвиг на уровне продукта: агенту мало вернуть diff, он должен проверить outcome и приложить evidence. GPT‑5.4 переносит подход в general-purpose модель, которую можно использовать внутри разных agent environments.

Миллион токенов — возможность с отдельной ценой

Документация API указывает для GPT‑5.4 контекстное окно 1,05 млн токенов и до 128 тысяч токенов ответа. Для длинной инженерной задачи это полезный запас: в контексте одновременно живут project instructions, код, результаты поиска, terminal output, документация и история принятых решений.

Но большое окно не отменяет context engineering. Если загрузить в него весь repository, повторяющиеся логи и устаревшие инструкции, агент получит больше шума, а не больше понимания. Есть и буквальная стоимость: API-запросы свыше 272 тысяч входных токенов тарифицируют весь сеанс по повышенному коэффициенту — вход вдвое, выход в полтора раза.

Специализированная coding-модель всё ещё имеет смысл

Из GPT‑5.4 не следует, что Codex-модели стали ненужными. Специализация может давать меньшую latency, другую стоимость, более предсказуемое поведение в repository или оптимизацию под конкретный execution loop. Отдельная модель особенно логична для коротких правок, high-volume review и интерактивной работы, где глубина общего reasoning не окупает задержку.

Поэтому я бы не заменял один старый универсальный ответ новым. Раньше таким ответом было «для кода всегда нужна coding model». Теперь им легко сделать «general model умеет всё». Практический выбор всё равно зависит от горизонта, неопределённости, риска и цены итерации.

• локальный предсказуемый patch может выиграть от быстрой специализированной модели;
• исследование с документацией, UI и несколькими внешними системами лучше соответствует general-purpose модели;
• рискованная задача может использовать одну модель для реализации и другую для независимого review.

То есть model routing никуда не исчезает. Наоборот, модель общего назначения добавляет router ещё один осмысленный вариант.

GPT‑5.4 не равна Codex

Самое полезное различие в этой теме — между моделью и агентом. GPT‑5.4 принимает решения. Codex предоставляет repository, инструкции, shell, worktree, permissions, execution loop и интерфейс контроля.

GPT‑5.4
   + project context
   + tools
   + sandbox
   + permissions
   + execution loop
   + verification
   = coding agent

Если модель правильно решит запустить feature-тест, но environment не умеет поднять PostgreSQL, работа остановится. Если shell доступен без разумных ограничений, автономность создаст риск. Если harness не возвращает модели результат команды, не получится исправить failure.

По мере универсализации frontier-моделей именно harness сильнее влияет на пользовательский результат. Мы уже видели это при сравнении Claude Code и Codex: впечатление «модель лучше понимает проект» часто означает, что продукт лучше собрал контекст или настойчивее прошёл test loop.

Как это выглядит в Laravel-проекте

Представим задачу: добавить повторную отправку неуспешных email через существующую очередь. Для неё нужно исследовать Jobs и Events, сверить настройки Redis, проверить retry policy Laravel, изменить код, запустить PHPUnit, поднять worker и наблюдать фактический статус job.

General-purpose модель удобна здесь тем, что задача пересекает несколько режимов работы:

1. прочитать project rules и найти текущий notification flow;
2. свериться с документацией Laravel для используемой версии;
3. предложить минимальное изменение без новой зависимости;
4. внести patch и запустить тесты внутри контейнера;
5. проверить worker, failed jobs и application logs;
6. сопоставить результат с Definition of Done.

Но завершённость всё равно создаёт не название модели. Её создают доступ к нужным инструментам, точные project instructions, изолированная среда и заранее определённая проверка.

Сравнивать стоит способность выполнить работу

После GPT‑5.4 вопрос «какая модель лучше пишет PHP» становится ещё менее полезным. Для локальной функции он годится. Для задачи уровня проекта нужно измерять весь маршрут.

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

Это benchmark агентной системы, а не одной LLM. Чем ближе модели по coding capability, тем заметнее различия в search, context management, permissions и verification.

Главный сдвиг — не новая модель, а новая граница

GPT‑5.4 интересна тем, что OpenAI перестала жёстко разводить general reasoning и agentic coding. Основная frontier-модель получила coding, shell, Apply Patch, computer use, MCP, Tool Search и длинный контекст в одном контуре.

Специализированные coding-модели от этого не исчезают. Они превращаются из обязательного класса в один из вариантов исполнения — рядом с general-purpose моделями разной стоимости и скорости.

А главный вопрос перемещается уровнем выше. Не «умеет ли модель написать этот класс?», а «может ли система исследовать задачу, выбрать инструменты, реализовать решение, проверить outcome и вернуться с доказательствами?»

GPT‑5.4 стирает границу между общей и coding-моделью. Граница между моделью и надёжным coding agent, напротив, становится только заметнее.