Estoy usando Claude Code para todo lo demás, menos para programar
Diecinueve días después de cancelar Claude Max, mi patrón ya se asentó. Codex con GPT-5.4 en xHigh se quedó con el asiento de programación. Claude Code con Opus 4.7 en xHigh se quedó con todos los demás asientos del escritorio.
El 3 de abril de 2026 dije que volvería en 30 días para contar la verdad sobre lo que había pasado después de cancelar Claude Max.
Estoy volviendo once días antes.
No porque sea impaciente. Sino porque el patrón ya quedó claro, y sentarme sobre la respuesta hasta el 2 de mayo sería más teatro que otra cosa.
El remate suena raro al principio. Una herramienta llamada Claude Code ahora es la herramienta que uso para casi todo excepto code.
La versión corta es esta:
- Codex con GPT-5.4 en xHigh thinking se quedó con el asiento de programación.
- Claude Code con Opus 4.7 en xHigh se quedó con todos los demás asientos de mi escritorio.
- La historia de "Codex barato" se rompió en cuanto aparecieron los límites reales.
Si quieres la tesis más limpia posible, probablemente sea esta:
Codex-GPT-5.4 en xHigh para todo lo relacionado con code. Claude Code con Opus 4.7 en xHigh para todo lo demás.
Es una división más nítida de lo que esperaba hace diecinueve días.
Y también es una respuesta más cara y más reveladora a nivel psicológico de lo que imaginaba.
Lo primero que se rompió no fue la calidad del code
Cuando escribí el post de cancelación, la historia simple era atractiva:
- Claude Max: $200/mes
- Codex / ChatGPT: $20-25/mes
- la brecha de calidad de ejecución se estaba cerrando muy rápido
- la confiabilidad de OpenAI se veía más fuerte
Eso parecía un downgrade fácil.
No lo fue.
Lo primero que se rompió no fue la arquitectura, ni la calidad de los planes, ni la disciplina de ejecución.
Fue la historia de los límites.
Mi cronología real se pareció más a esto:
- Apr 6: Me di de alta en dos asientos de ChatGPT Business a $25/mes cada uno, con facturación mensual.
- Apr 6: Ya estaba pensando en términos de workarounds. Para mantener más o menos el mismo ritmo de programación, sospechaba que iba a necesitar unas tres cuentas con capacidad de Codex.
- Apr 10: Después de unos días intentando vivir dentro de esa configuración, ya tenía suficiente evidencia para decirlo en voz alta: tres cuentas baratas seguían sin recrear lo que el plan Claude Max me había dado en su mejor momento.
- Apr 12: Compré ChatGPT Pro por $100/mes porque cuanto más usaba Codex para programación pura, más GPT-5.4 quería en razonamiento high y xHigh, no menos.
Esa es la primera corrección honesta al post del 3 de abril.
El reemplazo no fue "$200 de Claude Max se convierten en $20 de Codex".
Fue algo más parecido a esto:
- "Ya no necesito el mismo plan de Anthropic que antes."
- "Sí necesito más capacidad de Codex de la que da el tier barato."
- "La comparación real es la calidad del workflow bajo límites reales, no screenshots de benchmarks."
Mi lectura actual es que OpenAI probablemente está siendo agresivo con los límites porque quiere cuota de mercado. Esa es una inferencia, no información interna. Si eso es cierto, la ventana puede no quedarse abierta para siempre.
Así que, si basas toda tu decisión en la economía de hoy de $20, al menos deberías admitir que el entorno de pricing puede ser táctico, no estable.
Codex se quedó con el asiento de programación
La mayor lección para mí es que GPT-5.4 en xHigh thinking se siente como un especialista en programación.
No uno carismático.
No uno cálido.
Ni especialmente interesado en hacerse tu amigo.
Pero sí un especialista.
Hay una austeridad en Codex que terminé apreciando más de lo que esperaba. Se siente como trabajar con un ingeniero sobrio, metódico y cuidadoso, que no está intentando actuarte una personalidad.
Eso importa más de lo que pensé durante jornadas largas.
El momento más claro para mí fue el 17 de abril. Le di a Codex-GPT-5.4 en xHigh un plan acordado y lo dejé trabajar. Corrió durante treinta a cuarenta y cinco minutos en una sola sesión, siguiendo el plan de cerca, escribiendo y ejecutando unit tests, integration tests y browser tests en local, sin que yo tuviera que estar encima todo el tiempo.
No he tenido otra herramienta que haga eso para mí con la misma consistencia.
Eso cambió cómo pienso sobre Codex. Ya no es solo "lo bastante bueno para tareas pequeñas". Es capaz de una ejecución larga y disciplinada cuando el plan está claro.
Para trabajo de programación pura, ahora recurro a Codex casi todo el tiempo:
- arquitectura
- implementación
- debugging
- diseño de evals
- framing de tests
- limpieza de pipelines
- lógica de producto pensada para producción
El mejor ejemplo de abril es Prova.
La mayor parte del trabajo útil en Prova no fue glamoroso. No fue "mira qué inteligente es el modelo". Fue:
- evaluar sprints componibles
- endurecer la lógica de onboarding
- encontrar contradicciones entre la generación de roadmap y el estado del sprint asignado
- mejorar el producto a partir de filas reales de usuarios y comportamiento real en producción
Ese tipo de trabajo resulta encajar muy bien con Codex.
Es competente, minucioso y sorprendentemente agudo cuando el trabajo es:
- identificar la contradicción
- aislar el bug lógico
- separar corrección de territorio RFC
- recomendar el siguiente movimiento más pequeño que todavía sea defendible
Uno de los ejemplos más claros salió de una sola fila de producción de Prova para un usuario con intención de builder.
El sistema había:
- etiquetado a un usuario con intención de builder como
marketing_vp - asignado
table-stakes-diagnostic - generado un roadmap que empezaba más adelante en el recorrido
- mostrado una tarjeta de Context Check inmediatamente después del onboarding
Lo que volvió útil ese episodio no fue solo el diagnóstico, sino el loop de revisión cruzada.
Opus 4.7 me llevó a los tres primeros problemas:
- un bug de cálculo de track
- un bug de timing
- una pregunta de builder-opener / RFC
Luego GPT-5.4 empujó el análisis un paso más allá y detectó la contradicción que Opus había pasado por alto:
- el primer sprint asignado y el roadmap generado ya le estaban diciendo dos verdades distintas al mismo usuario
Eso importó. Cambió la conversación de "¿deberíamos shippear ya el Builder RFC?" a "arreglemos primero la contradicción que está viva y luego volvamos al RFC".
No se sintió como un modelo intentando impresionarme. Se sintió como un senior SWE diciendo: arregla primero la contradicción actual y después hablamos de teoría de producto.
Ese patrón se repitió suficientes veces este mes como para que deje de pensar en Codex como "la alternativa más barata". Ahora lo pienso como mi instrumento principal para programar.
Claude Code se quedó con todos los demás asientos
Si la historia terminara ahí, la respuesta sería simple: pásate a Codex y sigue.
Eso no fue lo que pasó.
Claude Code con Opus 4.7 sigue siendo mejor para trabajo donde la salida depende del gusto, o donde el loop es largo, iterativo y pesado en contexto.
Ahí es donde el título de este post deja de sonar contradictorio y empieza a sonar preciso. Claude Code, la CLI a la que antes llegaba por instinto cuando tocaba escribir code, ahora es la herramienta a la que recurro cuando toca hacer cualquier cosa excepto escribir code.
Por "todo lo demás" me refiero a:
- escribir texto que suene a mí
- iterar sobre estructura y ritmo
- naming y positioning
- taglines y lenguaje de marca
- prompts de imagen para las portadas del blog
- exploración de logo e identidad
- mejores pasadas de
/frontend-designcuando el trabajo necesita juicio visual y no solo UI funcional - hilos largos de investigación donde voy construyendo un punto de vista a lo largo de varias sesiones
Por mi experiencia durante estos diecinueve días, eso se ha mantenido verdad una y otra vez.
La brecha se vuelve especialmente obvia cuando hay un loop de feedback.
Tanto Claude como Codex pueden leer posts anteriores, inspeccionar prompts pasados y usar trabajo existente como referencia. Pero cuando estoy haciendo múltiples rondas de refinamiento con feedback después de cada intento, Claude todavía parece entender con más fiabilidad la dirección a la que quiero ir.
Eso aplica a la escritura.
También aplica a los prompts de imagen.
También aplica al naming.
El ejemplo de producto más claro es Prova. Yo no llegué a ese nombre con Codex. Necesité Opus para ese tipo de trabajo. Y lo mismo pasa con mucha exploración de lenguaje de marca. GPT-5.4 me da respuestas sólidas y competentes. Opus me dio un rango creativo más fuerte.
El mismo patrón aparece en el diseño del sitio.
El workflow de /frontend-design bajo Superpowers sigue funcionando mejor para mí con Opus que con GPT-5.4 cuando el trabajo está guiado por diseño y no por ingeniería. Codex me entrega algo funcional. Claude más a menudo me entrega algo que realmente querría shippear con orgullo.
Así que, si la pregunta es:
"¿Codex reemplazó a Claude para todo?"
No.
Lo reemplazó en el asiento de programación. No lo reemplazó para todo lo demás.
Esa distinción importa.
La familiaridad era real, y también lo fue la abstinencia
Llevaba usando Claude Code unos 13 meses.
Ese tiempo te cambia el lenguaje corporal del trabajo, no solo la lista de preferencias.
Cuando me pasé con más decisión a Codex, sí noté una especie de efecto de abstinencia.
No porque Codex fuera malo.
Sino porque era diferente.
Los puntos de fricción eran pequeños, pero persistentes:
- ciertas confirmaciones de permisos
- la sensación de que a veces hacía una pregunta de más
- el tono estéril de algunas respuestas
- la falta de esa "voz" familiar de Claude dentro del loop
No son defectos objetivos.
Son diferencias de workflow.
Y la familiaridad cambia cómo las sientes.
No quiero fingir que atravesé esa transición como un economista puramente racional.
No fue así.
En un momento me descubrí pasando trabajo por Claude solo como una revisión extra de seguridad, no porque necesitara la segunda opinión, sino porque el tirón era más fuerte que mi propia narrativa de "estoy cambiando limpio".
Lo que me enseñó es que la dependencia real no era solo de la capacidad bruta de Claude. Era de la sensación de seguridad que venía de tener otro sistema inteligente dentro del loop en el que confiaba de una manera distinta.
Y esa es también la razón por la que la respuesta final para mí nunca iba a ser "elige uno para siempre".
La psicología del workflow también importa.
Codex también tiene sus propios modos de fallo
Este tramo no fue una sola cadena de victorias de Codex.
También tuve problemas reales.
El primero que se sintió como un problema específicamente de Codex llegó el 14 de abril. En dos sesiones de terminal me apareció este error:
{
"error": {
"message": "Unknown parameter: 'prompt_cache_retention'.",
"type": "invalid_request_error",
"param": "prompt_cache_retention",
"code": "unknown_parameter"
}
}
Ese tipo de cosas importa porque rompe la confianza en la capa del harness, no en la capa del razonamiento.
También noté que Codex parece más estricto con lo que el modelo tiene permitido hacer alrededor de deploy o al tocar producción, incluso después de que ya se habían concedido aprobaciones antes en la sesión.
A veces eso es bueno.
A veces es molesto.
Pero definitivamente forma parte de la experiencia real de usuario.
Un ejemplo pequeño que sí prefiero del lado de Codex: poder revisar estado y límites sin interrumpir el flujo principal. Poder correr /status sin tener que esperar a que termine el trabajo actual es una tontería, pero después de diecinueve días esas pequeñas ergonomías se acumulan.
Eso es lo que quiero decir cuando digo que las herramientas no solo se diferencian por la calidad del output. Se diferencian por la sensación del harness.
La confiabilidad sigue importando, y abril no ayudó al caso de Claude
Una de las razones por las que me sentí cómodo haciendo el cambio en primer lugar fue la confiabilidad.
Ya había escrito sobre la diferencia de estado a 90 días entre Anthropic y OpenAI en el follow-up del 31 de marzo. El cuadro general sigue importando:


