Codex: подписка vs API — доступ, оплата и автоматизация

Вход через ChatGPT уместен для интерактивной работы человека в Codex CLI, IDE, desktop или cloud-средах, когда квота, членство в workspace и доступные контроли уже относятся к плану. Собственный OpenAI API-ключ уместен, когда workload должен оплачиваться в API-организации или проекте, требует отдельного контура расходов либо запускается через процесс, ориентированный на машину. Это не гарантирует одинаковые модели, функции, лимиты или контроль данных: до теста зафиксируйте поверхность, аккаунт, workspace, метод аутентификации, модель и владельца биллинга.

Не выбирайте API только потому, что задача техническая, и не переносите личный ChatGPT login в CI только потому, что план уже оплачен. Сначала разделите локальный pairing, делегированные cloud-задачи, code review, запланированную автоматизацию и собственную программную интеграцию. Для каждого класса определите идентичность, разрешения, бюджет, доказательства и условие остановки. Побеждает самый простой контур, который воспроизводимо проходит gates качества, полномочий и стоимости.

• Человек, локальная или IDE-сессия и квота плана → начинайте с входа через ChatGPT.
• API-проект, сервисная учетная запись, собственный metering или интеграция приложения → оценивайте API-ключ или workload identity.
• Codex cloud или review → отдельно проверьте подключение репозитория, политику workspace и квитанцию использования.
• Смешанный режим → запретите тихий fallback плательщика и документируйте routing.

OpenAI явно разделяет вход через ChatGPT и использование собственного API-ключа. После смены метода аутентификации не полагайтесь на старый prompt терминала или на сам факт активной подписки. Сохраните квитанцию без секретов: клиент и версия, метод аутентификации, маскированная метка организации или workspace, активная модель, репозиторий, профиль sandbox, timestamp и страница использования, где ожидается списание. В CLI проверяйте текущее состояние до первого существенного запуска.

Создайте негативный тест в одноразовом проекте: оставьте неактивную тестовую учетную запись в контролируемом shell-профиле и убедитесь, что оператор обнаруживает несоответствие до выполнения. Никогда не записывайте token в log, screenshot, issue или доказательства статьи. Для автоматизации используйте наиболее узкую доступную проектную или сервисную идентичность, ротацию и тест отзыва; человеческая OAuth-сессия не должна незаметно становиться общей машинной идентичностью.

Codex с аккаунтом ChatGPT использует квоту и биллинг соответствующего плана; доступные дополнительные кредиты и поведение reset зависят от плана и workspace. Codex с собственным API-ключом использует API pricing и лимиты API-проекта. Даже если оба контура измеряют tokens, могут различаться rate card, включенное использование, cache, плата за tools, владелец бюджета и авторитетный счет. Не путайте оценку в dashboard с финансовым счетом.

Сравнивайте стоимость принятой задачи на одном commit, наборе задач, инструкциях, классе модели, политике reasoning, сетевой границе и rubric reviewer. Записывайте input, cached input, output, активность tools, retries, параллельные workers, минуты review, принятый результат и прерывание. Не публикуйте среднее значение поставщика как прогноз своей команды. Если задача меняется между контурами или один run получает теплый cache, отметьте сравнение невалидным и повторите его.

• Квитанция плана → workspace, квота или пул кредитов, состояние reset и принятый артефакт.
• API-квитанция → организация, проект, модель, использование, состояние бюджета и источник счета.
• Неизвестное завершение → сначала проверьте git state и побочные эффекты, затем решайте вопрос retry.
• Изменение цены или модели → обновите датированный manifest, а не старую таблицу по памяти.

Интерактивный локальный Codex может запрашивать approval, показывать diff и работать в sandbox рядом с человеком. Делегированная cloud-задача зависит от подключенного репозитория, environment и контролей workspace. Неинтерактивный `codex exec`, GitHub Action или Codex SDK добавляют машиночитаемый output, максимальное время выполнения, concurrency, retry и риски частичного завершения. Одинаковый login не делает эти поверхности операционно эквивалентными.

