Планируйте в ChatGPT Pro, выполняйте в Codex: плейбук по передаче дизайн-документа

Схема работы, которую стоит позаимствовать в этом месяце, — это не модель, а разделение труда. Вы передаёте GPT-6 Pro в ChatGPT URL репозитория, просите у него документ по проектированию, а не патч, и передаёте этот документ Codex или Claude Code на реализацию. Планировщик работает на GPT-6 Astra — GPT-6 Pro — это имя, которое в лимитах использования ChatGPT применяется к ней, — а Astra — модель от 3 сентября 2026 года, так что здесь нет ни репортажа о запуске, ни заявления о релизе. То, что изменилось за последние семь дней, — это более узкий вопрос, и его стоит сформулировать точно: 17 сентября 2026 года практики сообщили, что официальный плагин GitHub в обычном ChatGPT Chat, а не в ChatGPT Work и не в Codex, может редактировать файлы репозитория, делать коммиты и открывать пул-реквесты, не расходуя квоту Codex/Work. Это утверждение сообщества, а не документация вендора — официальные страницы справки по-прежнему описывают приложение GitHub как доступное только для чтения и направляют всю запись через Codex — и оговорки, прилагаемые к нему, важны не меньше самого утверждения. Всё ниже помечено как сообщённое вендором, сообщённое сообществом или взятое с официальных страниц 19 сентября 2026 года.

Рабочий процесс, за один проход

Практики описывают один и тот же цикл с небольшими вариациями. Чаще всего повторяется такой: вставить адрес GitHub в ChatGPT, попросить его прочитать код и подготовить проектный документ, затем скачать этот документ и передать его агенту-исполнителю. Некоторые также просят сделать pull request; другие останавливаются на документе и позволяют исполнителю писать. В любом случае схема одна и та же — планирование в чат-продукте, сборка в агентском продукте — и причина, по которой это стоит копировать, в том, что эти две половины тарифицируются отдельно.

• Артефакт планирования — документ проектирования: интерфейсы, которые нужно добавить, файлы, которые нужно затронуть, с указанием путей, порядок миграции, приёмочные тесты и что делать, если всё пойдёт не так.

• Артефакт исполнения — ветка и pull request, созданные агентом, который может запускать только что написанные им тесты.

• Артефакт ревью — диф, и это единственное, что вообще должно попадать к ревьюеру.

Проектный документ — это несущий элемент, и он заслуживает своего места по двум причинам. Во-первых, документ переносим: один и тот же текст работает, будь исполнитель Codex, Claude Code или скриптовый агент, написанный вами самим, поэтому планирование, за которое вы заплатили, не привязано к инструменту одного вендора. Во-вторых, это поверхность проверки, которая существует до того, как что-либо будет записано в ваш репозиторий — что имеет огромное значение, учитывая, что путь записи в чат-продукте — наименее документированная часть всей этой конструкции.

Почему структура из двух корзин — это и есть весь трюк

ChatGPT не оплачивает этот рабочий процесс из одного общего котла. Chat, ChatGPT Work и Codex имеют отдельные квоты, причём Work и Codex совместно используют один общий пул; ключ OpenAI API — это снова отдельная оплата. Именно такая структура делает передачу задач экономичной: размышления происходят в корзине Chat, выполнение — в корзине агента, а проектный документ стоит одного сообщения Chat, тогда как реализация расходует квоту агента.

Цифры, как их публикует OpenAI для Chat-стороны, — это заявленные вендором показатели из его собственной документации по плану, а не результаты измерений:

• ChatGPT Pro за 200 долларов в месяц — 200 сообщений GPT-6 Pro в неделю; GPT-5.6 Sol Pro дополнительно даёт 170 сообщений в день, при этом общий лимит для обеих моделей вместе составляет 200 в день.

• ChatGPT Pro за $100 в месяц — 50 сообщений GPT-6 Pro в неделю, входящих в общий лимит с GPT-5.6 Sol Pro.

• Business Standard — 15 сообщений GPT-6 Pro в месяц, совместно с Sol Pro; Business Premium — 50 в неделю на той же основе совместного использования.

