ChatGPT y Codex compartirán una asignación en diciembre: cómo planificar con el nuevo modelo de uso

Qué cambiará OpenAI en diciembre

OpenAI está llevando a los suscriptores Plus, Pro y Business hacia un modelo de uso compartido en el que ChatGPT y Codex consumen la misma asignación basada en tokens. El cambio práctico es que los dos productos dejarán de planificarse como reservas de capacidad completamente independientes. Además, el trabajo se está incorporando a la experiencia principal de ChatGPT, por lo que la actividad que antes se percibía como un flujo de trabajo separado irá quedando cada vez más integrada con el uso habitual de ChatGPT.

Eso no significa que todas las interacciones consuman la asignación de la misma manera. El chat instantáneo queda excluido de este cambio, mientras que los modelos avanzados y las tareas más exigentes utilizan la capacidad compartida. En la práctica, la asignación pretende reflejar el peso computacional de una solicitud, en lugar de limitarse a contar cuántas veces pulsa Enviar el usuario. Por eso, un intercambio breve con un modelo ligero y una ejecución prolongada de Codex pueden tener efectos muy distintos sobre el saldo restante, aunque ambos comiencen como una sola solicitud del usuario.

La distinción importa porque el nuevo modelo conecta dos formas de trabajo que muchos suscriptores han tratado por separado. Una persona puede dedicar parte de la capacidad disponible a pedirle a ChatGPT que analice un problema difícil y después usar Codex para inspeccionar un repositorio, hacer cambios o ejecutar una secuencia más larga de tareas de programación. Con una asignación compartida, esas actividades compiten por la misma capacidad total. Un periodo de uso intensivo en un producto puede reducir el margen disponible en el otro, lo que vuelve más importante planificar el uso para quienes combinan habitualmente investigación, análisis, redacción y trabajo de software.

El cambio debe entenderse como una dirección anunciada y un marco de políticas, no como una calculadora completa para cada cuenta. OpenAI ha descrito la asignación compartida basada en tokens y el tratamiento diferenciado del chat instantáneo, los modelos avanzados y el trabajo complejo, pero la experiencia exacta todavía puede depender del plan y de la cuenta. Es posible que detalles como la asignación visible para un suscriptor concreto, la forma en que se muestra el uso y el efecto preciso de un flujo de trabajo determinado no estén publicados en una única tabla universal para todas las cuentas.

Esa incertidumbre es una razón para consultar la información de uso de la cuenta, en lugar de basarse en una suposición sencilla sobre el número mensual de mensajes. La cuestión relevante no es solo cuántas solicitudes envía una persona, sino qué modelos selecciona y qué tipo de trabajo ponen en marcha esas solicitudes. Una petición rutinaria puede influir poco en la capacidad si se la compara con una tarea larga, asistida por herramientas o de tipo agéntico. Cuando el modelo de diciembre entre en vigor, el cambio mental más útil será tratar ChatGPT y Codex como consumidores conectados de una misma asignación, mientras se consultan los indicadores de uso del producto para conocer los límites que realmente se aplican.

Para quienes usan ChatGPT de forma ligera, esto puede parecer un cambio administrativo menor. Para los suscriptores que utilizan Codex intensivamente o alternan entre sesiones exigentes de ChatGPT y flujos de trabajo de programación, plantea un problema de planificación directo: la capacidad gastada en un tipo de trabajo puede afectar al otro. Las secciones siguientes analizan por qué los totales de mensajes son una métrica débil para planificar, cómo organizar el trabajo alrededor de la asignación compartida y qué opciones de respaldo documenta OpenAI cuando la capacidad disponible no es suficiente.

Por qué el número de mensajes se está convirtiendo en una métrica de planificación deficiente

Un recuento fijo de solicitudes se está convirtiendo en una forma poco fiable de estimar cuánto trabajo queda disponible en ChatGPT y Codex. La unidad relevante no es simplemente el número de veces que el usuario pulsa Enviar. Las indicaciones de uso de OpenAI vinculan el consumo con el trabajo realizado: el modelo seleccionado, la cantidad de razonamiento solicitada, el tamaño del contexto, las herramientas utilizadas y la duración o complejidad de la tarea pueden modificar la cantidad de asignación que consume una ejecución. Por tanto, dos solicitudes que parecen similares dentro de una conversación pueden tener efectos muy distintos sobre la capacidad restante.

