Codex subscription vs API: choosing access, billing, and automation

ChatGPT sign-in is appropriate for interactive human work in Codex CLI, IDE, desktop, or cloud surfaces when the allowance, workspace membership, and available controls already belong to the plan. Your own OpenAI API key is appropriate when the workload must be billed to an API organization or project, needs a separate spend boundary, or runs through a machine-oriented process. This does not guarantee identical models, features, limits, or data controls: record the surface, account, workspace, authentication method, model, and billing owner before testing.

Do not choose the API merely because the task is technical, and do not move a personal ChatGPT login into CI merely because the plan is already paid for. First separate local pairing, delegated cloud tasks, code review, scheduled automation, and your own programmatic integration. For each class, define identity, permissions, budget, evidence, and a stop condition. The simplest path that reproducibly passes quality, authority, and cost gates wins.

• Human, local or IDE session, and plan allowance → start with ChatGPT sign-in.
• API project, service credential, custom metering, or app integration → evaluate an API key or workload identity.
• Codex cloud or review → verify repository connection, workspace policy, and usage receipt separately.
• Mixed mode → forbid silent payer fallback and document routing.

OpenAI explicitly separates sign-in with ChatGPT from use of your own API key. After changing the authentication method, do not rely on an old terminal prompt or on the fact that a subscription is active. Preserve a receipt without secrets: client and version, authentication method, masked organization or workspace label, active model, repository, sandbox profile, timestamp, and the usage page where the charge is expected. In the CLI, verify the current state before the first material run.

Build a negative test in a disposable project: leave an inactive test credential in a controlled shell profile and verify that the operator detects the mismatch before execution. Never write a token to a log, screenshot, issue, or article evidence. For automation, use the narrowest available project or service identity, rotation, and revoke test; a human OAuth session must not silently become a shared machine identity.

Codex with a ChatGPT account uses the allowance and billing of the relevant plan; available additional credits and reset behavior depend on the plan and workspace. Codex with your own API key uses API pricing and the limits of the API project. Even when both paths measure tokens, rate card, included usage, cache, tool charges, budget owner, and authoritative invoice can differ. Do not confuse a dashboard estimate with the financial invoice.

Compare accepted-task cost using the same commit, task set, instructions, model class, reasoning policy, network boundary, and reviewer rubric. Record input, cached input, output, tool activity, retries, parallel workers, review minutes, accepted result, and interruption. Do not publish a vendor average as a forecast for your team. If the task changes between paths or one run gets a warm cache, mark the comparison invalid and repeat it.

• Plan receipt → workspace, allowance or credit pool, reset state, and accepted artifact.
• API receipt → organization, project, model, usage, budget state, and invoice source.
• Unknown completion → check git state and side effects first, then decide whether to retry.
• Price or model change → update the dated manifest instead of relying on an old table from memory.

Interactive local Codex can request approval, show a diff, and work in a sandbox next to a person. A delegated cloud task depends on the connected repository, environment, and workspace controls. Non-interactive `codex exec`, GitHub Action, or the Codex SDK add machine-readable output, maximum runtime, concurrency, retries, and partial-completion concerns. The same login does not make these surfaces operationally equivalent.

Create an execution manifest for every mode: source commit, writable paths, network policy, secrets source, allowed commands, approval policy, output schema, timeout, idempotency key, validation commands, and merge authority. API billing makes project metering easier but does not automatically restrict shell authority. ChatGPT workspace policy can provide useful admin controls but does not replace repository branch protection or an independent deployment gate.

For Business, Enterprise, or Edu, verify membership, role, model availability, managed configuration, data controls, repository connector, and audit surface as separate entitlements. For the API, verify organization and project roles, service accounts, spend limits, model permissions, and key lifecycle. Removing a seat does not prove that an API credential was revoked; deleting an API key does not disconnect a GitHub repository from Codex cloud.

Run a joiner-mover-leaver test with a synthetic user. A joiner receives only the required repository and mode; a mover loses the old project and policy; a leaver loses the ChatGPT workspace, API project, repository connection, cached credentials, and automation schedule. Security keeps timestamped receipts, not secrets. Any residual path to a write or billable run blocks rollout.

Choose 12–20 representative tasks: repository explanation, bug fix, multi-file refactor, test repair, dependency investigation, review, and a correct refusal when evidence is insufficient. Run them through the approved ChatGPT path in week one and through a restricted API project in week two. Freeze the commit, client version, model class, configuration, task order, and acceptance rubric. Capture an authentication receipt before every run, then the diff, checks, completion state, and billing source afterward.

Add failure fixtures: exhausted allowance, API budget ceiling, revoked user, revoked key, network denial, approval refusal, timeout after a possible change, and corrupted machine-readable output. The pilot passes when payer attribution is reproducible, critical tasks complete or fail closed, finance can reconcile usage, and the reviewer sees no acceptance degradation. The result selects an operating model; it does not prove universal product superiority.

• Freeze → commit, task set, model class, policy, and acceptance criteria.
• Observe → authentication, payer, tokens or allowance, tools, and completion state.
• Review → correctness, regressions, correction time, and evidence quality.
• Reconcile → client receipt against the authoritative plan or API dashboard.
• Decide → the lowest-complexity path that passes the critical gates.

Before migrating, inventory Codex configuration, AGENTS.md, skills, MCP servers, environment variables, repository connections, cloud environments, automation schedules, model settings, and policy sources. Do not copy a credential between paths: reissue it from the target owner with minimum scope. After cutover, run a read-only canary, verify the authentication receipt, sandbox, network, and billing destination, and only then allow a patch task.

In a mixed model, routing must be deterministic: for example, human local pairing through workspace sign-in, CI proposals through an API project, and merge only through branch protection. Forbid fallback to a personal key or account. Rollback restores the previous approved authentication path, disables new schedules, revokes the new credential, and reconciles outstanding usage and side effects.

Record the decision owner, workload classes, required surfaces, identity source, data boundary, model eligibility, allowance or API budget, concurrency, audit needs, approval policy, repository scope, exit owner, and review date. Link to current official documentation instead of copying mutable limits and prices. Mark any value not present in your account or contract as `unknown`.

Choose the ChatGPT path if it covers the required interactive or governed Codex surfaces with a clear allowance and workspace lifecycle. Choose the API path for a separate programmatic billing and identity boundary when the workload and terms support it. A mixed path is acceptable only with explicit routing, independent budgets, credential isolation, and tested revocation. Review the decision again after changes to the plan, pricing, rate card, model, client, policy, or automation surface.