Y luego abril sumó otro recordatorio del mundo real.
El 15 de abril, Claude volvió a tener elevated errors en Claude.ai, la API y Claude Code. El login se vio afectado. La API se recuperó primero. Los usuarios de Claude Code que ya estaban logueados pudieron seguir trabajando, pero el propio inicio de sesión estuvo roto durante un rato.
Eso no borra las fortalezas de Claude.
Sí refuerza el caso práctico de no apostar todo tu workflow a un solo proveedor.
Esta sigue siendo una de las lecciones más duraderas de todo el experimento:
Llevar dos herramientas no es solo un lujo. Es resiliencia operativa.
Cuando un proveedor tiene una tarde mala, tú sigues shippeando.
Opus 4.7 afiló el patrón; no lo dio vuelta
Claude Opus 4.7 salió el 16 de abril. Publicar cualquier veredicto honesto sin haberlo probado de verdad no habría sido justo.
Así que casi de inmediato lo puse frente a un diagnóstico de programación real en Prova.
Opus 4.7 me dio un primer pase sólido. Identificó el bug del track, la tarjeta Context Check mal temporizada y la pregunta más amplia sobre el builder-opener.
Luego pasé ese diagnóstico por GPT-5.4 como critique pass, no como una segunda opinión ciega, sino como un reviewer leyendo el análisis escrito de Opus. GPT-5.4 detectó la contradicción más afilada que Opus había pasado por alto: el producto ya estaba asignando un primer sprint mientras generaba un roadmap que empezaba en otro lugar. Eso no era solo un tema de builder fit. Era un problema de corrección vivo.
Después volví a pasar el diagnóstico revisado por Opus y convergió.
La sorpresa llegó en la otra dirección.
El 19 de abril noté algo que no esperaba: para tareas más simples — una revisión corta de code, una ejecución enfocada sobre un cambio pequeño — Opus 4.7 en xHigh es visiblemente más lento que Codex-GPT-5.4 en xHigh. Yo esperaba lo contrario.
Ese detalle volvió a anclar mi patrón.
Donde Opus sigue ganando claramente para mí es en el trabajo pesado en gusto, iterativo y de contexto largo que describí antes. Donde Codex gana claramente es en el diagnóstico profundo de programación y en los giros cotidianos de programación a los que antes habría recurrido con Claude.
Así que la versión honesta es:
- Opus 4.7 todavía puede darme un buen primer pase en análisis de programación más profundo
- en giros de programación más livianos, ahora mismo se siente más lento que GPT-5.4 al mismo nivel de thinking
- combinado con la experiencia de ejecución continua del 17 de abril, eso empujó el asiento de programación todavía más hacia Codex en lugar de acercarlo a un empate
Dónde terminé de verdad
Si le quitas el drama, los screenshots de pricing, los screenshots de outages y el framing de social posts, a fecha del 22 de abril mi patrón de trabajo quedó así:
Para cualquier cosa relacionada con programación
Recurro primero a Codex con GPT-5.4 en xHigh thinking.
Por qué:
- se siente especializado
- es metódico
- es cuidadoso
- maneja bien arquitectura y ejecución
- puede correr un plan acordado completo con unit, integration y browser tests durante tramos de treinta a cuarenta y cinco minutos
- en los giros cotidianos de programación ahora mismo es más rápido que Opus 4.7 en xHigh
- ahora me resulta más fácil confiar en él para trabajo profundo de programación
Para todo lo demás
Recurro a Claude Code con Opus 4.7 en xHigh thinking.
Eso ahora cubre:
- escritura que tiene que sonar a mí
- prompts de imagen para portadas
- naming, positioning y lenguaje de marca
- pasadas de
/frontend-designque necesitan juicio visual - hilos largos de investigación donde voy construyendo un punto de vista a través de varias sesiones
- revisar mis propios planes antes de pasárselos a Codex
- este post
Por qué:
- sigue mejor mi estilo
- maneja mejor la iteración creativa guiada por feedback
- es más fuerte en gusto de marca y gusto de diseño
- sigue siendo el modelo en el que más confío cuando el trabajo es juicio, no ejecución
Para planes importantes de programación
Sigo prefiriendo el loop de revisión cruzada:
- sacar un plan con uno
- hacer que el otro lo critique
- y luego apretarlo a partir de eso
Ese workflow sigue pareciéndome más robusto que apostar por la primera respuesta de un solo modelo, por muy bueno que sea. La fila de builder-intent que recorrí arriba es exactamente la razón por la que me sigue gustando esta configuración.
En pricing
No terminé con el cambio simplista y barato.
Terminé aquí:
- sin querer ya la vieja estructura de Claude Max a $200
- queriendo más capacidad de Codex, no menos
- aceptando ChatGPT Pro a $100 como la respuesta más realista para el plan de programación
- manteniendo a Claude dentro del loop para todo lo que no es code
En shipping
Todo el punto del cambio era seguir shippeando. No fueron diecinueve días de benchmarkear herramientas sin nada que mostrar. En esa misma ventana, la separación Operator/Builder de Prova salió en vivo con un carril real de ejecución para Builder, salieron dos posts largos de blog y corrí una pasada completa de traducción en doce locales. La respuesta a si el experimento me costó output es no.
Si quieres la versión más comprimida:
Cancelé Claude Max, pero no saqué a Claude Code de mi trabajo. Moví a Claude Code fuera del asiento principal de programación y le di el resto del escritorio.
Ese es el resumen más verdadero que puedo darte.
Entonces: ¿tomaría la misma decisión otra vez?
Sí.
Pero ahora la describiría de otra manera.
El 3 de abril, el framing era:
"Cancelé Claude Max y estoy probando si Codex puede reemplazarlo."
El 22 de abril, el framing se parece más a esto:
"Cancelé Claude Max, descubrí que Codex es ahora mismo el especialista en programación más fuerte para mí, y ahora uso Claude Code para todo lo demás en mi escritorio, donde sigue siendo la mejor herramienta que tengo."
Esa respuesta es menos binaria, más cara que la versión simple para redes y bastante más cercana a la verdad.
Preguntas frecuentes
¿Codex realmente reemplazó a Claude para programar?
Para mí, sí. En trabajo de programación pura, Codex con GPT-5.4 en xHigh thinking se convirtió en mi asiento por defecto. Opus 4.7 en xHigh todavía puede darme un buen primer pase en diagnóstico profundo, pero ya no ocupa el asiento principal de programación para mí, y ahora mismo se siente más lento que Codex en giros más ligeros.
¿Se sostuvo la historia de Codex barato?
No del todo. En cuanto lo usé con volumen real, la economía del tier barato dejó de contar toda la historia. Me pasé a un plan de OpenAI más caro porque quería más capacidad, no porque el experimento hubiera fallado.
¿Sigues necesitando Claude?
Sí, si tu trabajo incluye escritura, diseño, naming, prompts de imagen, hilos largos de investigación o cualquier otro loop pesado en gusto o juicio. Opus 4.7 en xHigh se convirtió en el default para todo lo que no es code dentro de mi workflow.
¿Y qué pasa con la confiabilidad?
La brecha de confiabilidad sigue importando. Abril la reforzó. La respuesta no es entrar en pánico. La respuesta es tener cobertura de respaldo.
¿Por qué publicar once días antes?
Porque el patrón ya se asentó. Guardar el post hasta el 2 de mayo solo para honrar el número exacto del titular original habría sido teatro. Lo honesto era decir lo que de verdad estoy haciendo ahora y seguir.
Entonces, ¿qué plan comprarías hoy?
Si tu trabajo es principalmente programación, yo miraría muy en serio Codex / GPT-5.4 primero. Si tu trabajo mezcla programación con mucho trabajo creativo guiado por gusto, yo no querría estar sin Claude. Y si $100 al mes está fuera de alcance ahora mismo, el tier de $20 de Codex sigue funcionando para proyectos individuales más pequeños, solo que vas a tocar límites antes bajo trabajo sostenido y multiproyecto. Mi propia respuesta ahora mismo ya no es una respuesta de una sola herramienta.
Ese es el update honesto de diecinueve días.
Codex se quedó con el asiento de programación.
Claude Code se quedó con todos los demás asientos.
Y por eso una herramienta literalmente llamada Claude Code ahora es la herramienta a la que recurro cuando el trabajo es todo menos code.
Y la lección real, otra vez, es que el workflow importa más que el fandom.
Si hiciste un cambio parecido este mes, me gustaría de verdad saber dónde terminaste tú. ¿Una herramienta ganó de forma absoluta para ti, o tu división también se volvió más nítida?
Un abrazo,
Chandler