• ChatGPT Plus — GPT-6 Pro в Chat вообще нет. Astra попадает в Plus только через ChatGPT Work и Codex — а это именно та категория, которую и пытается защитить этот плейбук.

Со стороны Work/Codex OpenAI публикует не лимиты, а оценки, и прямо об этом говорит: примерно от 5 до 45 сообщений Astra за пятичасовое окно на Plus, от 25 до 225 на Pro 5x и от 100 до 900 на Pro 20x, причём на той же странице отмечается, что фактическое потребление зависит от сложности задачи, контекста, объёма вывода и использования инструментов, а сверх этого могут действовать и недельные лимиты. Эти диапазоны составляют примерно половину соответствующих чисел Sol — именно в этом арифметическая причина того, что передовую модель вообще можно позволить себе запускать в качестве агента.

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

Путь записи: что делает коннектор и что, как утверждают, делает он

Здесь источники расходятся, и это расхождение — самое интересное.

Собственная справочная документация OpenAI недвусмысленна: приложение GitHub в ChatGPT читает ваши репозитории для анализа и поиска, а генерация кода, его редактирование и отправка в GitHub — это то, для чего предназначен Codex. Это позиция только для чтения, и именно её следует учитывать при планировании, если вы внедряете это в командный процесс, потому что именно за ней стоит вендор.

Позиция сообщества, датированная 2026-09-17, такова: плагин GitHub для веб-версии в режиме Chat будет редактировать код, делать коммиты и открывать pull request'ы, и поскольку это официальный плагин, а не сторонний MCP-сервер, он не расходует квоту Codex или Work. В той же ветке осторожно относятся к масштабу: небольшие инструменты, мелкие правки, мелкие баги — крупные рефакторинги и сложная отладка по-прежнему остаются за Codex. Её собственные комментаторы добавляют оговорки, которые стоит повторить, потому что именно они и дают о себе знать:

• Обычные ограничения частоты запросов ChatGPT по-прежнему действуют. «Не квота Codex» — это не «бесплатно».

• Качество может ухудшиться после нескольких раундов без предупреждения, при этом сессия может переключиться на меньшую модель в середине задачи.

• Авторы ветки советуют не переключаться на Work, когда интерфейс предлагает это, и предупреждают, что наводнение анонимных чатов ухудшает веб-опыт для всех.

Независимое японское описание того же шаблона приходит к совместимому выводу без утверждения о квоте: если интеграция с GitHub поддерживает действия записи, обычный чат может читать репозиторий, изменять файлы, создавать ветку и открывать pull request; применяются обычные лимиты частоты чата; а Codex и Work используют общий пул агентов, поэтому обычный чат предназначен для правки нескольких файлов, а Codex — для длительных программных задач. Там, где два описания согласуются, согласие и есть полезная часть: чат — канал небольших изменений, Codex — канал длинных сессий, а пулы раздельны.

Существуют сторонние MCP-серверы, которые предоставляют настоящий рабочий процесс git — ветвление, diff, коммит, push, открытие pull request — с разрешениями, которые можно настраивать по уровням от «только чтение» до push. Если вы хотите, чтобы путь записи был детерминированным и поддающимся аудиту, а не поведением, на которое вы надеетесь, это тот самый маршрут; если вы хотите оставаться в рамках того, что документирует OpenAI, планируйте в Chat и пишите в Codex.

Так или иначе, именно передача проектного документа делает путь записи в чате защитимым. Сеанс чата с правом записи в репозитории предоставляет больше прав, чем сеанс чата с правом чтения, и этот документ — тот артефакт, который вы проверяете, прежде чем это разрешение будет задействовано.

Передача, шаг за шагом

• Направьте планировщик на репозиторий — публичный URL, вставленный в промпт, или коннектор GitHub, если вы его авторизовали, — и попросите его прочитать код, прежде чем что-либо предлагать.

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

• Попросите его процитировать файлы, которые он действительно прочитал. Документ проектирования, описывающий интерфейс, которого нет в репозитории, — самый распространённый способ провала этого рабочего процесса, и цитаты — это то, как вы поймаете это за минуту, а не за спринт.

