A ChatGPT plan gives each person a usage allowance for Codex, including cloud features and integrations. An API key bills per token at standard API rates and, per OpenAI's page, covers Codex in the CLI, SDK or IDE extension but not cloud features such as GitHub review or Slack. Choose by whether you need cloud features or centralized API controls.
What each route is
OpenAI's Codex usage page describes two ways to power the agent. The first is a ChatGPT plan, where the plan's allowance covers local messages and cloud chats, measured over windows such as five hours with weekly limits that may also apply. The second is an API key, which the page says lets you run extra local chats charged at standard API rates. Tools such as the terminal agent can be called from scripts and CI pipelines, according to the CLI page, which makes the API route the natural choice for automation.
| Question | ChatGPT plan | API key |
|---|---|---|
| How is usage measured? | Allowance over windows, credits beyond it | Tokens at API rates |
| Cloud features | Available on plans that include them | Not covered, per the page |
| CLI, SDK, IDE extension | Covered | Covered |
| Admin controls | Plan admin controls on business plans | API organization controls such as limits |
| Fits best | Individuals and teams wanting a bundle | Automation and centralized spend control |
Plan features change, so confirm each row against the current page.
Why the difference matters
Cloud features run in OpenAI's environment and integrate with tools like code review and chat. If your workflow depends on them, the API route will not provide them. If your workflow is local and scripted, an API key may fit better, with limits you set yourself. The page also notes model availability follows the API models your key can access, so check which models your key can use.
Worked example: three teams
These cases are illustrative.
Team one: five developers who want in-editor help. They use the CLI and IDE extension daily and sometimes ask for cloud review. A plan covers both. They watch the usage dashboard and buy credits if they run out.
Team two: a platform group that runs the agent in CI to fix lint failures. The jobs are scripted and need predictable limits and attribution. An API key with a dedicated project and spend limit fits. Cloud features are not needed.
Team three: a large company. Some staff use plans, some pipelines use keys. They set a policy: interactive work on plans, automation on keys with per-pipeline projects, and no personal accounts on company repositories.
Controls on the API side
OpenAI's rate limit guide says limits are set per organization and project, vary by model, and include request and token counters. It says to set the output ceiling close to the response size you expect, and to retry rate limit errors with backoff while not retrying quota errors. Use a separate project and key per pipeline, with its own limits. See how to set spend and workspace limits and retry and backoff.
Controls on the agent side
Whatever route powers it, an agent that edits files and runs commands needs permission limits. The CLI page says a permissions command controls when the agent may edit files or run commands without asking, and shows the active sandbox and writable roots. Start with the strictest mode that lets people work and widen deliberately.
Account hygiene
- Do not let personal plans authenticate on company machines for company code unless policy allows it.
- Store API keys in a secrets manager, not in repository files.
- Use one key per pipeline and rotate on staff change.
- Record which route each team uses and who owns the bill.
- Review usage monthly.
Reviewing what the agent wrote
An agent can add dependencies and change build files. Run dependency and vulnerability checks on its pull requests like any other. Safeguard's SBOM and dependency scanning and policy gates can check pull requests regardless of which assistant produced the code.
A simple decision record
Write a short decision record for your team: the date, the route you chose for each group, the reasons, and the conditions that would change your mind, such as a feature that only one route offers or a change in how limits work. Link the pages you relied on. When the vendor revises plans, you can reread the record and decide quickly whether the choice still holds.
Questions to settle before you pick
- Do we need cloud features such as code review integrations, or is local work enough?
- Will the agent run unattended in CI, where an allowance that runs out mid job is a problem?
- Who owns the bill, and can they see usage by person or by pipeline?
- Which models do we need, and does the route we picked give access to them?
- Which accounts may touch company repositories, and how do we enforce it?
- What is our fallback when a limit arrives during a release?
Write the answers in your decision record. If two answers conflict, for example needing cloud features and also needing centralized API-style limits, you may need both routes for different groups, with a clear rule about which work goes where.
Rolling out in stages
Start with a small group on one route and gather a month of usage. Add a second group on the other route if the first reveals a gap. Keep a short list of problems from each group: limits hit, features missing, permissions that were too tight or too loose. Review the list with the vendor documentation open, because some problems turn out to be settings rather than limits.
A staged rollout also gives you real numbers for budgeting. Per-person plan allowances and per-token API usage are hard to compare on paper, but a month of actual tasks gives you something concrete to take to finance.
What this means for you
If you are choosing how to pay for a coding agent, begin with the work, not the price. Interactive daily use with cloud features points toward a plan. Scripted or unattended work with per-project limits points toward an API key. Many organizations end up with both, and that is fine if each group knows which route it uses and why.
Common mistakes
Typical mistakes are assuming an API key unlocks cloud features, running unattended jobs on an allowance that can run out mid task, using personal accounts on company repositories, storing keys in files and failing to check which models a key can reach. Another is to compare a plan allowance with a per-token bill without measuring real tasks. Pick a route per group, write down the reason and revisit when plans change.
Try it yourself
Click through it at your own pace, or open it full screen. It shows ChatGPT working with Safeguard. Watch how security context from your projects is brought into the conversation, whichever route pays for the usage.
Quick check
Does an API key give me cloud features?
Not according to the OpenAI page, which says API-key plans cover Codex in the CLI, SDK or IDE extension but not cloud features such as GitHub review or Slack.
Which route suits CI?
The CLI page says the tool can be called from scripts and CI, and an API key gives per-project limits and attribution, so many teams use keys for automation. Check your own needs.
Do both routes need permission controls?
Yes. Limits control volume, not what the agent may do. Set permissions and sandbox rules either way.
Sources
Last reviewed: 19 October 2026.
