OpenAI продаёт /goal как «агент работает над целью часами автономно». Первое, что замечаешь на практике — счётчик токенов скачет непредсказуемо. Не в два раза. В три-пять. И ты не знаешь заранее, какой будет цена.
Codex CLI 0.128.0 вышел 30 апреля 2026. Главная фича — /goal, OpenAI’ская реализация Ralph loop. Параллельно поехали /side, активные /title и /statusline, codex update, deprecation --full-auto. За неделю до этого, 23 апреля, в Codex стала доступна GPT-5.5. И эта связка /goal + GPT-5.5 — то, что меняет работу с агентом сильнее, чем кажется по чейнджлогу.
Тестировал эту связку. Команда — тоже. И вот что мы поняли.
Что приехало вместе с 0.128.0
Если коротко, релиз не про одну фичу — он про сдвиг. Раньше Codex был «умный собеседник, который пишет код по задаче». Теперь — «процесс, который держит цель и долбит её, пока не упрётся в бюджет».
Конкретно:
/goal— persistent цель уровня треда. Агент сам пишет код, тестирует, рефлексирует, продолжает./side— эфемерный side-thread, не сбивающий основную цель./titleи/statusline— теперь редактируются на ходу, в активной сессии. Раньше только до запуска или после рестарта.codex update— наконец-то нативный self-update вместо ручной переустановки через npm/brew.--full-autodeprecated — теперь explicit permission profiles. Это важно, об этом ниже.
И GPT-5.5 как рекомендуемая модель. Без неё /goal не раскрывается — на старых моделях слишком много циклов для достижения той же цели.
Документации на /goal пока нет. Issue #20536 от 1 мая просит её добавить — справедливо, потому что фича в чейнджлог попала, а в slash commands reference её ещё не упомянули.
Что такое /goal под капотом
Внутри это state machine на уровне треда с пятью слоями. Это видно по PR #18073-18077.
Слой | Что делает |
|---|---|
Persistence | Хранит цель, статус ( |
App-Server API v2 | RPC |
Model tools | Модель может смотреть статус и помечать цель достигнутой. Не может — паузить, резюмить, сбрасывать |
Runtime | Continuation turns только когда сессия idle. User input приоритетнее |
TUI | Индикаторы статуса, elapsed time, бюджет токенов |
Слой Model tools — важный. Он гарантирует, что только пользователь управляет жизненным циклом цели. Модель не может сама решить «всё, я устала, ставлю на паузу» или «я считаю, что готово, очищаю цель». Только вы — через TUI.
А что заставляет модель долбить цель ход за ходом? Системный промпт. На каждом continuation turn Codex инжектит два файла-шаблона:
goals/continuation.md— фокус на цели и ключевая установка: «do not accept proxy signals and treat uncertainty as not achieved».goals/budget_limit.md— soft-stop при упирании в бюджет. Не падение — указание агенту завернуть работу: подготовить саммари, что сделано и что осталось.
Эту вторую часть оценил отдельно. Когда у тебя цель, рассчитанная на четыре часа, а агент упёрся в лимит на втором — не получаешь обрывок. Получаешь финальное состояние с пометкой «вот тут остановился, вот что не доделал». Можно резюмить и продолжить, не теряя контекст.
«Do not accept proxy signals» — это про то, что агент не должен отчитываться об успехе по косвенным признакам. Тесты прошли — это не значит цель достигнута. Файл записан — не значит работа сделана. Метрика улучшилась — не значит улучшилась так, как нужно. Конкретно: вы ставите цель «улучшить P95 latency на 20%». Агент написал кэш, тесты позеленели, но реальная метрика на проде упала на 5%. Без proxy-signal-инструкции агент закроет цель как achieved. С ней — продолжит.
В теории.
На практике агент всё равно иногда обманывается. Об этом дальше.
Включается через feature flag
Фича пока Experimental. Чтобы заработала — нужно явно включить:
codex features enable goals
Это пишет в ~/.codex/config.toml:
[features] goals = true
Альтернативы — codex --enable goals для разового запуска или ручная правка config.toml. Команда codex features list покажет все флаги, их maturity (Experimental/Beta/Stable) и состояние.
Запуск выглядит так:
/goal Implement Filament design in chat. Done = automated tests pass and dashboard text visible in sidebar.
Подкоманды:
/goal pause— пауза. Текущий ход дорабатывает./goal resume(или/goal unpause) — продолжить./goal clear— снять цель./goalбез аргументов — статус: время, токены, состояние.
Что показал реальный кейс
Лучший публичный пример, на который наткнулся — твит @NicolasZu от первого мая. Он гонял /goal для оптимизации производительности своей игры.
Запуск: один час, GPT-5.5 xhigh. Результат: +25% fps. npm run perf:guard прошёл с average improvement 25.7%.
Что агент сделал за этот час:
Урезал hot-path аллокации на движении и коллизиях зомби, выкинул неиспользуемое обслуживание separation-bucket.
Закэшировал статические метаданные WASM для конвейерной механики, убрал избыточные per-tick копии WASM.
Переиспользовал scratch-объекты для timing/accumulator боевой механики башен, сократил аллокации aim/targetability.
Добавил быстрые helper-функции для terrain/turret-center в hot paths.
Изменены файлы src/game/logistics/beltWasm.ts, src/game/zombies/crowdNavigation.ts, src/game/zombies/turretCombat.ts, src/game/zombies/turretAim.ts. Verification — npm run perf:guard passed.
Это один публичный кейс, не репрезентативная выборка — но он показывает сценарий, под который /goal спроектирован. Цель измеряется автоматически (perf-метрика), окружение даёт обратную связь (perf-guard), агент циклически итерирует. Час работы, конкретный измеримый результат, ясный коммит.
И вот тут начинается интересное.
Главная грабля — токены
Главная боль /goal — не качество кода и не зацикливания. Непредсказуемость трат токенов.
Не «огромные траты». А именно непредсказуемые. Один и тот же класс задач, поставленный одинаково сформулированной целью, может стоить 80k токенов в одном случае и 400k — в другом. Без видимой причины. Иногда агент быстро находит решение и закрывает цель за два цикла. Иногда уходит в спираль уточнений, рефакторингов, попыток валидации, и сжигает в пять раз больше.
Это бесит сильнее, чем хочется. Потому что нельзя бюджетировать. Если у тебя 5-часовой план в ChatGPT-плане, ты не знаешь, сколько /goal-сессий поместится. Может три. Может одна.
Кстати, по этому поводу есть отдельная грабля, про которую мало пишут. Когда упираешься в weekly или 5-часовой лимит — /goal не падает. Агент продолжает генерить текст. Но падает на MCP-вызовах, которые требуют LLM-approval (потому что approval сам по себе требует токена, а квоты ноль). Поэтому search_docs, db_seeds и подобное молча перестают работать. Сессия выглядит «живой», а на самом деле обезоружена. Если запускаете /goal на ночь — проверяйте свой dashboard, иначе утром получите красивый коммит без выполненных миграций.
Из этого мой главный совет: не оставляйте /goal бесконтрольно. Пока что. Может потом изменится — сейчас процесс нужно наблюдать. Не каждый ход, конечно. Но возвращаться раз в 15-20 минут, смотреть, что и сколько съедено, и быть готовым нажать /goal pause, если пошло не туда.
/side — два сценария
Вторая команда, которая ушла в работу — /side. Это аналог /btw из Claude Code: открыть эфемерный side-thread, не сбивая основную задачу. Escape — вернулись.
Технически это PR #18190 + расширение #18542. Внутри /side нельзя открыть ещё один /side — рекурсия запрещена. Можно с inline-вопросом сразу: /side Has this plan got an obvious risk?.
Очевидный сценарий — спросить уточнение, не сбивая цикл.
Менее очевидный, на котором ловлю себя несколько раз в неделю. Codex (и GPT-5.5 особенно) использует огромное количество англицизмов, причём в самых неожиданных местах. Получаешь объяснение, и в нём слова вроде «coalesce», «obviation», «debouncing», «invariant» в один ряд. Часть очевидна. Часть нет, особенно в специфичном домене. Открываю /side и спрашиваю: «расшифруй этот абзац простыми словами, что значит X в контексте моей задачи». Получаю короткий ответ. Закрываю. Возвращаюсь к основной цели.
Звучит не как фича для чейнджлога, но это как раз то, ради чего /side ценен в реальной работе. Контекст основной задачи остаётся чистым. Агент не отвлекается. Я уточняю — и иду дальше.
Кто взялся первым
Любопытная вещь, которую я заметил в команде. Думал, /goal подхватят первыми те, кто пишет код. Производительность, рефакторинг, миграции. Сценарии «дай агенту цель и дай ему работать».
Не подхватили. Ну, попробовали — но не пошло устойчиво.
Первыми реально взялись исследователи. Те, кто работает над проектами со сбором информации и данных. Им /goal зашёл сильнее всего, потому что у них типичная задача структурно ложится на /goal-парадигму: есть конкретная исследовательская цель (улучшить точность определённой метрики), есть измеримый результат (метрика — это число), есть ограниченный контекст, в котором агент работает.
Они гоняют /goal для повышения точности исследований — и это работает. Цель конкретная, домен чёткий, метрика измеримая. Все три условия, которые /goal любит.
Остальные тестируют — для улучшения конкретных метрик в коде, для оптимизаций, для миграций. Тоже работает, тоже нравится. Но не каждый день, не как основной инструмент.
Сказать, что мы её повсеместно стали использовать — рано. Не прижилась. Но это нормально для Experimental.
/title, /statusline и codex update
Маленькая удобная вещь. До 0.128.0 правка заголовка терминала и status line требовала рестарта или применялась только к новым сессиям. Теперь /title и /statusline работают прямо в активном ходе (PR #19917).
/statusline — picker для нижнего бара: model, model+reasoning, context stats, rate limits, git branch, token counters, session id, cwd, project root, codex version. Тогглишь, переупорядочиваешь, конфиг сохраняется в tui.status_line.
/title — то же для заголовка терминала: app name, project, spinner, status, thread, git branch, model, task progress. Сохраняется в tui.terminal_title.
Зачем это? Если параллельно крутятся три /goal-сессии в трёх вкладках, заголовки и статус-бары — единственный способ их различать. До 0.128.0 я ловил себя на том, что переключаюсь между вкладками и теряюсь, какая чем занята. Теперь не теряюсь.
И codex update — самообновление CLI прямо из терминала. До этого ставил/обновлял через npm. Теперь не нужно. Маленькая, незаметная, удобная.
Когда /goal не работает
Чтобы не было пафоса: /goal не серебряная пуля. Сценарии, где он стабильно ломается:
Размытая цель. Если попросить «сделай код лучше» — агент уйдёт в бесконечный цикл уточнений и переписываний. Цели нужен definition of done, выраженный в чём-то измеримом. Тесты, метрика, поведенческий критерий. Без этого — деньги в трубу.
Отсутствие обратной связи. Если у агента нет доступа к тестам, метрикам, флэйм-графам — он не может проверить свою работу. Будет работать по proxy signals, несмотря на установку «не делать так». Решение — настраивать MCP-инструменты заранее: тесты, perf-guard, доступ к логам.
Прод. Очевидно, но скажу прямо: на проде /goal запускать опасно. Агент может коммитить, мержить, рестартить. Один неудачный цикл — и у вас feature-branch с 47 коммитами, из которых половина бессмысленные. На проде только в read-only режиме или под жёстким permission profile.
Quota walls. Уже описал выше. Если упираетесь в weekly limit — MCP-approvals молча отвалятся, а сессия будет выглядеть живой.
Длинные неструктурированные задачи. «Перепиши этот сервис на новую архитектуру» без декомпозиции — /goal не справится. Нужно либо разбить на под-цели, либо использовать паттерн scrappy → PRD → clean: запустить /goal на исследовательской ветке, получить рабочее решение, описать его как PRD, реализовать заново начисто во второй итерации.
И ещё одно. Я использовал Ralph loop до /goal — не на основном продукте, а как вспомогательный инструмент для выявления багов и циклической проверки дизайна. Bash-цикл, скрипт, запуск, проверка результата, перезапуск. Грубо, но рабоче. /goal это автоматизирует — но не отменяет необходимость сначала понять, для какой задачи loop вообще подходит. Не каждая задача — петля.
Что в итоге
OpenAI сдвинул Codex от чат-помощника к автономному агенту цели. Это не маркетинг — за /goal стоит реальная архитектура с persistent state, soft-stop’ом и инжекцией системного промпта против proxy signals. Работает. Иногда впечатляюще, как кейс @NicolasZu с +25% fps за час.
Но эта же автономность обратной стороной — непредсказуемые траты и невозможность бюджетирования. Не оставляйте /goal бесконтрольно. Пока что.
С другой стороны — эксперименты с /goal обязательны прямо сейчас. Не потому что фича волшебная. А потому что к навыку «писать код руками» добавляется навык «работать рядом с процессами, которые тоже пишут код». Первый никуда не девается — кто-то всё ещё должен читать диффы, ловить proxy signals и понимать, почему агент закоммитил бессмыслицу. Просто инженерных задач становится больше, и часть из них теперь — про оркестровку.
И эта часть пока работает плохо. Бюджетировать нельзя, оставлять без присмотра нельзя, на проде нельзя. Учиться лучше начать сейчас, на маленьких целях и в безопасных контурах — чтобы когда /goal выйдет из Experimental, не разбираться с непредсказуемыми токенами в первый раз.
Ссылки
Codex Changelog — официальный список релизов
Slash commands reference — справка по командам
openai/codex Releases — GitHub-релизы
Issue #20536 — request to document
/goalSimon Willison: Codex CLI 0.128.0 adds /goal — разбор от 30 апреля
Kingy AI: long-horizon mode breakdown — детальный разбор архитектуры
Канал, где разбираю автономных агентов и работу AI Dev Team — @maslennikovigor. Там же выкладываю фейлы, которыми не хочется делиться публично. Связаться напрямую — @maslennikovig. Open-source kit с агентами и скиллами — GitHub.
