Amiga
Оглавление курса · урок 3 из 13

Модуль 1 · Решение · урок 3 из 13

Доступ: тарифы ChatGPT и API

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

Два способа входа

Codex поддерживает два режима авторизации (документация):

  • Вход через ChatGPT — доступ по подписке. Пользователь работает в рамках рабочего пространства (workspace), подчиняется его ролям и политике хранения данных.
  • API-ключ — оплата по токенам по тарифам API. Действуют настройки данных API-организации, а не рабочего пространства ChatGPT.

Десктопное приложение, CLI и расширение для IDE поддерживают оба режима. Но облачные задачи Codex требуют входа через ChatGPT. С API-ключом нет облачных функций: автоматического ревью в GitHub, интеграции со Slack, облачных окружений (pricing).

Тарифы — только названия

На октябрь 2026 года Codex входит в тарифы ChatGPT: Free, Go, Plus, Pro, Business, Enterprise и Edu, плюс отдельный вариант — работа по API-ключу. На младших тарифах набор поверхностей и моделей ограничен, на Plus и выше доступны CLI, IDE, облако и интеграции. Конкретные условия, состав функций по тарифам и цены меняются часто — смотрите актуальную страницу тарифов перед каждой закупкой.

Для компании выбор обычно стоит между Business и Enterprise (для доступа сотрудников) плюс API-ключи (для CI и автоматизации). Личные Plus и Pro — тарифы для частных лиц, а не способ подключить команду.

Лимиты: что важно понимать

Документация описывает несколько механизмов, которые влияют на планирование (usage limits):

  • На части тарифов действуют окна лимитов — пятичасовые и недельные. Локальные сообщения и облачные задачи расходуют общий лимит, облачные задачи могут тратить его быстрее.
  • На Enterprise и Edu с гибкой оплатой нет фиксированных лимитов: расход идёт из кредитов рабочего пространства.
  • ChatGPT Work и Codex делят тарификацию, кредиты и лимиты, но администрируются отдельно.
  • Доступность моделей отличается между входом через ChatGPT и API-ключом: модели снимаются с поддержки в ChatGPT по своему графику, а на API-ключ это не влияет.

Не закладывайте в планы конкретные числа сообщений: сама документация называет диапазоны оценочными. Смотрите дашборд использования и /status в CLI.

Почему личные подписки — проблема

Типичная картина в агентстве: половина разработчиков уже платит за личный Plus и работает с кодом клиентов через него. Что не так:

  • Другие правила данных. Для Enterprise OpenAI указывает, что по умолчанию бизнес-данные не используются для обучения. У личных тарифов настройки данных управляются самим пользователем — компания не знает, что выставлено.
  • Нет контроля. Админ не может навязать песочницу, запретить MCP-серверы или сеть: управляемая конфигурация действует только в рабочем пространстве.
  • Нет аудита. Ни аналитики, ни Compliance API, ни логов — при инциденте вы ничего не восстановите.
  • Договор. Если клиенту обещано, что код обрабатывается только у согласованных подрядчиков, личный аккаунт сотрудника — нарушение, которое вы не видите.

Решение — не запрет, а легальная альтернатива плюс техническое закрепление входа.

Закрепите вход за компанией

Ограничения входа админ задаёт в локальном системном requirements.toml или через MDM на macOS — до того, как Codex загрузит учётные данные и облачную политику (managed configuration):

toml · /etc/codex/requirements.toml
allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods разрешает chatgpt, api или оба. allowed_chatgpt_workspaces пускает только в перечисленные рабочие пространства — подставьте реальный идентификатор вашего. cli_auth_credentials_store = "keyring" хранит учётные данные в системном хранилище ключей, а не в открытом файле auth.json. Важная деталь: в облачной политике эти поля игнорируются, их нужно доставлять на устройство.

На стороне пользователя есть похожие ключи forced_login_method и forced_chatgpt_workspace_id (auth): при несовпадении Codex разлогинивает пользователя и завершает работу. Но это пользовательская настройка, а принуждение — через requirements. Как доставлять такие файлы на машины, разберём в уроке про администрирование.

Если аккаунт входит в ChatGPT по email и паролю, документация требует включить MFA до работы с Codex Cloud; если вход идёт через SSO, MFA должен включить администратор SSO.

API-ключи: для чего

API-ключ — правильный выбор для автоматизации: codex exec в CI, бот-ревьюер, скрипты. Документация называет его рекомендуемым вариантом для CI. Enterprise-админ может дополнительно разрешить Codex access tokens для доверенных раннеров (codex login --with-access-token). Общее правило из документации: не запускайте исполнение Codex в недоверенных или публичных окружениях.

Заводите ключи отдельно под задачи и проекты, а не один на всю компанию: так проще считать расход и отзывать ключ при инциденте. Подробнее об автоматизации — в курсе «Codex в автоматизации».

Особенность для GitLab

Если ваш код в GitLab, учтите два факта из документации на октябрь 2026 года (GitLab, cloud environments):

  • Ревью merge request через @codex review работает в статусе beta на всех тарифах ChatGPT. Для self-managed GitLab нужна настройка админом рабочего пространства, сервисный аккаунт, а групповые вебхуки требуют GitLab Premium или Ultimate версии 19.0+.
  • Текущие облачные окружения Codex не поддерживают GitLab и self-hosted GitHub Enterprise Server. Сама GitLab-интеграция работает через проектные окружения старого режима Codex Cloud (Legacy), который OpenAI собирается вывести из эксплуатации. Значит, основная работа будет локальной (CLI, IDE, десктоп) и в вашем CI.

Это прямо влияет на выбор: если вы рассчитывали на облачные задачи, а код живёт в GitLab, проверьте актуальный статус до закупки.

Попробуйте сами

10–15 мин на рабочем месте
  1. Проведите анонимный опрос: кто работает с агентами, через какой аккаунт и на каких проектах. Сравните с официальным списком доступов.
  2. Составьте таблицу «кто какой доступ получает»: разработчики — вход через рабочее пространство; CI — API-ключ на проект; тестировщики и аналитики — по потребности. Отметьте, где нужны облачные задачи и поддерживаются ли они вашим Git-хостингом.
  3. Найдите идентификатор вашего рабочего пространства и подготовьте три строки allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store для системного requirements.toml.

Коротко

  • Два входа: через ChatGPT (подписка, правила рабочего пространства, облако) и API-ключ (оплата по токенам, правила API, без облачных функций).
  • Тарифы называйте по именам и сверяйтесь со страницей тарифов — условия меняются.
  • Личные подписки на клиентском коде — это другие правила данных, отсутствие контроля и аудита.
  • allowed_login_methods и allowed_chatgpt_workspaces в системном requirements.toml или MDM закрепляют вход за компанией.
  • Для GitLab: ревью MR в beta, облачные окружения не поддерживаются.
Отметка хранится только в вашем браузере
Хотите связаться с владельцем
компании напрямую?
Дмитрий Тарасов
Дмитрий Тарасов
СЕО

НАПИСАТЬ

Написать в MAX