Esto importa porque un mensaje es solo la envoltura visible de una carga de trabajo. Una solicitud breve para reescribir un párrafo o explicar un concepto conocido puede resolverse rápidamente, con poco contexto y un uso limitado de herramientas. Una tarea de programación puede ser muy distinta aunque empiece con un solo aviso: el modelo quizá tenga que inspeccionar un repositorio, seguir referencias entre archivos, razonar sobre posibles cambios, ejecutar comprobaciones, revisar su enfoque y continuar hasta completar el resultado solicitado. El recuento de mensajes sigue siendo uno, pero el trabajo subyacente es más largo y exigente. Tratar esas interacciones como equivalentes hace que un presupuesto diario o semanal de avisos parezca más preciso de lo que realmente es.

La elección del modelo es una de las razones más claras por las que el modelo mental anterior deja de funcionar. Un modelo más rápido y económico puede ser adecuado para redactar, transformar, extraer información o realizar ediciones sencillas, mientras que uno más capaz puede resultar útil cuando la tarea depende de un razonamiento más profundo o de un trabajo sostenido. También importa el esfuerzo de razonamiento: pedirle a un modelo que dedique más esfuerzo a un problema difícil no equivale a solicitar una respuesta breve. Un usuario que envía menos avisos, pero utiliza un modelo exigente con un alto esfuerzo de razonamiento, puede consumir más asignación que alguien que envía muchas solicitudes pequeñas con una configuración más ligera.

El contexto introduce otra fuente de variación. Un aviso que incluye una pequeña cantidad de texto proporciona al modelo menos material que procesar que una solicitud acompañada de una conversación extensa, una base de código grande, documentos o instrucciones detalladas. Las herramientas añaden trabajo adicional. Buscar, ejecutar código, utilizar recursos conectados o llevar a cabo una ejecución en la nube puede convertir un solo turno conversacional en una secuencia de operaciones. Por tanto, el efecto total depende de lo que el modelo tenga que leer y hacer, no solo del número de mensajes que aparecen en la interfaz. Las entradas y salidas más grandes, los pasos múltiples y los modos de funcionamiento más rápidos también pueden afectar al uso.

La duración de la tarea es especialmente importante en el trabajo agéntico. En un intercambio normal, el usuario pregunta, el modelo responde y la interacción termina. En un flujo de trabajo agéntico, el sistema puede seguir trabajando en un objetivo más amplio: planificar, inspeccionar las entradas, aplicar cambios, comprobar el resultado y responder a condiciones intermedias. Por eso, una tarea prolongada de Codex puede consumir capacidad con el paso del tiempo aunque el usuario no envíe una sucesión de avisos separados. Las tareas en la nube pueden consumir más asignación que los mensajes locales, lo que convierte el recuento de mensajes en un indicador todavía menos fiable del trabajo realizado.

Una comparación práctica resulta útil. Pensemos en dos usuarios que inician diez interacciones cada uno. Uno las dedica a preguntas breves, resúmenes cortos y pequeñas ediciones. El otro inicia diez tareas de software que requieren contexto del repositorio, llamadas a herramientas, razonamiento repetido y ejecución en la nube. Su actividad visible es idéntica solo al nivel de los mensajes. El consumo de su asignación puede no serlo. El segundo usuario debería esperar que la capacidad varíe según el tamaño y la duración de cada ejecución, en lugar de asumir que diez interacciones representan una cantidad estable de trabajo.

La mejor señal para planificar es el panel de Uso y la información sobre la asignación que aparece en la cuenta. Las indicaciones de OpenAI recomiendan consultar Ajustes → Uso para comprobar el uso combinado restante y los momentos de restablecimiento, en vez de convertir el total de mensajes en una cuota fija. Esa vista puede mostrar si un modelo o flujo de trabajo concreto está consumiendo capacidad más rápido de lo previsto, algo más útil que contar avisos a posteriori. También ofrece un lugar donde comprobar la disponibilidad restante antes de iniciar un trabajo que pueda prolongarse o requiera mucho contexto.

