Codex Abo vs API: Zugang, Abrechnung und Automatisierung wählen

Die Anmeldung mit ChatGPT eignet sich für interaktive menschliche Arbeit in Codex CLI, IDE, Desktop oder Cloud-Oberflächen, wenn Kontingent, Workspace-Mitgliedschaft und verfügbare Kontrollen bereits zum Plan gehören. Ein eigener OpenAI-API-Key eignet sich, wenn der Workload einer API-Organisation oder einem Projekt in Rechnung gestellt werden muss, eine separate Kostengrenze braucht oder über einen maschinenorientierten Prozess läuft. Das garantiert keine identischen Modelle, Funktionen, Limits oder Datenkontrollen: Dokumentieren Sie vor dem Test Oberfläche, Account, Workspace, Authentifizierungsmethode, Modell und Billing Owner.

Wählen Sie die API nicht nur deshalb, weil die Aufgabe technisch ist, und verschieben Sie einen persönlichen ChatGPT-Login nicht in CI, nur weil der Plan bereits bezahlt ist. Trennen Sie zuerst lokales Pairing, delegierte Cloud-Tasks, Code Review, geplante Automatisierung und eigene programmgesteuerte Integration. Definieren Sie für jede Klasse Identität, Berechtigungen, Budget, Evidenz und Stop Condition. Es gewinnt der einfachste Pfad, der Quality-, Authority- und Cost-Gates reproduzierbar besteht.

• Mensch, lokale oder IDE-Session und Plan-Kontingent → mit ChatGPT-Anmeldung beginnen.
• API-Projekt, Service-Credential, eigenes Metering oder App-Integration → API-Key oder Workload Identity prüfen.
• Codex Cloud oder Review → Repository-Verbindung, Workspace-Policy und Usage Receipt separat prüfen.
• Gemischter Modus → stillen Payer-Fallback verbieten und Routing dokumentieren.

OpenAI trennt die Anmeldung mit ChatGPT ausdrücklich von der Nutzung eines eigenen API-Keys. Verlassen Sie sich nach einem Wechsel der Authentifizierungsmethode weder auf einen alten Terminal-Prompt noch auf eine aktive Subscription. Bewahren Sie einen Beleg ohne Secrets auf: Client und Version, Authentifizierungsmethode, maskiertes Organisations- oder Workspace-Label, aktives Modell, Repository, Sandbox-Profil, Zeitstempel und die Usage-Seite, auf der die Belastung erwartet wird. Prüfen Sie in der CLI den aktuellen Zustand vor dem ersten relevanten Lauf.

Bauen Sie einen Negativtest in einem Wegwerfprojekt: Hinterlegen Sie ein inaktives Test-Credential in einem kontrollierten Shell-Profil und prüfen Sie, dass der Operator die Abweichung vor der Ausführung erkennt. Schreiben Sie Tokens nie in Logs, Screenshots, Issues oder Article Evidence. Nutzen Sie für Automation die engste verfügbare Projekt- oder Service-Identität sowie Rotation und Revoke-Test; eine menschliche OAuth-Session darf nicht unbemerkt zur gemeinsamen Maschinenidentität werden.

Codex mit einem ChatGPT-Account nutzt Kontingent und Billing des jeweiligen Plans; zusätzliche Credits und Reset-Verhalten hängen von Plan und Workspace ab. Codex mit eigenem API-Key nutzt API-Preise und Limits des API-Projekts. Selbst wenn beide Pfade Tokens messen, können Rate Card, enthaltene Nutzung, Cache, Tool-Gebühren, Budget Owner und maßgebliche Rechnung unterschiedlich sein. Verwechseln Sie eine Dashboard-Schätzung nicht mit der Finanzrechnung.

Vergleichen Sie die Kosten akzeptierter Tasks mit demselben Commit, Task-Set, denselben Anweisungen, derselben Modellklasse, Reasoning-Policy, Netzwerkgrenze und Reviewer-Rubrik. Erfassen Sie Input, Cached Input, Output, Tool-Aktivität, Retries, parallele Worker, Review-Minuten, akzeptiertes Ergebnis und Unterbrechung. Veröffentlichen Sie keinen Vendor-Durchschnitt als Prognose für Ihr Team. Ändert sich der Task zwischen den Pfaden oder erhält ein Lauf einen warmen Cache, markieren Sie den Vergleich als ungültig und wiederholen Sie ihn.

• Plan-Beleg → Workspace, Kontingent oder Credit Pool, Reset-Status und akzeptiertes Artefakt.
• API-Beleg → Organisation, Projekt, Modell, Nutzung, Budgetstatus und Rechnungsquelle.
• Unklarer Abschluss → zuerst Git-Status und Side Effects prüfen, dann über Retry entscheiden.
• Preis- oder Modelländerung → datiertes Manifest aktualisieren statt einer alten Tabelle aus dem Gedächtnis zu vertrauen.

Interaktives lokales Codex kann Approval anfordern, einen Diff anzeigen und in einer Sandbox neben dem Menschen arbeiten. Ein delegierter Cloud-Task hängt von verbundenem Repository, Environment und Workspace-Kontrollen ab. Nichtinteraktives `codex exec`, GitHub Action oder das Codex SDK bringen zusätzlich maschinenlesbaren Output, maximale Laufzeit, Concurrency, Retry und Partial-Completion-Risiken. Derselbe Login macht diese Oberflächen nicht operativ gleichwertig.

