Codex: suscripción vs API para acceso, facturación y automatización

El inicio de sesión con ChatGPT es adecuado para trabajo humano interactivo en Codex CLI, IDE, desktop o superficies cloud cuando la asignación, la pertenencia al workspace y los controles disponibles ya forman parte del plan. Una clave API propia de OpenAI es adecuada cuando el workload debe facturarse a una organización o proyecto API, necesita un límite de gasto separado o se ejecuta mediante un proceso orientado a máquinas. Esto no garantiza modelos, funciones, límites o controles de datos idénticos: registra superficie, cuenta, workspace, método de autenticación, modelo y responsable de facturación antes de probar.

No elijas la API solo porque la tarea sea técnica y no lleves un login personal de ChatGPT a CI solo porque el plan ya esté pagado. Separa primero pairing local, tareas cloud delegadas, code review, automatización programada e integración programática propia. Para cada clase define identidad, permisos, presupuesto, evidencia y condición de parada. Gana el recorrido más simple que supera de forma reproducible los gates de calidad, autoridad y coste.

• Persona, sesión local o IDE y asignación del plan → empieza con inicio de sesión de ChatGPT.
• Proyecto API, credencial de servicio, metering propio o integración de aplicación → evalúa una clave API o workload identity.
• Codex cloud o review → verifica por separado conexión del repositorio, política del workspace y comprobante de uso.
• Modo mixto → prohíbe el fallback silencioso del pagador y documenta el routing.

OpenAI separa explícitamente el inicio de sesión con ChatGPT del uso de una clave API propia. Tras cambiar el método de autenticación, no te fíes de un antiguo prompt del terminal ni del simple hecho de tener una suscripción activa. Guarda un comprobante sin secretos: cliente y versión, método de autenticación, etiqueta enmascarada de organización o workspace, modelo activo, repositorio, perfil de sandbox, timestamp y página de uso donde se espera el cargo. En la CLI verifica el estado actual antes del primer run material.

Construye una prueba negativa en un proyecto desechable: deja una credencial de prueba inactiva en un perfil controlado del shell y verifica que el operador detecta la discrepancia antes de ejecutar. Nunca escribas un token en logs, screenshots, issues o evidencia editorial. Para automatización usa la identidad de proyecto o servicio más limitada disponible, rotación y prueba de revocación; una sesión OAuth humana no debe convertirse silenciosamente en una identidad de máquina compartida.

Codex con una cuenta de ChatGPT utiliza la asignación y facturación del plan correspondiente; los créditos adicionales disponibles y el comportamiento de reset dependen del plan y del workspace. Codex con una clave API propia utiliza los precios de API y los límites del proyecto API. Incluso si ambos recorridos miden tokens, la tarifa, el uso incluido, la caché, los cargos de herramientas, el propietario del presupuesto y la factura autoritativa pueden diferir. No confundas una estimación del dashboard con la factura financiera.

Compara el coste por tarea aceptada con el mismo commit, conjunto de tareas, instrucciones, clase de modelo, política de razonamiento, límite de red y rúbrica del reviewer. Registra input, input cacheado, output, actividad de tools, retries, workers paralelos, minutos de review, resultado aceptado e interrupción. No publiques una media del proveedor como previsión para tu equipo. Si la tarea cambia entre recorridos o un run obtiene caché caliente, marca la comparación como inválida y repítela.

• Comprobante del plan → workspace, asignación o pool de créditos, estado de reset y artefacto aceptado.
• Comprobante API → organización, proyecto, modelo, uso, estado de presupuesto y origen de factura.
• Finalización desconocida → revisa primero el estado de git y los efectos secundarios; después decide el retry.
• Cambio de precio o modelo → actualiza el manifiesto fechado en vez de una tabla antigua de memoria.

Codex local e interactivo puede pedir aprobación, mostrar un diff y trabajar en sandbox junto a una persona. Una tarea cloud delegada depende del repositorio conectado, el entorno y los controles del workspace. `codex exec` no interactivo, GitHub Action o Codex SDK añaden output legible por máquina, tiempo máximo de ejecución, concurrencia, retries y riesgos de finalización parcial. El mismo login no hace equivalentes estas superficies desde el punto de vista operativo.