Esto cambia la forma en que deben analizarse los límites dentro de un equipo. «¿Cuántos avisos tenemos?» ya no es una pregunta operativa suficiente. Resulta más útil preguntar: ¿qué modelos se están utilizando?, ¿cuánto razonamiento requieren normalmente las tareas?, ¿qué tamaño tiene el contexto de trabajo?, ¿qué herramientas o rutas de ejecución en la nube intervienen?, y ¿cuánto suelen durar las ejecuciones? Esas respuestas ayudan a explicar por qué la asignación de una persona puede disminuir más rápido que la de otra aunque ambas parezcan enviar un número similar de mensajes.

También sugiere un hábito sencillo para los usuarios individuales: comprobar la capacidad al comienzo de una sesión sustancial, no solo después de alcanzar un límite. Si la tarea es exploratoria, divídela en etapas claras para que sea más fácil observar el progreso y el consumo. Si es rutinaria, evita usar por defecto un flujo de trabajo de alto esfuerzo. Si el primer resultado queda incompleto, revisa las instrucciones, los archivos disponibles y los permisos antes de limitarte a aumentar el esfuerzo de razonamiento; un esfuerzo adicional no puede aportar información ni acceso que la tarea no tenga.

La idea central es que el número de mensajes describe la actividad de la conversación, mientras que la asignación compartida mide un conjunto más amplio de trabajo del modelo. La selección del modelo, el esfuerzo de razonamiento, el tamaño del contexto, las herramientas, la ejecución en la nube y la duración de la tarea se sitúan entre el prompt y la capacidad consumida. Una vez reconocidos esos factores, el panel de Uso se convierte en el punto de referencia práctico: refleja la posición real de la cuenta con más fiabilidad que un simple recuento de mensajes.

Una política operativa práctica para usuarios y equipos

La respuesta más útil ante una asignación compartida es tratar la elección del modelo como una decisión presupuestaria. Usa el modelo de razonamiento más potente cuando el problema sea realmente difícil, el coste de un error sea elevado o la tarea requiera un trabajo agéntico sostenido. Para redactar, reformular, dar formato, hacer ediciones rutinarias y aplicar cambios de código previsibles, elige una opción de menor coste cuando esté disponible. El objetivo no es que cada solicitud sea lo más barata posible, sino reservar la capacidad escasa para el trabajo que realmente se beneficia de ella. OpenAI recomienda elegir el modelo según la capacidad necesaria, y señala que los distintos modelos y ajustes consumen cantidades diferentes de la asignación. Guía de uso de OpenAI

Una regla sencilla de comprobación previa resulta útil. Clasifica cada tarea como rutinaria, investigativa o intensiva en ejecución. Una solicitud rutinaria puede ser una breve reescritura, la extracción de información o una pequeña edición de código. Una solicitud investigativa puede implicar rastrear un error difícil, comparar alternativas o trabajar con un contexto amplio. Una solicitud intensiva en ejecución puede incluir varias llamadas a herramientas, ejecución en la nube, cambios en un repositorio o un flujo de trabajo prolongado en Codex. Las dos últimas merecen una comprobación de la asignación antes de iniciarse. Esto resulta más útil que contar prompts, porque el uso depende del modelo, del tamaño de la entrada y la salida, de los ajustes de razonamiento, del modo de velocidad y del número de pasos implicados. OpenAI afirma explícitamente que la asignación no corresponde a un número fijo de mensajes o tareas. Gestión del uso en Work y Codex

Los trabajos grandes deberían dividirse en etapas, con un punto de parada visible entre ellas. En lugar de pedir a un agente que investigue, implemente, pruebe, documente y revise en una sola ejecución ininterrumpida, separa esas fases. Primero solicita un diagnóstico y un cambio propuesto. Revisa el alcance antes de pedir la implementación. Después ejecuta las pruebas o comprobaciones, y solicita la limpieza o la documentación solo cuando el resultado sea sólido. Así, el usuario tiene varias oportunidades de inspeccionar el progreso, detener una línea improductiva y decidir si la siguiente etapa merece la asignación restante. También se crea un registro más claro de dónde se consumió la capacidad cuando una tarea se amplía de forma inesperada.