Erstellen Sie für jeden Modus ein Execution Manifest: Source Commit, beschreibbare Pfade, Netzwerk-Policy, Secret-Quelle, erlaubte Befehle, Approval-Policy, Output-Schema, Timeout, Idempotency Key, Validation Commands und Merge Authority. API-Billing erleichtert Project Metering, begrenzt Shell Authority aber nicht automatisch. Eine ChatGPT-Workspace-Policy kann nützliche Admin-Kontrollen liefern, ersetzt jedoch weder Branch Protection noch ein unabhängiges Deployment-Gate.

Bei Business, Enterprise oder Edu prüfen Sie Membership, Rolle, Modellverfügbarkeit, Managed Configuration, Data Controls, Repository Connector und Audit Surface als getrennte Entitlements. Für die API prüfen Sie Organisations- und Projektrollen, Service Accounts, Spend Limits, Modellberechtigungen und Key Lifecycle. Das Entfernen eines Seats beweist keinen Revoke eines API-Credentials; das Löschen eines API-Keys trennt ein GitHub-Repository nicht von Codex Cloud.

Führen Sie einen Joiner-Mover-Leaver-Test mit einem synthetischen Benutzer durch. Der Joiner erhält nur das benötigte Repository und den benötigten Modus; der Mover verliert altes Projekt und alte Policy; der Leaver verliert ChatGPT Workspace, API-Projekt, Repository-Verbindung, gecachte Credentials und Automation Schedule. Security speichert zeitgestempelte Belege statt Secrets. Jeder verbleibende Pfad zu einem Write oder billable Run blockiert den Rollout.

Wählen Sie 12–20 repräsentative Tasks: Repository-Erklärung, Bugfix, Multi-File-Refactor, Test-Reparatur, Dependency-Untersuchung, Review und korrekte Ablehnung bei unzureichender Evidenz. Führen Sie sie in Woche eins über den freigegebenen ChatGPT-Pfad und in Woche zwei über ein begrenztes API-Projekt aus. Fixieren Sie Commit, Client-Version, Modellklasse, Konfiguration, Task-Reihenfolge und Acceptance-Rubrik. Erfassen Sie vor jedem Lauf einen Authentifizierungsbeleg und danach Diff, Checks, Completion State und Billing Source.

Ergänzen Sie Failure Fixtures: ausgeschöpftes Kontingent, API-Budgetgrenze, widerrufener Benutzer, widerrufener Key, Network Denial, Approval Refusal, Timeout nach möglicher Änderung und beschädigter maschinenlesbarer Output. Der Pilot besteht, wenn die Payer-Attribution reproduzierbar ist, kritische Tasks abschließen oder fail-closed enden, Finance die Nutzung abstimmen kann und Reviewer keine Verschlechterung der Acceptance sehen. Das Ergebnis wählt ein Betriebsmodell; es beweist keine universelle Produktüberlegenheit.

• Freeze → Commit, Task-Set, Modellklasse, Policy und Acceptance-Kriterien.
• Observe → Authentifizierung, Zahler, Tokens oder Kontingent, Tools und Completion State.
• Review → Korrektheit, Regressionen, Korrekturzeit und Qualität der Evidenz.
• Reconcile → Client-Beleg gegen maßgebliches Plan- oder API-Dashboard.
• Decide → Pfad mit geringster Komplexität, der die kritischen Gates besteht.

Inventarisieren Sie vor der Migration Codex-Konfiguration, AGENTS.md, Skills, MCP Server, Environment Variables, Repository Connections, Cloud Environments, Automation Schedules, Model Settings und Policy Sources. Kopieren Sie kein Credential zwischen Pfaden: Stellen Sie es beim Ziel-Owner mit minimalem Scope neu aus. Führen Sie nach dem Cutover einen Read-only-Canary aus, prüfen Sie Authentifizierungsbeleg, Sandbox, Netzwerk und Billing Destination und erlauben Sie erst danach einen Patch-Task.

Im gemischten Modell muss Routing deterministisch sein: zum Beispiel menschliches lokales Pairing über Workspace Sign-in, CI Proposal über ein API-Projekt und Merge nur über Branch Protection. Verbieten Sie Fallback auf persönliche Keys oder Accounts. Rollback stellt den vorherigen freigegebenen Auth-Pfad wieder her, deaktiviert neue Schedules, widerruft das neue Credential und stimmt offene Nutzung sowie Side Effects ab.

Dokumentieren Sie Decision Owner, Workload-Klassen, benötigte Oberflächen, Identitätsquelle, Datengrenze, Modellberechtigung, Kontingent oder API-Budget, Concurrency, Audit-Anforderungen, Approval-Policy, Repository-Scope, Exit Owner und Review Date. Verlinken Sie aktuelle offizielle Dokumentation, statt veränderliche Limits und Preise zu kopieren. Werte, die nicht in Ihrem Account oder Vertrag stehen, markieren Sie als `unknown`.

Wählen Sie den ChatGPT-Pfad, wenn er die benötigten interaktiven oder kontrollierten Codex-Oberflächen mit klarem Kontingent und Workspace Lifecycle abdeckt. Wählen Sie den API-Pfad für eine separate programmatische Billing- und Identitätsgrenze, wenn Workload und Bedingungen das unterstützen. Ein gemischter Pfad ist nur mit explizitem Routing, unabhängigen Budgets, Credential Isolation und getestetem Revoke akzeptabel. Prüfen Sie die Entscheidung nach Änderungen an Plan, Pricing, Rate Card, Modell, Client, Policy oder Automation Surface erneut.