Создайте execution manifest для каждого режима: source commit, writable paths, network policy, источник секретов, разрешенные команды, approval policy, output schema, timeout, idempotency key, команды валидации и merge authority. API-биллинг упрощает project metering, но автоматически не ограничивает полномочия shell. Политика ChatGPT workspace может дать полезные admin controls, но не заменяет branch protection репозитория и независимый deploy gate.

Для Business, Enterprise или Edu проверяйте членство, роль, доступность моделей, managed configuration, контроль данных, repository connector и audit surface как отдельные entitlements. Для API проверяйте роли организации и проекта, service accounts, лимиты расходов, права на модели и жизненный цикл ключей. Удаление seat не доказывает отзыв API-учетных данных; удаление API-ключа не отключает GitHub-репозиторий от Codex cloud.

Проведите joiner-mover-leaver тест на синтетическом пользователе. Joiner получает только нужный репозиторий и режим; mover теряет старый проект и политику; leaver теряет ChatGPT workspace, API-проект, подключение репозитория, cached credentials и schedule автоматизации. Security хранит квитанции с timestamp, а не секреты. Любой оставшийся путь к записи или billable run блокирует rollout.

Выберите 12–20 репрезентативных задач: объяснение репозитория, bug fix, многофайловый refactor, исправление тестов, исследование зависимостей, review и корректный отказ при недостатке доказательств. В первую неделю выполните их через утвержденный ChatGPT-контур, во вторую — через ограниченный API-проект. Зафиксируйте commit, версию клиента, класс модели, конфигурацию, порядок задач и rubric приемки. Перед каждым run фиксируйте квитанцию аутентификации, после него — diff, checks, состояние завершения и источник биллинга.

Добавьте failure fixtures: исчерпанная квота, потолок API-бюджета, отозванный пользователь, отозванный ключ, запрет сети, отказ approval, timeout после возможного изменения и поврежденный машиночитаемый output. Pilot проходит, когда атрибуция плательщика воспроизводима, критические задачи завершаются или fail-closed, finance может сверить использование, а reviewer не видит деградации приемки. Результат выбирает операционную модель; он не доказывает универсальное превосходство продукта.

• Freeze → commit, набор задач, класс модели, политика и критерии приемки.
• Observe → аутентификация, плательщик, tokens или квота, tools и состояние завершения.
• Review → корректность, регрессии, время исправления и качество доказательств.
• Reconcile → квитанция клиента против авторитетного dashboard плана или API.
• Decide → контур с минимальной сложностью, проходящий критические gates.

Перед миграцией инвентаризируйте конфигурацию Codex, AGENTS.md, skills, MCP servers, переменные окружения, подключения репозиториев, cloud environments, schedules автоматизации, настройки моделей и источники policy. Не копируйте credential между контурами: перевыпустите его у целевого owner с минимальным scope. После cutover выполните read-only canary, проверьте квитанцию аутентификации, sandbox, сеть и destination биллинга и только после этого разрешайте patch-задачу.

В смешанной модели routing должен быть детерминированным: например, человеческий локальный pairing через вход workspace, CI proposal через API-проект, merge только через branch protection. Запретите fallback на личный key или account. Rollback возвращает предыдущий утвержденный путь аутентификации, отключает новые schedules, отзывает новый credential и сверяет незакрытое использование и побочные эффекты.

Запишите владельца решения, классы workload, требуемые поверхности, источник идентичности, границу данных, доступность моделей, квоту или API-бюджет, concurrency, требования аудита, approval policy, scope репозитория, владельца выхода и дату пересмотра. Ссылайтесь на текущую официальную документацию вместо копирования изменяемых лимитов и цен. Значение, которого нет в вашем аккаунте или контракте, отмечайте как `unknown`.

Выбирайте ChatGPT-контур, если он покрывает нужные интерактивные или управляемые поверхности Codex с понятной квотой и жизненным циклом workspace. Выбирайте API-контур для отдельной программной границы биллинга и идентичности, если workload и условия это поддерживают. Смешанный контур допустим только с явным routing, независимыми бюджетами, изоляцией credentials и протестированным отзывом. Повторяйте review после изменения плана, pricing, rate card, модели, клиента, policy или поверхности автоматизации.