La misma disciplina se aplica al trabajo habitual en ChatGPT. Redacta el esquema, aprueba la dirección y después pide que se desarrolle; no regeneres una y otra vez una respuesta larga cuando baste con una revisión específica. Cuando una conversación haya acumulado mucho contexto, traslada los requisitos esenciales a un informe de trabajo compacto antes de continuar. En Codex, define desde el comienzo de la sesión el área del repositorio, las comprobaciones de aceptación y el entregable esperado. Unos límites precisos reducen los turnos exploratorios y facilitan detenerse cuando el resultado solicitado ya se ha verificado. Estas prácticas no pueden garantizar un ahorro concreto, porque el uso real sigue dependiendo del modelo seleccionado y del trabajo realizado.

Los equipos necesitan una capa adicional de responsabilidad. Un espacio de trabajo Business debería decidir quién se encargará de supervisar el uso, revisar las ejecuciones inusualmente grandes y comunicar cuándo el saldo compartido se está consumiendo más rápido de lo previsto. Esa responsabilidad no debería recaer en la primera persona que vea una advertencia. Un responsable puede distinguir entre un proyecto legítimo de alto valor, una repetición accidental, un trabajo agéntico descontrolado o una tarea que debería haberse dividido en etapas más pequeñas.

Los administradores del espacio de trabajo deberían combinar esa responsabilidad con los controles de gasto disponibles y una política clara para los créditos compartidos. El tipo de asiento importa: quienes necesitan principalmente conversar y hacer ediciones ligeras no tienen por qué seguir el mismo patrón operativo que quienes ejecutan Codex sobre bases de código importantes. El espacio de trabajo puede establecer expectativas sobre qué trabajos forman parte del plan compartido, cuándo un usuario debe detenerse para una revisión y si el uso adicional es apropiado para un proyecto. OpenAI documenta controles administrativos para los modelos predeterminados de Codex, los ajustes de razonamiento, la velocidad, Fast Mode y el acceso a la nube, pero los controles disponibles dependen del plan, el rol y la configuración del espacio de trabajo. Los equipos deberían comprobar qué aparece en sus propios ajustes antes de fijar un límite interno estricto. Uso de Codex con un plan de ChatGPT

Una revisión sencilla puede convertir esta política en algo medible. Comprueba qué modelos se utilizaron, qué proyectos generaron ejecuciones largas, dónde se repitió el trabajo y si a los usuarios les sorprendió la cuota restante. Después, ajusta el flujo de trabajo: traslada la redacción rutinaria a un modelo más ligero, añade un punto de aprobación antes de las tareas que exigen mucha ejecución o asigna un responsable claro a cada proyecto. Antes de iniciar una tarea grande, OpenAI recomienda consultar Ajustes → Uso para ver la cuota restante y los horarios de restablecimiento. Esa pequeña pausa ofrece a las personas y a los equipos una decisión práctica: empezar ahora, reducir el alcance de la tarea o aplazarla hasta que haya capacidad disponible. Consultar el uso y los horarios de restablecimiento

Créditos, restablecimientos, privacidad y cuándo conviene otra configuración

La cuota compartida es más fácil de gestionar si se entiende como un presupuesto de capacidad, no como el derecho a un número fijo de prompts. Si una cuenta alcanza un límite, la primera alternativa suele ser operativa: esperar al restablecimiento correspondiente. OpenAI describe distintas ventanas de restablecimiento para diferentes límites, incluidas ventanas de cinco horas y semanales, por lo que la pregunta relevante no es simplemente si un usuario se ha quedado “sin cuota” durante el mes. Lo importante es saber qué asignación se agotó, cuándo se restablece y si la tarea puede esperar hasta entonces. Por eso, la vista de Uso es el lugar práctico para consultar la capacidad restante y el próximo restablecimiento, en vez de calcularla a partir del número de mensajes del día anterior.