• Сохраняйте документ в репозитории, а не вставляйте его в следующий инструмент. Исполнитель, который читает файл, может перечитать его; у исполнителя, получившего вставленный текст, есть только одна попытка.

• Запустите исполнителя, передав ему документ в качестве инструкции, и ограничивайте один pull request одним разделом документа. Именно в длинных сессиях качество агента незаметно ухудшается.

• После этого оставьте планировщика в роли только для проверки. Когда документ неверен, перепланируйте и обновите документ — не позволяйте исполнителю импровизировать в обход него, потому что импровизированная работа — это то, что документ и должен был предотвратить.

Где это ломается

• Устаревшее состояние репозитория — планировщик прочитал ветку по умолчанию, пока вы работаете в ветке функции, поэтому пути к файлам в документе отстают на одну версию. Укажите, какую ветку читать, или вставьте дерево ветки.

• Расхождение с проектным документом — документ и код противоречат друг другу, а исполнитель следует документу. Шаг с цитированием файлов, описанный выше, — это недорогая страховка.

• Неожиданный расход квоты не в ту сторону — двадцатиминутный разговор о планировании дёшев в сообщениях Chat и дорог с точки зрения внимания; долгий запуск агента — наоборот. Планируйте бюджет того ресурса, который вы на самом деле тратите.

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

• Разрастание разрешений — путь записи, будь то через плагин или MCP-сервер, даёт сессии чата возможность изменять ваш код. Разделите разрешения по уровням и отзывайте их, когда изменение будет внесено.

Запуск исполнительной половины через одну конечную точку

Планирующая половина этого рабочего процесса живёт внутри продукта по подписке, и эта часть такова, какова она есть. Исполнительная половина — это вызов API, и именно эту половину стоит взять на себя. Если вы автоматизируете исполнителя скриптом — небольшой цикл агента, задачу CI, которая превращает утверждённый проектный документ в ветку, — то вызов модели — единственная часть, которая должна быть заменяемой, потому что модель, которая вам понадобится в следующем квартале, — это не та модель, на которую вы ориентируетесь сегодня.

Вот для чего нужен слой маршрутизации. openai/gpt-6-astraдоступна через тот же OpenAI-совместимый эндпоинт, что и более 200 других моделей, при этом прайс-листовая цена провайдера передаётся без наценки — 0%. Поэтому когда поставщик меняет цену, цена на нашей стороне меняется в тот же день, а не при следующем продлении контракта. Автоматическое переключение при сбое позволяет направить на непроверенную модель часть трафика, подстраховавшись проверенной, — это честный способ выяснить, достаточно ли дешёвый исполнитель хорош для ваших тестов. А DSL маршрутизации объединяет несколько моделей в один вызов, так что модель-ревьюер может проверить диф исполнителя по тому же ключу, в том же пути запроса, без второй интеграции.

Ничто из этого не меняет структуру передачи. Это меняет стоимость экспериментов с той половиной, которую вы контролируете: один ключ, один эндпоинт и строка модели, которую можно изменить, не трогая пайплайн.

Кому сейчас стоит запустить это, а кому — подождать

Если вы уже платите за план ChatGPT уровня Pro и уже используете Codex или Claude Code, такую передачу работы стоит внедрить уже на этой неделе, потому что эти две статьи расходов и так разделены в вашем счёте, а проектный документ — самая дешёвая часть цикла. Начните с изменения, которое вы понимаете достаточно хорошо, чтобы заметить плохой план: запросите документ, прочитайте указанные в нём файлы, а затем передайте его.

Если вы на Plus, умерьте ожидания. Astra доступна вам через Work и Codex, но не через Chat, поэтому планировочная половина этого руководства недоступна вам в описанном виде — вы бы планировали и выполняли из одного и того же пула, что устраняет экономический аргумент и оставляет только дисциплину сначала написать документ. Эта дисциплина всё ещё стоит того, чтобы её иметь. А скидка — нет.

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

Тот же ключ открывает доступ к остальной части каталога, и вы можете просмотреть полный каталог моделей, чтобы увидеть, что ещё находится за одним OpenAI-совместимым эндпоинтом.