Crea un manifiesto de ejecución para cada modo: commit fuente, rutas escribibles, política de red, origen de secretos, comandos permitidos, política de aprobación, esquema de salida, timeout, clave de idempotencia, comandos de validación y autoridad de merge. La facturación API facilita el metering por proyecto, pero no limita automáticamente la autoridad del shell. La política del workspace de ChatGPT puede aportar controles administrativos útiles, pero no sustituye branch protection ni un gate de despliegue independiente.

Para Business, Enterprise o Edu verifica pertenencia, rol, disponibilidad de modelos, configuración gestionada, controles de datos, conector de repositorio y superficie de auditoría como entitlements separados. Para la API verifica roles de organización y proyecto, cuentas de servicio, límites de gasto, permisos de modelo y ciclo de vida de claves. Eliminar un seat no demuestra que se haya revocado una credencial API; borrar una clave API no desconecta un repositorio de GitHub de Codex cloud.

Ejecuta una prueba joiner-mover-leaver con un usuario sintético. El joiner recibe solo el repositorio y modo necesarios; el mover pierde proyecto y política anteriores; el leaver pierde workspace de ChatGPT, proyecto API, conexión de repositorio, credenciales cacheadas y schedule de automatización. Seguridad conserva comprobantes con timestamp, no secretos. Cualquier ruta residual hacia escritura o un run facturable bloquea el rollout.

Elige 12–20 tareas representativas: explicación de repositorio, bug fix, refactor multiarchivo, reparación de tests, investigación de dependencias, review y una negativa correcta cuando falta evidencia. La primera semana ejecútalas por el recorrido aprobado de ChatGPT y la segunda por un proyecto API restringido. Congela commit, versión del cliente, clase de modelo, configuración, orden de tareas y rúbrica de aceptación. Antes de cada run captura el comprobante de autenticación; después, diff, checks, estado de finalización y origen de facturación.

Añade fixtures de fallo: asignación agotada, techo de presupuesto API, usuario revocado, clave revocada, denegación de red, rechazo de aprobación, timeout tras un posible cambio y output legible por máquina corrupto. El piloto pasa cuando la atribución del pagador es reproducible, las tareas críticas terminan o fallan de forma cerrada, finanzas puede reconciliar el uso y el reviewer no ve degradación en la aceptación. El resultado elige el modelo operativo; no demuestra superioridad universal del producto.

• Freeze → commit, conjunto de tareas, clase de modelo, política y criterios de aceptación.
• Observe → autenticación, pagador, tokens o asignación, tools y estado de finalización.
• Review → corrección, regresiones, tiempo de corrección y calidad de evidencia.
• Reconcile → comprobante del cliente contra el dashboard autoritativo del plan o API.
• Decide → el recorrido de menor complejidad que supera los gates críticos.

Antes de migrar inventaría configuración de Codex, AGENTS.md, skills, servidores MCP, variables de entorno, conexiones de repositorio, entornos cloud, schedules de automatización, ajustes de modelo y fuentes de política. No copies una credencial entre recorridos: vuelve a emitirla desde el owner de destino con scope mínimo. Tras el cutover ejecuta un canary read-only, verifica comprobante de autenticación, sandbox, red y destino de facturación, y solo entonces permite una tarea de patch.

En un modelo mixto, el routing debe ser determinista: por ejemplo, pairing humano local mediante inicio de sesión del workspace, propuesta CI mediante proyecto API y merge solo mediante branch protection. Prohíbe fallback a una clave o cuenta personal. El rollback restaura la ruta de autenticación aprobada anterior, desactiva nuevos schedules, revoca la nueva credencial y reconcilia uso pendiente y efectos secundarios.

Registra owner de la decisión, clases de workload, superficies necesarias, origen de identidad, límite de datos, elegibilidad de modelos, asignación o presupuesto API, concurrencia, necesidades de auditoría, política de aprobación, scope de repositorio, owner de salida y fecha de revisión. Enlaza documentación oficial vigente en vez de copiar límites y precios mutables. Marca como `unknown` cualquier valor que no figure en tu cuenta o contrato.

Elige el recorrido ChatGPT si cubre las superficies interactivas o gobernadas de Codex necesarias con asignación clara y ciclo de vida del workspace. Elige el recorrido API para una frontera separada de facturación programática e identidad cuando workload y términos lo permitan. Un recorrido mixto solo es aceptable con routing explícito, presupuestos independientes, aislamiento de credenciales y revocación probada. Revisa de nuevo la decisión tras cambios de plan, precios, rate card, modelo, cliente, política o superficie de automatización.