Los créditos ofrecen otra vía documentada para los usos que cumplen los requisitos. Pueden ampliar el acceso cuando la cuota incluida no es suficiente, pero no convierten el uso del plan de ChatGPT en un fondo ilimitado ni eliminan la diferencia entre productos. Antes de confiar en los créditos para una ejecución larga de Codex, comprueba que la cuenta, el plan y la carga de trabajo sean aptos, y asegúrate de que el gasto previsto sea visible para la persona responsable de la cuenta. Un poco de capacidad adicional puede ser útil para una fecha límite puntual; si el mismo equipo agota la cuota con frecuencia, no sustituye adecuadamente una política operativa repetible.

Esta diferencia es especialmente importante para los equipos. Los espacios de trabajo Business necesitan una responsabilidad clara sobre la supervisión del uso: alguien debería saber dónde se muestra la capacidad restante del espacio de trabajo, qué asientos consumen recursos compartidos y qué controles de gasto se aplican. De lo contrario, un equipo puede interpretar un límite que parece personal como un problema individual, cuando la restricción real es compartida. La visibilidad a nivel de cuenta también tiene una dimensión de privacidad. Los administradores y propietarios del espacio de trabajo pueden necesitar información de uso para controlar la capacidad, mientras que los usuarios individuales deberían entender qué información es visible dentro de su espacio de trabajo y qué permanece separado de su cuenta privada. El modelo compartido puede simplificar la administración, pero también hace que los límites entre cuentas sean más importantes.

Cambiar de plan es la siguiente opción cuando los reinicios y los créditos válidos no se ajustan a la carga de trabajo. La decisión debería basarse en un patrón de uso, no en una sola tarea inusualmente grande. Un usuario ocasional de ChatGPT que a veces pide código o un análisis breve normalmente tendrá pocos motivos para rediseñar su configuración: usar la asignación incluida, elegir los modelos de forma deliberada y esperar al reinicio cuando el trabajo no sea urgente. En cambio, un usuario intensivo de Codex debería comprobar si la capacidad compartida del plan admite la duración y la frecuencia de sus tareas reales en repositorios antes de convertirlo en su entorno predeterminado. La prueba relevante es el trabajo sostenido en condiciones normales, no un único prompt exitoso.

Una clave de API es una alternativa independiente para las cargas de trabajo que necesitan un control predecible y programático. El uso de la API tiene una facturación propia, por lo que no debe describirse como otra forma de gastar la asignación del plan de ChatGPT. Esa separación puede ser útil cuando un equipo necesita su propio presupuesto, medición a nivel de aplicación o un flujo de trabajo que no dependa del ciclo de reinicio de una cuenta interactiva. También introduce un modelo de costes diferente y una mayor responsabilidad de supervisión. La disyuntiva no es simplemente «suscripción frente a API», sino capacidad interactiva incluida frente a consumo facturado por separado y gestionado de forma deliberada.

También existe una salvedad estratégica: consolidar ChatGPT y Codex en torno a una única asignación a nivel de cuenta aumenta la comodidad, pero puede incrementar la dependencia de los límites de producto, los paneles, las reglas de reinicio y los cambios de plan del proveedor. Los equipos con cargas de trabajo predecibles deberían llevar un registro sencillo del volumen de tareas, la elección del modelo, la duración de las ejecuciones y el uso observado de la asignación durante la transición. Ese registro facilita decidir si se justifica un plan superior, créditos o un flujo de trabajo con API facturada por separado, y evita que una sensación imprecisa de escasez determine la decisión.

La recomendación práctica es sencilla. Prueba la configuración compartida si tu trabajo consiste principalmente en conversaciones ligeras, programación ocasional y tareas que pueden tolerar un reinicio; probablemente el modelo será lo bastante cómodo sin una planificación especial. Pruébala con cautela si Codex es fundamental en tu jornada: reserva capacidad para las ejecuciones importantes, consulta el panel antes de iniciar trabajo agéntico y mantén los créditos o una ventana de reinicio como opciones de respaldo explícitas. Evita convertirla en la única vía de producción si tu equipo tiene cargas predecibles y de gran volumen, o necesita una asignación estricta de costes; evalúa en su lugar un plan superior o una configuración de API facturada por separado. En cualquier caso, mantén clara la frontera: el uso del plan de ChatGPT y el uso de la API son presupuestos diferentes, y la configuración adecuada es aquella cuyos límites tu flujo de trabajo puede observar y gestionar.