Codex on KnightLi Blog

Cómo elegir entre GPT-5.5, GPT-5.4 y GPT-5.3-Codex

Sun, 10 May 2026 08:43:17 +0800

Si solo quieres la conclusión corta, es bastante simple: usa GPT-5.5 por defecto, elige GPT-5.4 cuando el presupuesto y el consumo importen más, y presta especial atención a GPT-5.3-Codex cuando trabajes en tareas de ingeniería de software de larga duración dentro de Codex o necesites funciones como Cloud Tasks y Code Review.

No es solo una impresión subjetiva. A fecha de 2026-05-10, la documentación oficial de Codex sigue diciendo que la mayoría de las tareas deberían empezar con gpt-5.5; si gpt-5.5 aún no está disponible, conviene seguir con gpt-5.4; y para tareas ligeras o subagentes, gpt-5.4-mini encaja mejor.

Diferencias de posicionamiento entre los tres modelos

Primero conviene mirar la posición oficial de cada uno.

GPT-5.5 es el modelo frontier más reciente dentro de Codex, orientado a programación compleja, uso del ordenador, trabajo de conocimiento y flujos de investigación. Funciona como el modelo principal por defecto para análisis difíciles, tareas de varios pasos, cambios en múltiples archivos, diseño de soluciones y trabajo documental más pesado.

GPT-5.4 es una opción más equilibrada y estable. OpenAI lo describe como un modelo que reúne la capacidad de programación de GPT-5.3-Codex con mejor razonamiento, uso de herramientas y flujos agentic. Es decir, no es simplemente una versión más débil de 5.5, sino una opción más balanceada para usar como base a largo plazo.

GPT-5.3-Codex sigue siendo un modelo muy fuerte para código, pero sus ventajas están más concentradas en la ingeniería de software real y en los flujos nativos de Codex. La documentación oficial también deja claro que está optimizado para agentic coding tasks, mientras que GPT-5.4 ya hereda buena parte de esa fortaleza.

Por eso hoy ya no tiene tanto sentido tratar GPT-5.3-Codex como si fuera automáticamente “el mejor modelo de programación”. En la mayoría de escenarios cotidianos de desarrollo, conviene mirar antes GPT-5.5 y GPT-5.4.

Cómo elegir según el tipo de tarea

Si tu trabajo es preguntas frecuentes, explicaciones complejas, síntesis de materiales, análisis de archivos o integración de información extensa, GPT-5.5 es la mejor opción. No solo escribe código bien, sino que también resuelve mejor el trabajo intelectual exigente fuera del código puro.

Si tu trabajo es programación compleja, refactorización, depuración, diseño de arquitectura o cambios en varios archivos, GPT-5.5 sigue siendo la primera elección. Esa es también la recomendación oficial de Codex: cuando gpt-5.5 está disponible, lo normal es empezar por ahí.

Si te importan más el consumo y los límites, y aun así quieres una calidad alta, GPT-5.4 suele ser el valor por defecto más razonable. Para desarrollo habitual, reescrituras normales, traducciones estándar, generación de scripts y corrección de bugs, GPT-5.4 ya es suficientemente fuerte y además consume menos.

Si usas Codex CLI, la extensión de IDE o la app para un trabajo más parecido al de un agente de ingeniería, por ejemplo leer un repositorio durante mucho tiempo, modificar código de forma continua, encadenar tareas, o usar Cloud Tasks y Code Review, GPT-5.3-Codex sigue teniendo peso. No porque sea más avanzado que GPT-5.5, sino porque Cloud Tasks y Code Review de Codex siguen ejecutándose sobre GPT-5.3-Codex.

Cuánta diferencia hay en consumo

La tabla de credits de Codex deja las diferencias bastante claras.

Bajo la tarificación por tokens para Business / New Enterprise:

GPT-5.5: 125 credits / 1M tokens de entrada, 12.5 credits de entrada en caché y 750 credits de salida
GPT-5.4: 62.5 credits / 1M tokens de entrada, 6.25 credits de entrada en caché y 375 credits de salida
GPT-5.3-Codex: 43.75 credits / 1M tokens de entrada, 4.375 credits de entrada en caché y 350 credits de salida

Eso significa que, si solo miras la tarifa nominal, GPT-5.4 cuesta aproximadamente la mitad que GPT-5.5 para cantidades parecidas de entrada y salida. GPT-5.3-Codex es más barato en entrada, pero su salida ya está bastante cerca de GPT-5.4, así que no es una opción “muchísimo más barata” en conjunto.

Hay otro detalle importante. La documentación oficial también dice que GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4. En otras palabras, aunque la tarifa unitaria sea más alta, en tareas complejas puede compensar con menos tokens y menos retrabajo.

Sin embargo, en tareas como reescritura de artículos con plantilla fija, traducción o generación de descripciones SEO, donde la longitud de entrada y salida suele ser bastante estable, esa ventaja de “equivocarse menos” se nota menos que en la ingeniería compleja. En la práctica, GPT-5.4 suele seguir siendo la opción más barata, normalmente con un ahorro de alrededor del 45% al 50%.

Diferencias en los límites de uso dentro de Codex

Además del precio, estos modelos no están disponibles exactamente de la misma manera dentro de Codex.

A fecha de 2026-05-10, GPT-5.5 es el modelo recomendado en Codex, pero por ahora solo está disponible cuando inicias sesión en Codex con ChatGPT, y no admite autenticación con API key. GPT-5.4 y GPT-5.3-Codex sí admiten acceso vía API.

Además, GPT-5.5 y GPT-5.4 no soportan actualmente Codex Cloud Tasks ni Code Review. Esas dos funciones siguen siendo terreno de GPT-5.3-Codex. Por eso, si lo que realmente quieres es ejecutar trabajo de ingeniería prolongado dentro de Codex, no basta con comparar cuál modelo es más fuerte: también debes mirar si la función que necesitas sigue dependiendo de GPT-5.3-Codex.

Si solo usas mensajes locales, la ventana oficial de cinco horas del plan Plus es aproximadamente:

GPT-5.5: 15-80
GPT-5.4: 20-100
GPT-5.3-Codex: 30-150

Eso también refleja una diferencia práctica: GPT-5.5 es el más fuerte, pero normalmente te da menos usos dentro de un límite fijo; GPT-5.4 es más equilibrado; y GPT-5.3-Codex puede parecer más resistente en mensajes locales.

Cómo elegir en escenarios comunes

En el trabajo diario hay muchas tareas frecuentes. La forma más útil de comparar estos modelos no es preguntar en abstracto cuál es “mejor”, sino separarlos por escenario.

1. Preguntas diarias, organización de materiales y resúmenes largos

GPT-5.5: La mejor opción. Maneja mejor las solicitudes ambiguas, completa contexto y convierte información dispersa en una salida estructurada.

GPT-5.4: Adecuado para resúmenes normales y trabajo en lote. Cuando la dificultad es moderada y el volumen es alto, suele ser la opción más económica.

GPT-5.3-Codex: No es ideal como opción principal. Puede hacerlo, pero no es donde más destaca.

2. Explicación de conceptos técnicos, lectura de código y proyectos antiguos

GPT-5.5: Mejor para proyectos complejos. Es más fiable cuando hay muchas relaciones entre archivos, cadenas largas de llamadas y mucha deuda histórica.

GPT-5.4: Muy bueno para lectura y explicación normales. Funciona bien para entender funciones, módulos, configuraciones y ponerse al día en un proyecto.

GPT-5.3-Codex: Más orientado a ejecución, no es la primera opción para tareas centradas en explicación.

3. Scripts, herramientas pequeñas, SQL, shell y expresiones regulares

GPT-5.5: Mejor cuando el script forma parte de un diseño de sistema más amplio, conecta varios servicios o tiene restricciones complejas.

GPT-5.4: La mejor opción principal por defecto. La mayoría de scripts, herramientas pequeñas, SQL y trabajo de línea de comandos caben perfectamente dentro de su zona de confort, y además consume menos.

GPT-5.3-Codex: Tiene sentido si el script es solo una parte de un flujo más grande de agente de ingeniería, pero no hace falta priorizarlo para scripting aislado.

4. Corregir bugs, hacer cambios pequeños, añadir tests y desarrollo rutinario

GPT-5.5: Mejor para correcciones algo más complejas, especialmente si primero debe analizar la causa, luego editar varios archivos y finalmente añadir pruebas.

GPT-5.4: El mejor caballo de batalla para el desarrollo diario. En bugs normales, pequeñas funciones, esqueletos de tests, renombrado y limpieza de formato, ofrece el mejor equilibrio entre coste y resultado.

GPT-5.3-Codex: Capaz, pero normalmente no es la primera opción salvo que necesites específicamente Cloud Tasks o un flujo de agente de ingeniería.

5. Refactorización compleja, diseño de arquitectura y depuración difícil

GPT-5.5: La mejor opción. En tareas complejas, lo caro no suele ser una respuesta aislada, sino el retrabajo. GPT-5.5 encaja mejor como modelo principal para resolver problemas difíciles.

GPT-5.4: Bueno para trabajos de complejidad media. Puede encargarse de refactorizaciones y diseño, pero en contextos muy largos, razonamiento de muchos pasos y problemas con alta incertidumbre, suele ser menos estable que GPT-5.5.

GPT-5.3-Codex: Más orientado a ejecución, y no es la prioridad por defecto para trabajo de decisión difícil.

6. Tareas ligeras en lote, trabajo repetitivo y sub-tareas divididas

GPT-5.5: Puede hacerlo, pero normalmente no compensa por coste.

GPT-5.4: La mejor opción. Para editar comentarios en lote, reformatear, generar código de plantilla o hacer cambios repetitivos de contenido, es la más equilibrada.

GPT-5.3-Codex: Tiene sentido si el trabajo ya vive dentro de un flujo de ingeniería de Codex, pero en términos puros de coste-rendimiento suele quedar por detrás de GPT-5.4.

7. Automatización, ejecución de agentes y trabajo continuo sobre repositorios

GPT-5.5: Bueno para diseño inicial, reglas y descomposición de tareas complejas.

GPT-5.4: Bueno para escribir scripts de automatización y completar lógica de flujos de complejidad media, especialmente si importa el acceso por API.

GPT-5.3-Codex: Es el más relevante aquí. Como Cloud Tasks y Code Review de Codex siguen corriendo sobre él, encaja mejor en escenarios donde quieres que el sistema siga trabajando por sí solo.

8. Copy para páginas importantes, presentación de marca y pulido final

GPT-5.5: La mejor opción. Tiene mayor naturalidad, mejor control de estilo y más consistencia en textos largos.

GPT-5.4: Adecuado para la mayoría de páginas normales y actualizaciones diarias. Las páginas importantes pueden partir de un borrador en GPT-5.4 y pulirse después con GPT-5.5.

GPT-5.3-Codex: No encaja como modelo principal de redacción.

9. Reescritura de artículos con plantilla fija, traducción y descripciones SEO

GPT-5.5: Mejor para diseñar la plantilla, hacer el pulido final, cerrar páginas importantes y producir una traducción chino-inglés más natural.

GPT-5.4: La mejor opción para producción en lote. En reescritura de artículos estándar, traducciones con estructura fija, reescritura de copy de producto y generación masiva de meta descriptions, suele ofrecer el mejor equilibrio entre calidad y coste.

GPT-5.3-Codex: No es adecuado como modelo principal de redacción. Es más útil para scripts de procesamiento por lotes, limpieza de HTML, conservación de estructuras de etiquetas y mejora de flujos de publicación.

10. Copy para e-commerce, páginas de categoría y operación masiva de contenidos

GPT-5.5: Bueno para definir reglas, hacer revisiones de muestra y pulir páginas de alto valor.

GPT-5.4: La mejor opción para producción masiva. En títulos de producto, descripciones de categorías, textos de campañas y contenido SEO long-tail, ofrece un equilibrio más práctico.

GPT-5.3-Codex: Bueno para scraping, limpieza, procesamiento en lote y scripts de publicación automática, pero no tanto para el copy principal.

Si comprimes todos estos escenarios en una sola línea:

Trabajo intelectual complejo, análisis complejo y redacción de alto valor: prioriza GPT-5.5
Desarrollo diario, producción en lote y trabajo repetitivo: prioriza GPT-5.4
Agentes de ingeniería en Codex, Cloud Tasks y Code Review: presta especial atención a GPT-5.3-Codex

Recomendación final

Si tu trabajo consiste sobre todo en programación normal, corrección de bugs, preguntas técnicas y documentación de apoyo, GPT-5.4 es un valor por defecto muy sólido.

Si necesitas análisis de proyecto más complejos, cambios en varios archivos, diseño de arquitectura, depuración difícil, o un solo modelo que cubra tanto ingeniería como trabajo intelectual exigente, ve directamente a GPT-5.5.

Si lo que más pesa es el flujo de trabajo de ingeniería dentro de Codex, como Cloud Tasks, Code Review y ejecución prolongada de agentes, entonces GPT-5.3-Codex sigue mereciendo un lugar, aunque ya no tenga demasiado sentido como primera opción por defecto.

Para un sitio con contenido de plantilla fija, una combinación más práctica suele ser:

GPT-5.4 para la producción en lote
GPT-5.5 para diseñar la plantilla, hacer revisiones de muestra y pulir el resultado final
GPT-5.3-Codex para escribir herramientas de automatización en lugar del contenido principal

Resumen

El orden por defecto más razonable hoy es GPT-5.5 primero, GPT-5.4 segundo, y GPT-5.3-Codex reservado para escenarios más ligados a agentes de ingeniería o a funciones específicas de Codex.

Si la pregunta concreta es “¿cuánto ahorra GPT-5.4 frente a GPT-5.5 al reescribir el mismo artículo con plantilla?”, entonces, según la tabla oficial de credits y la estructura típica de tokens de este tipo de tarea, es razonable pensar en un ahorro cercano a la mitad. Para sitios de contenido por lotes, esa diferencia es lo bastante grande como para que la práctica habitual no sea usar GPT-5.5 en todo, sino usar GPT-5.5 para fijar reglas y estilo, y dejar la producción masiva a GPT-5.4.

Cómo elegir planes de AI Coding: los usuarios ligeros priorizan comodidad, los intensivos necesitan flexibilidad

Sun, 10 May 2026 08:20:58 +0800

Los planes de AI Coding han cambiado muy rápido en los últimos seis meses. Muchas herramientas han pasado de un modelo de cobro por mensajes o por uso limitado a uno claramente basado en consumo, los planes baratos y generosos se han ido recortando, y algunos servicios extranjeros han añadido verificaciones de identidad, restricciones regionales y reglas de uso más estrictas.

Para un desarrollador, la pregunta ya no es solo qué modelo es el más fuerte. También importa cuánto vas a gastar cada mes, si la cuota alcanza, si la herramienta resulta cómoda de usar y si podrás cambiar sin demasiado dolor cuando un proveedor suba precios o cambie las reglas de repente.

Una conclusión bastante útil es esta: los usuarios ligeros deberían comprar comodidad, los usuarios intermedios deberían comprar relación calidad-precio y los usuarios intensivos deberían comprar flexibilidad. Cuanto más intensivo sea el uso, menos conviene atar el modelo y la herramienta dentro del mismo plan.

Cuatro cosas que conviene revisar antes de elegir un plan

Antes, al elegir un plan de AI Coding, normalmente bastaba con mirar tres cosas:

Si el modelo era lo bastante fuerte.
Si la velocidad de respuesta era estable.
Si la cuota incluida alcanzaba.

Ahora hay que añadir una cuarta: si el modelo y la herramienta se pueden separar.

El modelo aporta la capacidad de razonamiento, mientras que la herramienta gestiona contexto, edición de archivos, orquestación de Agent y experiencia de flujo de trabajo. Ambas cosas importan, pero es mejor no dejarlas completamente atadas entre sí. Por ejemplo, si te gustan los modelos de Claude, puedes usar el plan oficial o conectar la API a otras herramientas. Y si te gusta un editor o entorno Agent concreto, es preferible que pueda conectarse a varios modelos en lugar de obligarte a usar solo el suyo.

La gracia de esto no es complicarse por gusto. Es reducir riesgos. AI Coding es uno de los segmentos que cambian más rápido. Un plan que hoy parece generoso puede cambiar de precio en dos meses, y una herramienta que hoy parece cómoda puede empeorar después de un cambio en la integración con modelos. Separar modelos y herramientas te deja margen de maniobra.

Los planes extranjeros se están endureciendo

Herramientas como GitHub Copilot, Cursor, Windsurf y Claude Code siguen siendo la base de trabajo de mucha gente, pero la tendencia es cada vez más clara: mantener planes muy baratos con cuotas muy altas es más difícil, y la facturación por uso real es cada vez más común.

Cuando servicios como GitHub Copilot se apoyan más en facturación por uso, el supuesto margen de ahorro de algunos planes cae bastante. Para usuarios ligeros siguen siendo cómodos, pero para quienes usan agentes, contexto largo y tareas complejas de código con mucha frecuencia, el consumo real empieza a parecerse mucho más al coste real de API.

Cursor y Windsurf, en esencia, empaquetan capacidad de modelo dentro de una experiencia de IDE. Su punto fuerte es que funcionan bien desde el primer momento y ofrecen una experiencia de editor madura. Su punto débil es el mayor nivel de dependencia de herramienta. Cuanto más dependas de sus agentes propietarios, sus índices y sus flujos automáticos, más caro será migrar después.

Claude Code sigue siendo atractivo tanto por experiencia como por atención del ecosistema, pero las suscripciones internacionales, la verificación de identidad, las restricciones regionales y la seguridad de los servicios intermedios son riesgos que los usuarios en China necesitan valorar con cuidado. En especial, los relays de terceros pueden mezclar modelos, ser inestables, exponer datos o desaparecer, así que no son una gran base a largo plazo para trabajo importante.

Ventajas y límites de los planes nacionales

Una ventaja de muchos planes nacionales de AI Coding es que suelen ofrecerse en forma de API, lo que hace que queden menos atados a una sola herramienta. Puedes conectarlos a OpenCode, Cline, Continue, tus propios scripts o agentes internos.

El problema también es evidente: si quieres al mismo tiempo un modelo fuerte, buena velocidad y bastante cuota, hay pocos planes que cumplan todo a la vez.

La familia GLM es fuerte dentro del panorama nacional, pero en horas punta el rendimiento puede volverse inestable y las tareas pesadas acaban limitadas por velocidad. Kimi tiene buen nivel, pero sus reglas de precio y cuota hay que seguirlas de cerca, sobre todo la transparencia del límite real. Modelos como MiniMax son más amables en velocidad y cuota, lo que los hace útiles para tareas ligeras del día a día, lotes y ayuda de código no demasiado compleja, aunque pueden quedar un escalón por debajo en razonamiento de ingeniería difícil. DeepSeek puede parecer muy rentable cuando un modelo nuevo está en precio promocional, pero al acabar la promoción toca reevaluarlo con tarifa normal.

Por eso, en muchos casos, las opciones nacionales funcionan mejor como un grupo de modelos disponible para repartir trabajo según la tarea, y no como una apuesta total por un solo modelo y un solo plan.

Usuarios ligeros: elige lo que resulte cómodo y no sobrediseñes

Si solo usas AI para retocar scripts, completar documentación, explicar errores o generar herramientas pequeñas una o dos veces por semana, probablemente no necesitas una configuración complicada.

En este caso importa más la comodidad. Cursor, Windsurf, Trae, CodeBuddy, Tongyi Lingma, GitHub Copilot y herramientas similares son opciones razonables. El objetivo no es perseguir el coste unitario más bajo, sino reducir fricción: algo estable dentro de tu editor, con buenas sugerencias y fácil de revertir cuando se equivoca.

Para usuarios ligeros, construir capas de API, relays y proxys complejos solo para ahorrar un poco de dinero rara vez compensa. El tiempo, el riesgo de cuenta y el coste de depuración suelen costar más que la suscripción que te ahorras.

Usuarios intermedios: mira la relación calidad-precio, pero también la portabilidad

Si usas AI todos los días para programar, modificar proyectos, generar pruebas y preparar documentación, la cuota y el consumo real empiezan a importar mucho más.

En este caso conviene separar la herramienta principal de los modelos de respaldo. Por ejemplo, un plan cómodo de IDE puede servir para el trabajo diario, mientras que una API o plan agregador conectable a varias herramientas puede encargarse de tareas con contexto más largo o flujos de Agent más complejos.

Aquí hay tres preguntas clave:

Si se puede integrar con herramientas de terceros.
Si el consumo de tokens o cuota es visible y entendible.
Si al superar el límite se aplica throttling, degradación, corte del servicio o pura facturación por uso.

Si un plan parece barato pero solo funciona dentro de su propia herramienta, conviene contar también el coste de migrar más adelante. Si cuesta algo más pero puede conectarse a varias herramientas, puede ser mejor como base a largo plazo.

Usuarios intensivos: no bloquees modelo y herramienta juntos

Para los usuarios intensivos, la necesidad principal es la flexibilidad.

Cuando una persona o un equipo usa agentes de AI de forma intensiva todos los días, el consumo crece muy rápido. Búsquedas de repositorio, cambios con contexto largo, depuración en múltiples rondas y reparación automática de pruebas pueden multiplicar el gasto en tokens. Si en ese punto dependes de un solo plan, aparecen tres problemas con facilidad:

La cuota deja de ser suficiente de repente.
La regla de cobro cambia de forma inesperada.
Una herramienta o un modelo deja de estar disponible temporalmente.

La opción más estable es montar una estructura por capas: una herramienta Agent principal, uno o varios endpoints de modelo intercambiables, un modelo barato para tareas simples y un modelo fuerte para tareas difíciles. No conviene mandar todas las tareas pequeñas al modelo más caro, ni depender solo del más barato para las tareas críticas.

Para un usuario intensivo, que las herramientas puedan conectarse a cualquier modelo y que los modelos puedan moverse entre herramientas importa más que ahorrar unas decenas de dólares al mes. Lo realmente caro no suele ser la suscripción. Lo caro es quedar atrapado en un solo ecosistema y tener que reconstruir el flujo de trabajo después.

Una estrategia de combinación más estable

Una forma razonablemente sólida de organizarlo sería esta:

Usa un modelo de bajo coste para tareas ligeras como explicar código, escribir scripts pequeños, formatear y generar documentos simples.
Usa un modelo orientado a valor para tareas intermedias como desarrollo normal de funciones, completar pruebas y sugerencias de refactorización.
Usa un modelo fuerte para tareas difíciles como cambios de arquitectura, correcciones entre varios archivos, bugs complejos y razonamiento con contexto largo.
Mantén abierta la capa de herramientas, eligiendo soluciones que puedan conectarse por API, exportar configuración y cambiar de modelo.
Conserva un camino de respaldo, de forma que si tu plan principal cambia reglas puedas moverte rápido a otra herramienta o modelo.

Puede que no sea la configuración más barata posible, pero sí una mucho más resistente. Los precios y cuotas de AI Coding van a seguir cambiando. Lo valioso a largo plazo no es un plan que hoy parezca muy generoso, sino un flujo de trabajo portable.

Resumen

Los planes de AI Coding no deberían juzgarse solo por el precio mensual. Los usuarios ligeros deberían priorizar simplicidad y comodidad. Los usuarios intermedios deberían fijarse en cuota, consumo y capacidad de migrar. Los usuarios intensivos deberían separar modelos y herramientas para no quedar atrapados en un único ecosistema.

La idea más importante es que los planes cambian, los modelos cambian y las herramientas también. Mantener la capacidad de elegir en tus propias manos es la forma más importante de controlar costes cuando trabajas con AI Coding a largo plazo.

De PPT a prototipos: casos de uso de Guizang PPT Skill y Huashu Design

Sat, 09 May 2026 08:34:23 +0800

Hay dos Agent Skills de diseño creadas por desarrolladores chinos que vale la pena mirar en conjunto: guizang-ppt-skill, de Guizang, y huashu-design, de Huashu.

No son “herramientas de diseño” en el sentido tradicional. En realidad convierten un proceso de diseño, preferencias estéticas, listas de comprobación y plantillas de ingeniería en Skills que un Agent puede ejecutar. No abres una UI para arrastrar elementos poco a poco; entregas el requisito a un Agent como Claude Code, Codex o Cursor, y dejas que genere HTML, PPT, animaciones o prototipos siguiendo un flujo fijo.

El valor de estos proyectos no está en dejar que la IA improvise, sino en convertir “cómo hacer que esto no se vea mal” en un proceso.

guizang-ppt-skill: enfocado en PPT web con estilo de revista

guizang-ppt-skill, de Guizang, tiene una posición muy clara: genera PPT en HTML de archivo único con paginación horizontal, y una base visual de “revista digital x tinta electrónica”. Se parece más a un sistema de maquetación para charlas que a un framework de diseño general.

El README del repositorio enumera estas capacidades principales:

Salida HTML de archivo único, sin necesidad de build ni servidor. Se abre directamente en el navegador.
Paginación horizontal, con soporte para teclado, rueda del ratón, deslizamiento táctil, puntos inferiores e índice con ESC.
5 paletas temáticas predefinidas, incluidas Ink Classic, Indigo Porcelain, Forest Ink, Kraft Paper y Dune.
10 layouts de página, incluidos portada de apertura, separador de sección, póster de datos con número grande, texto a la izquierda e imagen a la derecha, cuadrícula de imágenes, Pipeline, pregunta de suspense, cita grande, comparación Before/After y composición mixta de texto e imagen.
Plantillas integradas, notas de componentes, esqueletos de layout, configuración de tema y listas de comprobación de calidad.

Sirve para presentaciones presenciales, charlas internas de industria, eventos privados, lanzamientos de productos de IA, demo days y decks con un estilo personal fuerte. No encaja tan bien con grandes tablas de datos, materiales de formación o edición colaborativa entre varias personas.

Este proyecto toma una buena decisión de alcance: no intenta cubrir todos los escenarios de diseño, sino que estrecha el foco a “PPT con estilo de revista”. Los colores de tema se eligen desde presets y los layouts tienen esqueletos claros. Eso reduce la probabilidad de que el Agent se desvíe.

Si a menudo necesitas convertir opiniones, observaciones de industria o contenido de lanzamiento de producto en un deck de presentación, puede ser muy práctico.

El comando de instalación también es directo:

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design: un flujo de diseño HTML-native más completo

huashu-design, de Huashu, cubre un terreno más amplio. Su objetivo no es solo hacer PPT, sino tratar HTML como un lienzo de diseño nativo y usar un Agent para generar activos de diseño entregables.

El README del repositorio enumera estas capacidades:

Prototipos clicables de App o Web.
Diapositivas HTML y exportación a PPTX editable.
Animaciones de lanzamiento de producto, MP4, GIF y versiones con música.
Comparación en paralelo de varias direcciones de diseño.
Infografías, visualización de datos y exportación a PDF, PNG y SVG.
Revisión experta en 5 dimensiones, incluidas consistencia filosófica, jerarquía visual, calidad de ejecución, funcionalidad e innovación.

La idea central es que el Agent entienda primero la marca y los materiales, y después produzca diseño de alta fidelidad. El proyecto enfatiza el Core Asset Protocol: cuando se trabaja con una marca concreta, primero hay que confirmar logo, imágenes de producto, capturas de UI, paleta de colores, tipografías y guía de marca, en lugar de adivinar de memoria.

Esto importa. Muchos diseños generados por IA parecen “diseño”, pero no parecen pertenecer a un producto o una marca real. huashu-design intenta resolver ese problema por adelantado: primero encontrar activos reales, luego diseñar.

El comando de instalación es:

`1`	`npx skills add alchaincyf/huashu-design`

Encaja mejor con quienes quieren completar una entrega de diseño más amplia desde la terminal: prototipos de producto, animaciones de lanzamiento, presentaciones, infografías y revisiones de diseño pueden procesarse dentro de un único flujo de trabajo de Agent.

La mayor diferencia entre ambos

En pocas palabras, guizang-ppt-skill es un generador de decks de presentación más estrecho y más estable; huashu-design es un sistema de diseño HTML-native más amplio y completo.

Si miramos solo PPT:

guizang-ppt-skill enfatiza más la sensación de revista, el ritmo, la maquetación y la presentación de archivo único en navegador.
huashu-design enfatiza más la capacidad de diseño general, PPTX editable, activos de marca, rutas de exportación y flujo de revisión.

Si miramos la capacidad de diseño general:

guizang-ppt-skill tiene límites más claros y sirve para crear rápido una presentación horizontal con estilo.
huashu-design es más integral y sirve para descomponer una tarea de diseño de producto o marca en prototipos, animaciones, diapositivas e infografías.

Estos dos proyectos también representan dos formas distintas de escribir Skills. El primero se parece a un conjunto muy concentrado de plantillas y restricciones estéticas; el segundo se parece al manual de trabajo de un pequeño equipo de diseño.

Por qué este tipo de Skill importa

Un problema común de los Agents es que “pueden hacerlo, pero no de forma estable”. La misma petición a veces produce una salida muy buena, y otras veces se desliza hacia gradientes morados, tarjetas redondeadas, iconos falsos y un montón de frases vacías que suenan sofisticadas.

El sentido de una Skill es añadir estabilidad. Fija cosas como:

Plantillas reutilizables.
Listas de comprobación ejecutables.
Preferencias estéticas claras.
Reglas para evitar errores comunes.
Formatos de salida y flujos de validación.
Cuándo hacer preguntas y cuándo empezar directamente.

Esto es mucho más fiable que escribir simplemente “hazlo más premium”.

Esto es especialmente cierto en tareas de diseño. La estética no se puede reproducir de forma estable con una sola frase de prompt. Lo que realmente ayuda es el proceso: confirmar materiales, definir una dirección, montar la estructura, trabajar la parte visual y revisar la salida. Cuando ese proceso se escribe como Skill, el Agent se parece más a un ejecutor colaborativo que a un generador de imágenes de una sola vez.

Recomendaciones de uso

Si solo quieres convertir un tema en una charla presencial o un deck para compartir, prueba primero guizang-ppt-skill. Su frontera de salida es estrecha, y el HTML de archivo único facilita distribuirlo y previsualizarlo.

Si quieres que un Agent asuma una tarea de diseño más completa, como prototipos de App, animaciones de lanzamiento, diapositivas con marca, PPTX exportable o infografías, mira primero huashu-design. Su flujo es más largo y encaja con tareas que necesitan varias rondas de iteración y exportación de entregables.

Si ya estás escribiendo tu propia Skill para Codex o Claude Code, ambos proyectos merecen estudio:

Para aprender “cómo estabilizar un escenario estrecho”, mira guizang-ppt-skill.
Para aprender “cómo dividir un flujo complejo en protocolos ejecutables”, mira huashu-design.

Resumen

Lo que tienen en común los proyectos de Guizang y Huashu es que ambos convierten la “capacidad de diseño” de un prompt único en un proceso repetible.

guizang-ppt-skill se centra en PPT HTML con estilo de revista y encaja con presentaciones muy estilizadas. huashu-design se centra en un sistema de diseño HTML-native que cubre prototipos, animaciones, diapositivas, infografías y revisión. El problema que resuelven no es “si la IA puede generar diseño”, sino “si la IA puede generar diseño entregable siguiendo un método estable”.

Esto podría convertirse en una categoría importante de proyectos open source dentro del ecosistema de herramientas Agent: no solo plantillas de código, sino experiencia humana, estética y métodos de trabajo empaquetados como Skills.

Enlaces de referencia:

Codex vs Claude Code: cómo elegir entre dos diseños de Subagent

Fri, 08 May 2026 14:14:01 +0800

Las herramientas de programación con IA están prestando cada vez más atención a los subagentes. No es simple moda: un solo agente acaba encontrando límites cuando debe manejar tareas reales de ingeniería.

Si un agente lee código, revisa logs, modifica implementación, ejecuta pruebas, analiza errores y resume resultados a la vez, el contexto principal se ensucia rápido. Resultados de búsqueda, salidas de comandos, logs de pruebas y razonamientos intermedios se mezclan. Las decisiones posteriores se vuelven menos fiables. Además, explorar, implementar, verificar y revisar en un único hilo dificulta el paralelismo.

El objetivo de los subagentes es reducir esa presión. La sesión principal deja de hacerlo todo de principio a fin y pasa a coordinar: define objetivos, asigna trabajo, recibe resultados y los integra. Un subagente se ocupa de una parte local, como exploración, implementación, verificación o revisión, y devuelve una conclusión comprimida.

Un subagente no es “otra copia de mí”. Es una forma de dividir trabajo de ingeniería confuso en roles más claros.

Fundamentos compartidos

Un sistema maduro de subagentes suele necesitar cuatro bases:

Aislamiento de contexto.
Especialización de roles.
Configuración a nivel de proyecto y usuario.
Límites de herramientas y permisos.

El aislamiento de contexto es esencial. En un repositorio real hay mucho material intermedio: búsquedas, logs de pruebas, salidas de comandos. Si todo entra en la sesión principal, el hilo principal se vuelve ruidoso. Un subagente puede digerir ese proceso local y devolver solo las señales útiles.

La especialización de roles también importa. Multi-agent no significa abrir varias copias del mismo modelo. Un rol de exploración debe buscar, leer y resumir. Un rol de implementación debe centrarse en cambios locales. Un rol de verificación debe ejecutar checks, identificar riesgos e informar con claridad.

Los límites de herramientas y permisos determinan si el sistema es seguro. Un subagente no debería heredar automáticamente todas las capacidades de la sesión principal. Un explorer de solo lectura no necesita escribir archivos. Un verifier no siempre necesita modificar implementación.

Codex y Claude Code comparten estas preocupaciones, pero toman caminos distintos.

Codex: delegación explícita

El diseño de Codex es más contenido.

Ofrece un mecanismo de delegación controlado y ligero alrededor de la sesión principal actual. Cuándo delegar, a quién delegar y cuándo recoger resultados son decisiones explícitas. El flujo de control permanece en la tarea actual.

Sus rasgos:

La sesión principal delega explícitamente.
El conjunto de roles se mantiene pequeño.
La sesión principal sabe qué agente hace qué.
Los resultados vuelven a la línea principal.
Los límites de colaboración son transparentes.

Esto encaja con equipos que valoran orquestación manual, previsibilidad y determinismo. Puedes pedir a un explorer que inspeccione una cadena de llamadas, a un worker que haga un cambio acotado y a la sesión principal que integre el resultado.

La contrapartida es que la presión de orquestación sigue en la sesión principal. Debe decidir cuándo dividir, cómo dividir, a quién asignar y cómo fusionar resultados. Para colaboración ligera es cómodo; para flujos largos puede cansar.

Claude Code: agentes como puestos de trabajo

Claude Code toma una ruta más de plataforma.

Trata los agentes como objetos describibles, seleccionables, configurables, con memoria, aislables y capaces de ejecutarse en segundo plano. Un subagente no es solo una ayuda temporal en una conversación; se parece más a un puesto de trabajo dentro de un sistema de ingeniería.

El sistema puede exponer listas de agentes, casos de uso, descripciones y límites de herramientas al modelo, permitiendo que el modelo decida qué rol usar en cada turno. Eso hace la delegación más automática.

Varios elementos definen este enfoque.

Primero, un sistema de roles. Explorer, planner, general-purpose y verifier pueden tener descripción de uso, restricciones de herramientas, modelos por defecto y condiciones de ejecución. Un explorer de solo lectura no edita archivos; un planner diseña; un verifier comprueba.

Segundo, herencia y override. Un subagente no es completamente libre. Hereda los límites grandes de la sesión principal, pero puede ajustar comportamiento local dentro de reglas permitidas.

Tercero, memoria. La memoria no es solo recordar algo. Puede tener alcance: memoria de usuario para preferencias largas, memoria de proyecto para contexto del repositorio y memoria local para estado del entorno.

Cuarto, background y worktree isolation. Algunas verificaciones pueden seguir en segundo plano mientras el hilo principal avanza. Si hace falta aislamiento fuerte, el agente puede trabajar en un worktree separado.

Quinto, ecosistema de plugins. Si los agentes son objetos de primera clase, hay que pensar en distribución, instalación, prioridades, overrides y seguridad. Los plugin agents pueden entrar al sistema, pero campos de alto riesgo como permission mode, hooks o MCP servers deben estar controlados.

Esto hace que Claude Code se parezca más a un runtime de agentes que a una herramienta de colaboración de una sola sesión.

Diferencia principal

Codex se parece a una herramienta de delegación controlada:

Delegación explícita.
Roles ligeros.
Flujo de control claro.
Subtareas centradas en la sesión actual.
Adecuado para trabajo humano-orquestado y determinista.

Claude Code se parece a un sistema de puestos de ingeniería:

Los agentes están modelados formalmente.
Los roles son más sistemáticos.
Memoria, background, aislamiento y plugins forman parte del runtime.
El modelo puede ayudar a elegir roles.
Adecuado para proyectos largos y workflows de plataforma.

La pregunta no es cuál tiene más funciones. Es si quieres que un subagente sea “un ayudante al que llamo explícitamente” o “un puesto permanente dentro del sistema”.

Cómo elegir

Elige el estilo Codex si valoras control explícito, delegación ligera y paralelismo seguro dentro de la sesión actual. Encaja con revisiones, cambios pequeños, tareas claras y flujos donde la persona quiere mantener el ritmo.

Elige el estilo Claude Code si necesitas roles sistemáticos, memoria a largo plazo, ejecución en segundo plano, aislamiento por worktree, plugins y un runtime más completo.

Hazte dos preguntas:

¿Aceptas que el modelo decida quién debe hacer el trabajo?
¿Necesitas un runtime de agentes más completo?

Si la primera te incomoda, la delegación explícita es mejor. Si la segunda es sí, un sistema tipo plataforma encaja mejor.

Consejos prácticos

No trates los subagentes como “más modelos igual a más potencia”.

Define límites de tarea para cada rol.
Limita las herramientas de cada rol.
Pide conclusiones, no logs crudos.
Mantén la decisión final en la sesión principal.
Haz visibles tareas en background y worktrees.
Define límites de seguridad para plugins.

El valor de los subagentes no está en la cantidad, sino en la calidad de la división del trabajo.

Resumen

Codex y Claude Code resuelven el mismo problema: un solo agente no puede cargar cómodamente con todo el trabajo real de ingeniería. Ambos reconocen la importancia de aislar contexto, especializar roles, definir permisos y resumir localmente.

Codex es más contenido y prioriza delegación explícita y control de la sesión principal. Claude Code es más sistemático y trata los agentes como puestos configurables, con memoria, aislamiento, background y ecosistema de plugins.

La elección no depende de qué marca gana, sino de si tu flujo necesita una herramienta de colaboración controlada o un runtime completo de agentes.

9Router: conecta Claude Code, Codex y Cursor a un mismo router de IA

Fri, 08 May 2026 13:41:15 +0800

9Router es un router local para herramientas de programación con IA. Permite conectar Claude Code, Codex, Cursor, Cline, Copilot, OpenCode, OpenClaw y herramientas similares a un único endpoint compatible con OpenAI, y desde ahí enrutar las solicitudes a distintos modelos y proveedores.

No pretende ser otro cliente de chat. Se coloca entre tus herramientas de programación y los proveedores de modelos para resolver problemas prácticos: formatos de API incompatibles, cambios manuales entre proveedores, consumo rápido de tokens por salidas de herramientas, cortes por cuotas agotadas y configuración complicada de varias cuentas.

Según el README, 9Router admite más de 40 proveedores y más de 100 modelos. Incluye RTK Token Saver, fallback automático, seguimiento de cuotas, rotación multi-cuenta, traducción de formatos y registros de solicitudes. Está escrito en JavaScript, usa Node.js, Next.js, React, Tailwind CSS y LowDB, y tiene licencia MIT.

Para qué sirve

9Router tiene más sentido cuando usas varias herramientas de programación con IA y varias fuentes de modelos al mismo tiempo.

Claude Code usa una cuenta de suscripción.
Codex o Cursor necesitan un endpoint OpenAI personalizado.
Cline, Continue o RooCode necesitan una API compatible con OpenAI.
Los proveedores gratuitos sirven para pruebas.
GLM, MiniMax o Kimi funcionan como respaldo barato.
Los modelos de mayor calidad se reservan para tareas difíciles.

Sin 9Router, cada herramienta necesita su propio endpoint, API key, nombre de modelo y estrategia de fallback. 9Router centraliza todo eso en una capa local.

API local:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

Instalación rápida

Para uso local:

1
2

npm install -g 9router
9router

Desde el código fuente:

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

Modo producción:

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

El paquete npm requiere Node.js >=18.0.0. En VPS o Docker, configura JWT_SECRET, INITIAL_PASSWORD, DATA_DIR y API_KEY_SECRET.

Conectar herramientas de programación

Configuración típica:

1
2
3

Base URL: http://localhost:20128/v1
API Key: copiada desde el dashboard de 9Router
Model: nombre de modelo o combo configurado en 9Router

Para Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Para Cline, Continue o RooCode, elige OpenAI Compatible:

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

Los nombres dependen de los proveedores conectados, por ejemplo cc/, cx/, gh/, glm/, minimax/, kr/ y vertex/.

RTK Token Saver

En programación con IA, muchas veces lo que más tokens consume son salidas de herramientas:

git diff
git status
grep
find
ls
tree
logs
listas largas de archivos

RTK Token Saver comprime esas salidas antes de enviarlas al modelo. El proyecto afirma que puede ahorrar 20%-40% de tokens de entrada en muchas solicitudes.

La ventaja es que no tienes que cambiar de herramienta ni de modelo. Aun así, para logs críticos o contenido completo de archivos, conviene probar primero que la calidad de respuesta no baje.

Fallback automático

Puedes ordenar modelos por prioridad:

1
2
3

1. Modelo de suscripción
2. API barata
3. Proveedor gratuito

Ejemplo:

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

El fallback reduce interrupciones, pero cambia la consistencia de salida. Para refactors grandes, migraciones o tareas sensibles, es mejor fijar un modelo principal.

Cuidado con proveedores gratuitos

Kiro, OpenCode Free y Vertex pueden ser útiles, pero sus reglas cambian. Verifica siempre si el uso es gratuito, si hay límites regionales, si se permite usar herramientas de terceros, si puede haber rate limits o bloqueos, y cuándo caduca la cuota.

9Router enruta solicitudes; no cambia las condiciones del proveedor.

Despliegue local

Para uso personal, basta con escuchar en localhost. Si lo llevas a un VPS o LAN, cambia la contraseña por defecto, configura JWT_SECRET y API_KEY_SECRET, no expongas el dashboard directamente, y exige Bearer API key en /v1/*.

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

Resumen

9Router es una puerta de enlace local para herramientas de programación con IA. Unifica Claude Code, Codex, Cursor y Cline en http://localhost:20128/v1, y gestiona selección de modelo, traducción de formatos, compresión de tokens, cuotas y fallback.

Es más útil para usuarios intensivos que ya alternan entre varios proveedores. Empieza con una herramienta y un proveedor, y añade combos poco a poco.

Referencias

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Awesome Codex Skills: un catalogo comunitario para ampliar Codex CLI

Thu, 07 May 2026 20:19:15 +0800

awesome-codex-skills, de ComposioHQ, es un catalogo comunitario de skills para Codex CLI. Su valor no esta en ser otra pila de plantillas de prompts, sino en ofrecer una forma de empaquetar flujos repetibles como Skills instalables, reutilizables y mantenibles.

Si ya usas Codex como parte del desarrollo diario, este tipo de repositorio resulta util de inmediato: reglas, comandos, materiales de referencia y pasos operativos que antes tenias que explicar una y otra vez pueden escribirse una vez y reutilizarse cada vez que se invoque la Skill correspondiente.

Que resuelve este repositorio

Las Codex Skills pueden entenderse como modos de trabajo especializados para Codex CLI. Un prompt normal sirve bien para una instruccion temporal; una Skill encaja mejor con algo que quieres reutilizar durante mucho tiempo.

Por ejemplo, puede que a menudo necesites:

generar mensajes de commit con un formato fijo;
consultar una familia especifica de documentacion de API;
ejecutar comandos de pruebas y despliegue propios de un proyecto;
reescribir articulos, traducir documentos u organizar notas segun reglas del equipo;
llamar herramientas externas para tareas de desarrollo repetitivas.

Escribir estas instrucciones cada vez se convierte rapidamente en sobrecarga. Una Skill coloca las reglas en un directorio independiente. El nucleo suele ser un archivo SKILL.md, a veces acompanado de scripts, plantillas, documentos de referencia o assets. Cuando Codex se activa, lee las instrucciones y sigue el flujo descrito alli.

En que se diferencia de un prompt

Un prompt se parece mas a una instruccion puntual: “haz esta tarea de esta forma”. Una Skill se parece mas a un pequeno manual operativo: “cuando aparezca esta clase de tarea, trabaja de esta manera”.

Sus principales ventajas son:

Reutilizable: los flujos comunes ya no necesitan preparacion por copy-and-paste.
Revisable: los archivos de skill suelen ser Markdown locales que pueden abrirse, editarse y versionarse.
Extensible: las skills complejas pueden incluir scripts, plantillas y referencias, no solo instrucciones en lenguaje natural.

Por eso catalogos como awesome-codex-skills son utiles: ayudan a descubrir skills existentes y luego adaptarlas a tu propio flujo de trabajo.

Instalacion y uso

El repositorio ofrece un script de instalacion y tambien soporta instalacion manual. Un flujo tipico es:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

Si solo quieres probar algunas skills, lee primero el SKILL.md de cada directorio. Revisa que lee, que scripts puede ejecutar, que archivos puede editar y si los valores por defecto encajan con tu entorno local.

Despues de instalar, Codex puede detectar skills cuando la tarea las necesita, o puedes nombrar una skill de forma explicita. Para uso a largo plazo, el enfoque mas practico suele ser instalar primero una skill comunitaria y despues reescribir sus instrucciones alrededor de las convenciones de tu proyecto.

Que skills merece la pena observar

Las skills mas valiosas no son necesariamente las que tienen los nombres mas llamativos. Son las que eliminan trabajo repetido de forma fiable.

Yo miraria primero:

Skills de flujo de desarrollo: review, pruebas, commits, releases, comprobacion de dependencias.
Skills de documentacion: reescritura, traduccion, resumen, organizacion estructurada.
Skills de integracion de herramientas: conectar Codex con servicios externos, APIs y herramientas CLI.
Skills de convenciones de proyecto: codificar reglas del equipo, estructura de directorios, convenciones de nombres y pasos de despliegue.

Si una skill solo envuelve un prompt de una frase, su valor es limitado. Si puede conectar investigacion, juicio, ejecucion, verificacion y salida en un flujo estable, merece conservarse.

Puntos de cuidado

Las skills comunitarias son comodas, pero no deberian tratarse como cajas negras. Esto es especialmente cierto para Skills que incluyen scripts. Antes de instalar una, revisa:

que le pide SKILL.md a Codex;
si incluye scripts que acceden a la red, leen o escriben archivos, o llaman servicios externos;
si las rutas, comandos y permisos por defecto encajan con tu maquina.

Una Skill amplia lo que Codex puede hacer. Bien escrita, hace que Codex se sienta mas como un companero que conoce tu proyecto. Escrita con descuido, puede traer reglas inadecuadas a tu flujo de trabajo. El mejor patron no es instalar muchas skills, sino mantener un conjunto pequeno, ajustarlas con cuidado y conservarlas con el tiempo.

Mi lectura

awesome-codex-skills merece guardarse en favoritos, especialmente si ya usas Codex CLI para desarrollo real, documentacion o automatizacion. No es una capacidad oficial por si misma; es un punto de entrada comunitario para encontrar y adaptar flujos reutilizables.

Para usuarios intensivos, el punto de Codex Skills no es simplemente ayudar a la IA a recordar mas. Es ayudar a la IA a dar menos rodeos en tareas repetidas. Escribir reglas como Skills convierte instrucciones temporales en infraestructura de trabajo reutilizable.

CC Switch: una herramienta de escritorio para gestionar Claude Code, Codex, Gemini CLI y OpenClaw en un solo lugar

Wed, 06 May 2026 09:03:08 +0800

CC Switch es una herramienta de gestión de escritorio para usuarios intensivos de programación con IA. El problema que intenta resolver es directo: muchas personas ahora usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw al mismo tiempo, pero cada herramienta tiene su propio formato de configuración, sintaxis de Provider, configuración MCP y forma de gestionar Skills.

Cuando solo usas una herramienta, editar archivos de configuración manualmente todavía es tolerable. Una vez que se mezclan varias herramientas, además de cuentas oficiales, APIs de terceros, servicios relay, modelos locales y configuración compartida de equipo, editar JSON, TOML y archivos .env a mano se vuelve tedioso rápidamente.

CC Switch se posiciona como una forma de reunir estas configuraciones dispersas en una sola app de escritorio multiplataforma.

Qué problema resuelve

Las herramientas modernas de programación con IA se sienten cada vez más como “colegas de desarrollo dentro de la línea de comandos”, pero sus ecosistemas aún no están completamente unificados.

Los puntos de dolor comunes incluyen:

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw usan formatos de configuración distintos.
Cambiar API Providers requiere editar repetidamente archivos de configuración.
Los servidores MCP se configuran una y otra vez en distintas herramientas.
Archivos de prompt como CLAUDE.md, AGENTS.md y GEMINI.md son difíciles de mantener de forma consistente.
Instalación, sincronización, respaldo y eliminación de Skills carecen de una entrada central.
Cambiar entre múltiples cuentas, relays y servicios de modelos puede volverse confuso fácilmente.
Cuando un archivo de configuración editado a mano se rompe, depurarlo cuesta tiempo.

La idea detrás de CC Switch es dejar de obligar a los usuarios a recordar los detalles de configuración de cada herramienta, y usar una interfaz unificada para gestionar Providers, MCP, Prompts, Skills, Sessions y proxies.

Herramientas soportadas

El README enumera cinco objetivos principales soportados:

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

Estas herramientas son similares en posicionamiento: todas se centran en programación con IA, flujos Agent y colaboración por línea de comandos. Pero sus sistemas de configuración difieren, y el valor de CC Switch está en envolver esas diferencias.

Para quienes comparan con frecuencia distintas herramientas de programación con IA, esto es mucho más fácil que abrir manualmente archivos de configuración cada vez.

Gestión de Providers

La primera capa de CC Switch es la gestión de Providers.

Incluye más de 50 presets de Provider. El README menciona direcciones como AWS Bedrock, NVIDIA NIM y varios relays comunitarios. Los usuarios pueden copiar una API key, importarla con un clic y luego cambiar desde la interfaz.

Los puntos prácticos incluyen:

Añadir Providers con un clic.
Reordenar Providers arrastrando.
Cambiar rápidamente desde la bandeja del sistema.
Importar y exportar Providers.
Sincronizar algunos Providers comunes entre varias apps.

Para muchas personas, esta función por sí sola ya es atractiva. En el trabajo diario de programación con IA, el problema muchas veces no es “no sé usar el modelo”, sino “qué herramienta, endpoint y cuenta debería usar hoy esta key”.

Proxy local y failover

Además de escribir archivos de configuración, CC Switch también proporciona un modo de proxy local.

El foco de esta capacidad es:

Cambio en caliente de Providers.
Conversión de formatos.
Failover automático.
Circuit breakers.
Health checks de Providers.
Corrección de solicitudes.

En términos simples, no solo escribe configuración en herramientas objetivo. También puede añadir una capa de proxy local en el medio, para que distintas herramientas accedan a servicios de modelos mediante el proxy.

Esto es útil para usuarios con múltiples Providers: si un servicio cae, cambiar a otro; si un modelo es caro, pasar a uno más barato; si el formato de solicitud es incompatible, adaptarlo mediante la capa de proxy.

MCP, Prompts y Skills

La segunda capa importante de CC Switch es la gestión unificada de MCP, Prompts y Skills.

MCP

Proporciona un panel MCP unificado para gestionar servidores MCP entre varias apps, con soporte para sincronización bidireccional e importación mediante Deep Link.

Esto es práctico para usuarios que ya trabajan con MCP. Cuando hay muchos servidores MCP, la configuración se dispersa fácilmente entre distintos clientes. Un panel unificado reduce la configuración duplicada y facilita la migración.

Prompts

La sección Prompts soporta edición Markdown y puede sincronizar archivos correspondientes entre distintas herramientas, como:

CLAUDE.md
AGENTS.md
GEMINI.md

Estos archivos son esencialmente manuales de proyecto para Agents. La gestión unificada facilita mantener reglas de equipo, convenciones de proyecto y prompts globales.

Skills

Las Skills pueden instalarse con un clic desde repositorios GitHub o archivos ZIP. También se soportan gestión de repositorios personalizados, enlaces simbólicos y copia de archivos.

Si usas herramientas como Claude Code, Codex y OpenClaw al mismo tiempo, las Skills pueden convertirse fácilmente en archivos dispersos por distintos directorios. CC Switch las centraliza y reduce el costo de mantenimiento.

Sesiones y workspace

El README también menciona funciones de Session Manager y Workspace.

Puede explorar, buscar y restaurar historial de sesiones de varias apps. Para personas que usan herramientas de programación con IA durante mucho tiempo, la gestión de sesiones es realmente importante: muchos contextos valiosos, rastros de depuración y comparaciones de soluciones quedan enterrados en conversaciones antiguas.

También proporciona un editor de Workspace para OpenClaw, permitiendo editar archivos de agente como AGENTS.md y SOUL.md con vista previa Markdown.

Esto muestra que CC Switch no es solo una pequeña utilidad para “cambiar keys”. Se está expandiendo hacia una estación de trabajo para AI Agent.

Sincronización en la nube y almacenamiento de datos

CC Switch soporta sincronizar datos de Providers mediante Dropbox, OneDrive, iCloud, NAS o WebDAV.

El almacenamiento local de datos también está claramente definido:

Base de datos: ~/.cc-switch/cc-switch.db
Configuración local: ~/.cc-switch/settings.json
Copias automáticas: ~/.cc-switch/backups/
Skills: ~/.cc-switch/skills/
Copias de Skills: ~/.cc-switch/skill-backups/

Usa SQLite como fuente principal de datos y enfatiza escrituras atómicas y copias automáticas, con el objetivo de evitar corrupción de archivos de configuración durante cambios o escrituras.

Este diseño importa para usuarios intensivos. Si la herramienta de gestión de configuración escribe una mala configuración, todas las herramientas de programación con IA pueden verse afectadas.

Instalación

CC Switch es una app de escritorio multiplataforma construida sobre Tauri 2.

Los requisitos aproximados del sistema son:

Windows: Windows 10 o posterior
macOS: macOS 12 Monterey o posterior
Linux: Ubuntu 22.04+, Debian 11+, Fedora 34+ y otras distribuciones principales

Los usuarios de Windows pueden descargar el instalador .msi o un paquete comprimido portable.

Los usuarios de macOS pueden instalarlo con Homebrew:

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

Para actualizar:

`1`	`brew upgrade --cask cc-switch`

Los usuarios de Linux pueden elegir .deb, .rpm o AppImage. Los usuarios de Arch Linux también pueden instalarlo con paru -S cc-switch-bin.

Al 6 de mayo de 2026, la página del repositorio muestra la última release como CC Switch v3.14.1, publicada el 23 de abril de 2026.

Stack técnico

Por la estructura del repositorio, CC Switch es una app de escritorio Tauri típica:

Frontend: React 18, TypeScript, Vite, TailwindCSS, TanStack Query, shadcn/ui
Backend: Tauri 2, Rust, SQLite, Tokio
Testing: Vitest, MSW, Testing Library

Los patrones de diseño principales incluyen:

SQLite como Single Source of Truth.
JSON para configuración local a nivel de dispositivo.
Escritura en la configuración viva de herramientas objetivo durante el cambio.
Rellenar ediciones del Provider actual desde la configuración viva.
Escrituras atómicas usando archivos temporales más rename.
Conexiones de base de datos bloqueadas para evitar problemas de escritura concurrente.

Esta arquitectura sugiere que el proyecto no es un script simple, sino una herramienta de escritorio diseñada para uso de largo plazo.

Para quién es

CC Switch encaja con estos usuarios:

Personas que usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw juntas.
Personas que cambian con frecuencia entre cuentas oficiales, relays de terceros, modelos locales o Providers de equipo.
Usuarios que ya usan MCP intensivamente.
Equipos que quieren mantener CLAUDE.md, AGENTS.md y GEMINI.md en un solo lugar.
Usuarios que instalan, prueban y migran Skills con frecuencia.
Personas que quieren ver historial de sesiones y uso entre distintas herramientas.

Si solo usas una herramienta de programación con IA, dependes del login oficial y rara vez tocas Providers, MCP o Skills, su valor puede no ser evidente.

Pero si ya entraste en un estado de “muchas herramientas, muchas cuentas, muchos Providers, muchos proyectos”, puede eliminar mucho trabajo repetitivo de configuración.

Qué vigilar

Herramientas como esta son cómodas, pero también necesitan límites claros.

Primero, gestiona configuración para múltiples AI CLIs, así que los usuarios deben asegurarse de confiar en la herramienta y su lógica de escritura.

Segundo, API keys, endpoints relay y servidores MCP son configuración sensible. Antes de activar sincronización en la nube, asegúrate de que la carpeta de sincronización y el servicio WebDAV sean seguros y confiables.

Tercero, después de cambiar Providers, la mayoría de herramientas todavía necesitan reiniciar la terminal o CLI para que los cambios surtan efecto. El README menciona que Claude Code soporta cambio en caliente de datos de Provider, pero otras herramientas normalmente aún requieren reinicio.

Cuarto, al volver al login oficial, es mejor añadir el provider oficial según las instrucciones del proyecto y luego volver a ejecutar el flujo de login de la herramienta correspondiente.

Resumen

El valor de CC Switch no está en crear otra herramienta de programación con IA. Su valor está en reconocer una realidad: el ecosistema de AI coding entró en una etapa donde coexisten múltiples herramientas.

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw tienen cada una sus propios sistemas de configuración, mientras MCP, Skills, Prompts y Providers se expanden rápidamente. Seguir editando archivos de configuración a mano terminará convirtiéndose en una carga.

CC Switch reúne estas piezas en una app de escritorio, facilitando cambiar Providers, sincronizar MCP, gestionar Skills, mantener archivos de prompt y ver sesiones. Para usuarios intensivos de programación con IA, herramientas como esta pueden pasar de “utilidad opcional” a “infraestructura diaria”.

Referencias

farion1231/cc-switch

Guía inicial de Codex App: instalación, sandbox, tareas paralelas, Skills y MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App puede entenderse como un espacio de trabajo de tareas para programación con IA. No es un IDE tradicional ni solo una ventana de chat. Reúne multitarea, gestión de proyectos, permisos de sandbox, Git, ejecución en la nube, plugins, Skills, MCP y automatización en una sola interfaz.

Si ya usas Codex CLI, Claude Code, Cursor u otros coding agents, la parte más interesante de Codex App es que convierte “ejecutar varios agentes en paralelo” en un flujo de escritorio más claro.

Para qué sirve Codex App

El valor central de Codex App no es responder preguntas, sino permitir que la IA ejecute tareas de forma continua dentro de un directorio de proyecto:

Editar código, ejecutar comandos e iniciar servidores de desarrollo.
Gestionar múltiples proyectos y múltiples tareas.
Ejecutar tareas largas localmente o en la nube.
Llamar plugins, Skills y MCP para ampliar capacidades.
Gestionar cambios mediante Git, worktree y flujos PR.

OpenAI también posiciona Codex App como una interfaz para gestionar múltiples coding agents. Es adecuada para personas que necesitan avanzar varias tareas de programación a la vez, especialmente páginas frontend, scripts, apps pequeñas, documentación y flujos de automatización.

Preparación antes de instalar

Antes de usar Codex App, conviene preparar tres herramientas básicas:

Git
Node.js
VS Code o tu IDE preferido

Codex App soporta macOS y Windows. Después de instalar, inicia sesión con tu cuenta de ChatGPT. En el primer lanzamiento, puedes elegir tu escenario principal de uso, como programación o trabajo diario. Codex precargará algunos plugins y Skills según tus elecciones, y luego puedes ajustarlos en configuración y en el marketplace de plugins.

Las funciones principales en Windows y macOS son bastante parecidas, pero algunas capacidades de automatización del ordenador pueden depender de la plataforma y del soporte de plugins. Usa lo que tu versión actual muestre realmente.

Estructura de interfaz: proyectos, tareas y chats

Codex App usa un diseño clásico de tres columnas:

Izquierda: proyectos, tareas, historial de chats, plugins y entradas de automatización.
Centro: ventana de chat actual.
Derecha: archivos, navegador, terminal, resultados de ejecución y otros paneles.

Un proyecto normalmente corresponde a una carpeta local. Puedes abrir varios chats dentro del mismo proyecto, o abrir varios proyectos a la vez para que distintos agentes trabajen en paralelo.

La lista de tareas muestra distintos estados:

Running: el agente sigue ejecutando.
Waiting for approval: debes confirmar permisos, red, instalación de dependencias o una acción de alto riesgo.
Completed: la tarea terminó, y puedes inspeccionar el resultado o seguir preguntando.

Esto es más intuitivo que cambiar entre varias ventanas de terminal, y se adapta mejor a gestionar varias tareas de IA a la vez.

Sandbox y control de permisos

El sistema de permisos de Codex App se construye alrededor del sandbox. Por defecto, la carpeta actual del proyecto se convierte en el workspace principal del agente.

Los límites de permisos comunes incluyen:

Puede leer y modificar archivos dentro del directorio del proyecto.
Por defecto no puede modificar libremente archivos fuera del proyecto.
La red o comandos de alto riesgo están restringidos por defecto.
Cuando necesita acceso elevado, pide aprobación al usuario.

Un modo práctico es “auto review”: las acciones de bajo riesgo se permiten automáticamente, mientras que las acciones de alto riesgo siguen siendo confirmadas por el usuario. Esto reduce ventanas emergentes frecuentes y evita que operaciones peligrosas ocurran en silencio.

“Full access” debe habilitarse con cautela. Es adecuado cuando sabes exactamente qué necesita hacer el agente, el proyecto ya tiene respaldos Git y los archivos importantes tienen copias separadas. No se recomienda como valor diario permanente.

Contexto, modelos y cuotas

Codex App muestra el uso de contexto del chat actual. Cuanto más larga es la conversación y más historial contiene, más contexto necesita procesar el modelo.

Hábitos útiles:

Empezar un chat nuevo después de terminar una tarea.
Los chats largos pueden comprimirse manualmente, pero no trates la compresión como memoria perfecta.
Para tareas complejas, declara claramente objetivos, límites y criterios de aceptación.
No pegues de golpe logs, errores o archivos grandes e irrelevantes en un chat.

Para selección de modelos, ajusta la fuerza de razonamiento según la complejidad de la tarea. Ediciones simples, escritura y tareas repetitivas no siempre necesitan el modelo más fuerte. Migraciones de arquitectura, bugs difíciles y refactors entre archivos encajan mejor con modelos más potentes.

Si la interfaz tiene un modo rápido, recuerda que normalmente consume más cuota. Úsalo cuando la velocidad importe, pero no como valor diario predeterminado.

Generación de imágenes y entradas multimodales

Codex App puede aceptar imágenes y archivos como contexto, y puede llamar generación de imágenes en escenarios adecuados.

Esto es útil para proyectos frontend y de contenido. Por ejemplo, puedes pedir a Codex:

Corregir estilos de página según capturas.
Reemplazar imágenes inadecuadas en una web.
Generar imágenes de producto, imágenes de carrusel o assets de página.
Señalar qué debe cambiarse a partir de una captura de UI.

Un enfoque más eficiente no es decir solo “hazlo más bonito”, sino usar capturas y señalar problemas concretos, como “el espacio en esta tarjeta es demasiado grande”, “esta imagen no coincide con la escena del servicio” o “haz más clara el área del mapa”.

Steer: corregir dirección durante la ejecución

Steer puede entenderse como tomar control de la dirección durante la ejecución. Si el agente ya empezó pero notas que entendió mal, no siempre conviene esperar a que termine para corregirlo.

Puedes usar steering para insertar una nueva instrucción en el flujo de ejecución actual y hacer que Codex corrija el rumbo.

Buenos casos de uso para Steer incluyen:

El agente entendió mal el requisito.
El estilo de página generado es claramente incorrecto.
El plan actual es demasiado costoso o pesado.
Necesitas añadir una restricción clave temporalmente.

En general, mantén el comportamiento predeterminado en cola y usa Steer manualmente solo cuando se necesite intervención. Esto evita interrumpir tareas normales y aun así permite recuperar la dirección en momentos clave.

Modo plan y navegador integrado

Para tareas complejas, empieza con modo plan. En modo plan, Codex no modifica código de inmediato. Primero produce un plan y puede hacer preguntas clave con tarjetas.

Tareas adecuadas para modo plan incluyen:

Migración de frameworks, como pasar un proyecto React a Next.js.
Refactors grandes.
Funciones que involucran bases de datos, autenticación o despliegue.
Requisitos donde aún no has decidido la ruta técnica.

El panel derecho de Codex App puede abrir un navegador integrado para previsualizar el servidor local de desarrollo. Puedes anotar la página y dejar que Codex modifique una ubicación específica de UI. Este flujo de “mirar la página, hacer clic en la posición y pedir a la IA que la cambie” suele ser mejor para depuración frontend que descripciones puramente textuales.

Git, IDE y rollback de código

Codex App no es un IDE completo. Puede ver código y añadir anotaciones, pero la edición manual sigue siendo mejor en VS Code, Cursor, Windsurf u otro IDE.

Todo proyecto de Codex debería inicializar Git temprano:

Pedir a Codex que cree o revise .gitignore.
Hacer un commit al llegar a un estado usable.
Asegurar un punto de commit limpio antes de cada cambio grande.
Volver atrás con Git si no estás satisfecho.

Si haces rollback solo del historial de chat, el código no vuelve automáticamente. Un enfoque más seguro es devolver el chat al punto correcto y luego usar un hash de commit Git para devolver el código al estado correspondiente.

Worktree: desarrollo paralelo en varias direcciones

git worktree es especialmente adecuado para agentes paralelos en Codex App.

Crea varios directorios de trabajo independientes desde el mismo repositorio, cada uno correspondiente a una rama distinta. Esto permite que diferentes agentes trabajen en distintas carpetas al mismo tiempo sin sobrescribirse.

Uso típico:

Un worktree optimiza el componente de reseñas de clientes.
Un worktree ajusta información de tienda y diseño del mapa.
Fusionar ambas tareas de vuelta a main tras completarlas.
Eliminar worktrees temporales después de fusionar.

Esto es mucho más seguro que dejar que varios agentes modifiquen código en el mismo directorio. Si hay conflictos, revísalos y fusiónalos con flujos Git normales.

Entorno de ejecución en la nube

Codex puede trabajar no solo en tu máquina local, sino también en un entorno de nube.

La ejecución en la nube es adecuada cuando:

Estás fuera y solo tienes un teléfono.
Quieres que los agentes ejecuten tareas largas en segundo plano.
El código ya se sincronizó con GitHub y Codex necesita modificar el repositorio remoto.
Quieres revisar y fusionar cambios mediante PRs.

Un flujo típico es: subir el código local a GitHub, dejar que Codex descargue el repositorio en un entorno de nube, ejecutar la tarea, generar cambios y presentarlos como PR o diff para revisión.

Al continuar el desarrollo local, recuerda traer los últimos cambios remotos.

Sistema de memoria: escribe un buen AGENTS.md

Los chats nuevos no tienen memoria histórica completa por defecto. Una vez que un proyecto se vuelve complejo, explicar el contexto repetidamente es ineficiente.

La solución más general es mantener AGENTS.md en la raíz del proyecto. Este archivo puede registrar:

Objetivos del proyecto y stack principal.
Comandos comunes.
Estructura de directorios.
Estilo de código y convenciones de nombres.
Acciones prohibidas, como borrar archivos en masa.
Reglas de pruebas, build y despliegue.

También puedes pedir a Codex que lea el proyecto y genere una primera versión de AGENTS.md, luego revisarla manualmente. Para proyectos complejos, vale la pena mantener este archivo.

Las reglas globales deben usarse con cuidado. Son adecuadas para restricciones universales de seguridad, como “no borrar directorios recursivamente” o “confirmar antes de operaciones destructivas”. No pongas detalles específicos del proyecto en reglas globales, o contaminarán otros proyectos.

Plugins y automatizaciones

Los plugins conectan Codex con servicios externos como GitHub, Gmail, Google Drive, bases de datos y plataformas de despliegue.

Su valor está en reducir copiar y pegar. Por ejemplo, Codex puede:

Revisar tendencias de estrellas de un repositorio GitHub.
Resumir contenido de email y enviártelo.
Ejecutar una revisión recurrente.
Escribir el resultado como resumen.

Las automatizaciones son adecuadas para tareas repetidas. Por ejemplo, revisar datos de un repositorio todos los viernes por la tarde y enviar un informe por email. Las tareas simples de automatización normalmente no requieren el modelo más fuerte; basta un modelo más ligero.

Skills: convertir flujos de trabajo en capacidades reutilizables

Las Skills son “manuales profesionales” para Codex. No son prompts de una sola vez. Empaquetan un flujo de tarea, reglas, scripts y notas para que Codex pueda reutilizarlos de forma fiable después.

Fuentes comunes incluyen:

Skills oficiales.
Skills de terceros.
Skills escritas por ti.

Buenos candidatos para Skills incluyen:

Convertir subtítulos en notas ilustradas.
Escribir informes semanales con formato de empresa.
Procesar imágenes o documentos por lotes.
Revisiones de código con formato fijo.
Inicialización de proyectos para un framework concreto.

Si has copiado y pegado el mismo prompt muchas veces, vale la pena convertirlo en una Skill.

MCP: conectar herramientas externas y bases de datos

MCP puede entenderse como un protocolo estandarizado de herramientas para modelos grandes. Mediante MCP, Codex puede llamar servicios externos para completar tareas más concretas.

Por ejemplo, después de conectar Supabase, Codex puede:

Crear tablas de base de datos.
Leer esquemas de base de datos.
Modificar endpoints backend.
Enviar formularios frontend a la base de datos.
Depurar problemas según el estado de la base de datos.

Esto es poderoso, pero los permisos importan. Bases de datos, entornos de producción, plataformas de despliegue y cuentas de email son recursos de alto riesgo. Al conectarlos por primera vez, usa un proyecto de prueba y una cuenta con pocos privilegios.

Plugins de despliegue

Los plugins de plataformas de despliegue pueden permitir que Codex complete builds y releases directamente, como desplegar un proyecto frontend en Netlify.

Estos plugins son adecuados para sitios pequeños, prototipos, herramientas internas y demos. En uso real, presta atención a:

Ejecutar un build local antes del despliegue.
No escribir variables de entorno directamente en el código.
Comprobar que la página abre normalmente después de publicar.
Mantener revisión humana para proyectos de producción.

La IA puede ayudar a conectar el flujo de despliegue, pero los permisos de despliegue deben gestionarse con cuidado.

Automatización del ordenador

Con plataformas y entornos de plugins soportados, Codex también puede operar navegadores o apps de escritorio, completando tareas más cercanas a RPA.

Ejemplos:

Abrir una app de chat y preparar un mensaje.
Navegar un tablero de proyecto y resumir estado de tareas.
Generar un brief en inglés.
Enviarlo a un destinatario especificado después de tu confirmación.
Convertir el flujo en una automatización programada.

Estas capacidades son imaginativas, pero requieren los límites de seguridad más fuertes. Cualquier operación que implique enviar mensajes, enviar email, enviar formularios, pagos o eliminar datos debe conservar confirmación humana.

Sugerencias de uso

La forma correcta de usar Codex App no es dejarle tomar todo de golpe, sino dividir tareas y permitir que ejecute eficientemente en un entorno controlado.

Hábitos recomendados:

Inicializar Git en cada proyecto.
Usar modo plan para tareas complejas.
Usar worktree para tareas paralelas.
Poner reglas de proyecto en AGENTS.md.
Mantener confirmación humana para acciones de alto riesgo.
Convertir flujos repetidos en Skills o automatizaciones.
Validar plugins y MCP primero en un entorno de prueba.

Referencias

Resumen

Codex App no es “otra ventana de chat con IA”. Su foco es convertir la programación con IA en un espacio de trabajo gestionable, donde proyectos locales, tareas en la nube, Git, worktree, plugins, Skills, MCP y automatización puedan conectarse.

La clave para usarla bien es equilibrar libertad y control. Las tareas pequeñas pueden entregarse a Codex con confianza. Las tareas complejas deben empezar con un plan. Las acciones de alto riesgo deben confirmarse. Usada así, Codex puede convertirse no solo en un asistente que escribe código, sino en una herramienta de ingeniería de largo plazo.

Por que ChatGPT y Codex piden verificar el numero de telefono al iniciar sesion

Tue, 05 May 2026 23:57:50 +0800

Algunos usuarios se encuentran con esta situacion: la cuenta de ChatGPT ya fue registrada correctamente, pero al iniciar sesion en ChatGPT o Codex el sistema vuelve a pedir verificar un numero de telefono. Esto resulta especialmente confuso en Codex: si la cuenta ya se registro, ¿por que el inicio de sesion de la herramienta exige telefono?

Este tipo de problema suele estar relacionado con controles de riesgo de cuenta, abuso de cuotas gratuitas, entorno de red y politicas de seguridad. A continuacion se organizan las causas comunes y las formas de abordarlo.

Por que se exige verificar telefono

La causa mas directa es un endurecimiento del control de riesgo.

Despues de abrir Codex a usuarios, las cuotas gratuitas atraen a muchos usuarios reales, pero tambien a registros masivos y captacion automatizada de cuotas. Si alguien usa registradores para crear cuentas en lote y consumir esas cuotas, la plataforma tiende a endurecer la verificacion.

Desde el lado del usuario, el resultado es que una cuenta que antes solo necesitaba correo o login de terceros de pronto exige agregar verificacion de telefono al iniciar sesion en ChatGPT o Codex.

Esto no significa necesariamente que tu cuenta tenga un problema. Tambien puede indicar un entorno de inicio de sesion de mayor riesgo, por ejemplo:

Uso de una salida de red compartida por muchos usuarios.
Un rango de IP usado con frecuencia para registros o logins anormales.
Cuenta recien creada que accede enseguida a herramientas de alto consumo.
Cambios frecuentes de dispositivo, region o red.
Comportamiento de cuenta gratuita parecido al de cuentas masivas.

Si recientemente hubo anomalias de cuenta, restricciones de inicio de sesion o bloqueos por error, tambien puede estar relacionado con una marca indirecta del entorno de red. Los nodos compartidos por muchas personas tienen un riesgo claramente mayor.

Por que Codex lo activa con mas facilidad

Codex es distinto del chat normal. Se parece mas a una herramienta de desarrollo, puede implicar mayor consumo de recursos y es mas facil que cuentas masivas lo usen para gastar cuotas gratuitas.

Por eso no es raro que la misma cuenta parezca normal en la pagina de ChatGPT, pero active verificacion de telefono en el flujo de inicio de sesion de Codex. Puede entenderse asi: distintos productos tienen entradas con distintas evaluaciones de riesgo.

Para usuarios normales, esta verificacion normalmente no busca dificultar el uso individual, sino limitar el registro masivo y el abuso de cuotas gratuitas. Pero si el entorno de red no esta limpio, tambien puede haber falsos positivos.

Metodo 1: actualizar a Plus

Si usas ChatGPT o Codex de forma prolongada, la forma mas sencilla de manejarlo es actualizar a ChatGPT Plus.

En la experiencia practica, las cuentas de pago suelen activar con menos frecuencia controles de abuso de cuotas que las cuentas gratuitas. Una cuenta Plus tambien es mas adecuada para usar Codex, modelos avanzados de ChatGPT y funciones de alta frecuencia de forma estable.

Pero hay que recordar que actualizar a Plus no significa que nunca volvera a pedirse verificacion. Si despues de pagar aun se exige telefono, la causa frecuente sigue siendo el entorno de red.

En ese caso conviene revisar:

Si estas usando una red compartida por muchos usuarios.
Si la IP de salida cambia con frecuencia.
Si usas desde hace tiempo proxies baratos o nodos publicos de baja calidad.
Si en la misma red inician sesion muchas cuentas de OpenAI.

Si es posible, iniciar sesion desde una red mas estable y limpia suele ser mas efectivo que repetir intentos.

Metodo 2: revisar el entorno de red

Muchos problemas de verificacion al iniciar sesion parecen problemas de cuenta, pero en esencia son problemas de red.

Si una IP de salida es compartida por muchas personas, o se uso antes para registros masivos, logins anormales o solicitudes automatizadas, es mas facil que sea marcada. En ese caso, aunque seas un usuario normal, ChatGPT o Codex pueden pedir verificacion adicional.

Puedes revisar estos puntos:

Cambia a un entorno de red mas estable.
Evita nodos publicos, baratos o compartidos por muchas personas.
Reduce cambios frecuentes de region en poco tiempo.
No cambies muchas cuentas dentro del mismo navegador.
Si usas proxy, prioriza lineas mas estables y con menos abuso.

Tambien puedes usar herramientas externas para evaluar el riesgo de la IP actual, pero esos resultados solo son referencia y no representan por completo el criterio interno de OpenAI.

Metodo 3: completar la verificacion de telefono

Si el sistema exige claramente verificacion de telefono, lo mas seguro es completarla como se pide.

Conviene usar un numero propio que puedas conservar y recibir codigos a largo plazo. Asi, si despues aparece una verificacion de seguridad, recuperacion de acceso o alerta anormal, podras gestionarla.

No se recomienda vincular una cuenta importante a numeros de origen desconocido, compartidos por muchas personas o que no puedas usar durante mucho tiempo. A corto plazo pueden pasar la verificacion, pero a largo plazo traen riesgos de recuperacion, auditoria de seguridad y segunda verificacion.

Si usas una cuenta de trabajo, cuenta de equipo o cuenta de desarrollo de la que dependes a largo plazo, deberias evitar todavia mas los numeros temporales no controlados. La seguridad de la cuenta importa mas que ahorrar unos minutos.

Que cuidar al actualizar a Plus

Si vas a actualizar a Plus, confirma primero varias cosas:

La cuenta puede iniciar sesion con normalidad.
El entorno de red es estable y no cambia de region frecuentemente.
El metodo de pago es fiable; evita pagos de origen desconocido.
Conserva comprobantes de pago y el correo de la cuenta.
No prestes la cuenta para uso compartido por muchas personas.

Muchos problemas de cuenta no vienen de Plus en si, sino de la red, el pago y los habitos de uso compartido antes y despues de actualizar. Una cuenta usada por muchas personas, con logins frecuentes desde lugares distintos y cambios constantes de entorno, puede activar verificaciones aunque sea de pago.

Si solo pruebas ocasionalmente, una cuenta gratuita puede seguir sirviendo. Pero si ya usas Codex como herramienta diaria de desarrollo, Plus es mas adecuado para el uso estable a largo plazo.

No conviene seguir exprimiendo cuotas gratuitas

Las cuotas gratuitas de herramientas como Codex existen para que usuarios normales prueben y experimenten. Si muchas cuentas masivas consumen esas cuotas de forma continua, la plataforma solo puede aumentar la intensidad del control de riesgo.

El resultado es que los usuarios normales tambien se ven afectados: iniciar sesion se vuelve mas molesto, aparecen mas verificaciones, aumentan los bloqueos por error y sube el coste de uso de la cuenta.

Para quienes realmente usan Codex para escribir codigo, modificar proyectos y ejecutar tareas de ingenieria, es mejor ordenar la cuenta y el entorno de red que gastar tiempo evitando controles. A largo plazo, eso ahorra mas trabajo que registrar cuentas nuevas, cambiar nodos y resolver verificaciones una y otra vez.

Resumen

Cuando ChatGPT o Codex piden verificar un numero de telefono al iniciar sesion, normalmente esta relacionado con control de riesgo de cuenta, abuso de cuotas gratuitas y riesgo del entorno de red. No significa necesariamente que la cuenta haya infringido reglas, pero si indica que el entorno de login o el estado de la cuenta activo una verificacion superior.

El orden de manejo puede ser simple:

Primero revisa la red y evita salidas compartidas o de alto riesgo.
Si lo usas a largo plazo, considera actualizar a Plus.
Si el sistema exige telefono, usa preferiblemente un numero que controles a largo plazo.
Evita registros masivos, cuentas compartidas y cambios frecuentes de entorno.

La clave para usar herramientas de IA de forma estable no es saltarse verificaciones todo el tiempo, sino mantener normales la cuenta, la red y la forma de uso. Asi se reducen los problemas de inicio de sesion y tambien la probabilidad de falsos positivos posteriores.

Compound Engineering Plugin: convertir la programación con IA en un ciclo de planificación, ejecución y revisión

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin es un plugin de flujo de trabajo de programación con IA publicado como open source por Every Inc.

No se centra en “hacer que la IA escriba un fragmento de código más rápido”, sino en colocar la programación con IA dentro de un ciclo más parecido al de un equipo de ingeniería: primero planificar, luego implementar, después revisar y finalmente conservar la experiencia aprendida. Para quienes usan con frecuencia herramientas como Claude Code, Codex, Cursor o Copilot, este tipo de plugin resuelve un problema de flujo de trabajo, no solo de prompts.

Las herramientas de programación con IA son cada vez más fuertes, pero en proyectos reales lo más difícil no suele ser generar código, sino lograr que siga de forma continua las reglas del proyecto, entienda los límites de la tarea, evite repetir errores y acumule contexto durante iteraciones largas.

Qué problema resuelve

Muchas personas usan asistentes de programación con IA más o menos así:

Describen directamente el requisito
Dejan que la IA modifique código
Miran si el resultado puede ejecutarse
Si hay error, añaden más instrucciones
En la siguiente tarea vuelven a explicar desde cero

Este método puede completar tareas pequeñas, pero en proyectos complejos aparecen problemas con facilidad:

El requisito no se divide primero con claridad y la IA empieza a modificar directamente
Falta una review sistemática después de los cambios
Las reglas del proyecto dependen de que el usuario las recuerde una y otra vez
El mismo tipo de error vuelve a aparecer en la siguiente ocasión
Falta un método de trabajo común entre varias herramientas Agent
La experiencia no se convierte en reglas reutilizables

Compound Engineering Plugin quiere resolver precisamente estos problemas. Divide la programación con IA en varias etapas, para que el Agent no solo ejecute comandos, sino que participe en un proceso de ingeniería más completo.

Qué es Compound Engineering

Según la descripción del README del proyecto, Compound Engineering puede entenderse como un método de desarrollo de software asistido por IA.

Destaca un ciclo:

Planificación: entender primero el objetivo, dividir tareas y confirmar la ruta
Ejecución: modificar código según el plan, ejecutar comandos y tratar problemas
Revisión: comprobar calidad de implementación, riesgos y cobertura de pruebas
Aprendizaje: convertir la experiencia en reglas reutilizables para el futuro

Este ciclo se parece mucho a la forma de trabajo de un equipo de ingeniería real.

Un ingeniero fiable no recibe un requisito y empieza a cambiar cosas sin rumbo, ni entrega directamente después de modificar. Primero evalúa el alcance de impacto, luego implementa, después revisa riesgos y resultados de pruebas, y finalmente registra los problemas encontrados. Los AI Agent también necesitan restricciones similares.

Por qué hace falta un plugin

Un prompt puede decirle a la IA “planifica antes de ejecutar”, pero el prompt por sí mismo no siempre es estable.

Cuando la conversación se alarga y el contexto se vuelve complejo, el modelo puede saltarse la planificación, ignorar reglas o volverse demasiado confiado para terminar la tarea. El valor del plugin está en fijar el proceso para que distintos entornos Agent sigan un método parecido.

Este tipo de plugin suele dividir el flujo de trabajo en comandos, reglas, plantillas o subprocesos. El usuario no necesita escribir cada vez un prompt completo, sino que activa una etapa mediante una entrada fija.

Por ejemplo:

Pedir primero al Agent que genere un plan
Implementar después paso a paso según el plan
Activar review tras terminar los cambios
Volver a corregir cuando se encuentren problemas
Escribir las experiencias valiosas en memoria o reglas

Esto hace que la programación con IA se parezca más a una “colaboración controlada” que a una conversación de una sola vez.

Qué entornos Agent soporta

El README menciona que el proyecto soporta varios entornos de programación con IA, incluyendo:

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

Este punto es importante.

Muchas herramientas de flujo de trabajo están atadas a un solo cliente; al cambiar de herramienta, las reglas dejan de reutilizarse. Compound Engineering Plugin se parece más a un método de ingeniería transversal a distintos Agent, llevando procesos similares de planificación, ejecución y revisión a varias herramientas.

Si usas varios asistentes de programación con IA al mismo tiempo, este tipo de flujo unificado gana valor. Las herramientas tienen capacidades distintas, pero las normas del proyecto, los hábitos de review y el método de división de tareas deberían ser lo más consistentes posible.

Para qué sirve la etapa de planificación

El valor de la planificación es evitar que la IA actúe demasiado pronto.

En tareas complejas, las preguntas realmente importantes suelen ser:

Qué archivos hay que modificar
Qué módulos pueden verse afectados
Cuál es el patrón existente
Si hay pruebas
Dónde están los riesgos
Si hay que leer documentación antes
Si puede dividirse en pasos más pequeños

Si el Agent no piensa primero estas preguntas y se pone a escribir código directamente, es fácil que produzca una implementación que parece terminada, pero que se aleja de la estructura del proyecto.

El plan no tiene que ser largo. Un buen plan debería ser corto, concreto y ejecutable. Su objetivo no es fabricar documentación, sino dar límites a la implementación posterior.

Qué evitar en la etapa de ejecución

Cuando la IA ejecuta tareas de código, aparecen con facilidad varios problemas:

Refactorizar código no relacionado de paso
Sobrescribir cambios existentes del usuario
Cambiar solo el happy path
Ignorar manejo de errores
No seguir el estilo existente del proyecto
No ejecutar validaciones necesarias
Probar a ciegas tras encontrar errores

Un plugin de flujo de trabajo no puede garantizar que estos problemas desaparezcan por completo, pero puede reducir su frecuencia mediante reglas y restricciones por etapa.

Por ejemplo, la etapa de ejecución puede pedir al Agent que avance paso a paso según el plan; si descubre algo fuera del alcance previsto, primero explica el riesgo; si modifica módulos compartidos, añade pruebas o al menos ejecuta validaciones relacionadas.

Esta restricción es especialmente importante en codebases grandes. Cuanto más rápido escribe código la IA, más necesita un proceso que limite su inercia.

Por qué importa la etapa de review

Muchos fallos de programación con IA no ocurren porque el código no pueda ejecutarse en absoluto, sino porque los detalles están mal:

No se tratan condiciones límite
Las actualizaciones de estado no son consistentes
El contrato de API se cambia en silencio
Las pruebas no cubren rutas clave
Los mensajes de error no son claros
No se mencionan riesgos de rendimiento o seguridad

La etapa de review cambia al Agent de “modo autor” a “modo revisor”.

El modo autor tiende a justificar su propia implementación; el modo revisor debe buscar activamente defectos, riesgos de regresión y pruebas omitidas. Separar estas dos etapas suele ser más fiable que pedir en una misma respuesta que implemente y se autoevalúe.

Para el usuario, la salida de review también es más valiosa. Ayuda a decidir rápidamente si este cambio merece integrarse o si necesita otra ronda de trabajo.

El sentido de aprendizaje y memoria

La palabra “Compound” del nombre del proyecto sugiere una idea importante: la experiencia de ingeniería debería crecer con efecto compuesto.

Si cada vez que la IA comete un error solo lo arregla en ese momento, pero la próxima vez comete el mismo error, la mejora de eficiencia es limitada. Un mejor método es conservar la experiencia útil:

Convenciones de directorios del proyecto
Métodos de diagnóstico para ciertos errores
Comandos de prueba y precauciones
Archivos generados que no deben tocarse
Preferencias de estilo de código
Patrones de implementación habituales

Estas experiencias pueden convertirse en reglas, memoria, documentación o plantillas. En tareas posteriores, el Agent lee primero ese conocimiento acumulado y luego empieza a trabajar.

Esa es la clave para que la programación con IA pase de “pregunta y respuesta puntual” a “colaboración de largo plazo”.

Escenarios adecuados

Compound Engineering Plugin es adecuado para:

Usar AI Agent para escribir código de forma continua
Modificar un mismo proyecto durante muchas rondas
Querer que la IA planifique antes de implementar
Querer que después de modificar entre automáticamente en mentalidad de review
Equipos que quieren unificar el flujo de programación con IA
Personas que usan a la vez Claude Code, Codex, Cursor y otras herramientas
Querer convertir experiencia del proyecto en reglas reutilizables

Si solo pides ocasionalmente a la IA que escriba un pequeño script, el flujo completo puede parecer pesado.

Pero si estás tratando al asistente de programación con IA como un compañero diario de desarrollo, el ciclo de planificación, ejecución, revisión y aprendizaje se vuelve claramente útil.

Diferencia frente a plantillas de prompt comunes

Las plantillas de prompt comunes suelen resolver “cómo expresar bien la tarea”.

Por ejemplo:

Piensa paso a paso
Lee primero los archivos
Mantén el estilo de código
Ejecuta pruebas
Resume los cambios

Estas indicaciones son útiles, pero siguen dependiendo de que el usuario las use correctamente cada vez.

Compound Engineering Plugin se sitúa más en la capa de flujo de trabajo. Organiza estos requisitos en un proceso repetible y lo adapta a distintas herramientas Agent. Así, no partes de cero escribiendo prompts cada vez, sino que avanzas dentro de un proceso.

En pocas palabras, una plantilla de prompt se parece a un recordatorio; un plugin de flujo de trabajo se parece a un sistema.

Precauciones al usarlo

Primero, no conviertas el proceso en una carga.

Las tareas pequeñas no siempre necesitan un plan completo y una review larga. Un buen flujo de trabajo debería ajustarse a la complejidad de la tarea: resolver rápido los problemas simples y usar el ciclo completo en problemas complejos.

Segundo, la review no sustituye a las pruebas.

Una review hecha por Agent puede encontrar muchos problemas, pero aun así puede omitir errores reales de ejecución. El juicio final depende de pruebas, type checking, resultados de build y revisión humana.

Tercero, hay que limpiar reglas de forma continua.

Acumular experiencia es importante, pero demasiadas reglas también se convierten en ruido. Reglas obsoletas, repetidas o que solo servían para una tarea puntual deberían ordenarse periódicamente.

Cuarto, consistencia entre herramientas no significa identidad total.

Claude Code, Codex, Cursor, Copilot y otras herramientas tienen capacidades e interacciones diferentes. Lo que se unifica es el método de trabajo, no necesariamente cada comando ni cada detalle de configuración.

Qué equipos pueden aprovecharlo

Si un equipo ya permite que AI Agent modifique código real, no basta con discutir “qué modelo es más fuerte”.

Debería preocuparse más por:

Si la IA entiende la tarea antes de modificar
Si respeta límites del proyecto mientras modifica
Si revisa riesgos activamente después de modificar
Si aprende de errores históricos
Si el equipo tiene una norma común de uso de Agent

Ahí está el sentido de proyectos como Compound Engineering Plugin. Llevan la programación con IA desde una habilidad personal hacia un proceso reutilizable por el equipo.

Referencia

EveryInc/compound-engineering-plugin

Una última frase

Lo que merece atención de Compound Engineering Plugin no es que añada un comando más de programación con IA, sino que organiza la programación con IA como un proceso de ingeniería que puede mejorar en ciclos.

Cuando los AI Agent empiezan a participar en proyectos reales, planificación, ejecución, revisión y acumulación de experiencia importan más que generar código una sola vez.

Codex está empezando a controlar la computadora. ¿Qué significa eso para el futuro?

Wed, 29 Apr 2026 11:28:25 +0800

La parte más importante de esta actualización del Codex no es que agregó otro botón común y corriente. Es que el Codex está empezando a avanzar hacia “controlar la computadora”.

En el pasado, usar IA generalmente significaba hacer preguntas en un cuadro de chat, copiar, pegar y luego operar manualmente el software.
Ahora ese límite se está ampliando: la IA no solo te responde. Puede operar aplicaciones de escritorio según su objetivo.

A corto plazo, esta es una característica nueva. A largo plazo, puede cambiar la cantidad de personas que usan computadoras.

¿Qué es esta característica?

En pocas palabras, la capacidad de uso de computadoras de Codex le permite acceder y operar el entorno de escritorio.

Puede hacer cosas como:

seleccionar y controlar una aplicación
recibir tareas en lenguaje natural
abrir navegadores, herramientas de inteligencia artificial, archivos locales u otro software
ingrese texto, haga clic en botones y espere resultados
conectar varios pasos en una tarea
seguir ejecutándose en segundo plano sin necesidad de que el usuario siga cada paso manualmente

Su función no es solo escribir un texto para usted, sino también completar un flujo de operación para usted.

Esa es la diferencia clave entre un Agente y un chatbot común y corriente:
un chatbot da principalmente respuestas; un Agente está más cerca de “recibir un objetivo y luego ejecutarlo”.

Por qué esto es importante

En el pasado, gran parte de la automatización requería que supieras escribir guiones.

Por ejemplo, supongamos que desea completar un flujo de trabajo entre software:

abrir una página web
encontrar información
copiar contenido
pásalo a otra herramienta de IA
guardar un archivo
abre el directorio local y comprueba el resultado

Para automatizar esto de forma tradicional, es posible que necesite scripts de navegador, API, programas locales e incluso automatización de ventanas.

Pero muchos usuarios comunes y corrientes no saben cómo escribir estas cosas.
Incluso si lo hacen, puede que no valga la pena escribir un guión para una tarea temporal.

Aquí es donde importa el uso de la computadora: empuja la “capacidad similar a un script” hacia el lenguaje natural.

No es necesario que le diga exactamente dónde hacer clic.
Puede decirle qué resultado desea y dejar que intente completar la tarea.

Flujos de trabajo que pueden cambiar

Creo que los primeros flujos de trabajo que cambiarán no serán trabajos extremadamente serios o de alto riesgo, sino tareas molestas, fragmentadas, repetitivas y para las que no vale la pena escribir un programa dedicado.

1. Mover información a través del software

El caso más típico es el de mover información entre aplicaciones.

Anteriormente, podía alternar entre un navegador, un documento, una ventana de chat y una carpeta local.
En el futuro, podrás encargar este tipo de tarea a un Agente:

encontrar cierto tipo de información
resumirlo en un documento
guárdelo en un directorio específico
abre el resultado para que lo revises

Este trabajo no es difícil, pero requiere atención.
El valor de un Agente es que absorbe estas pequeñas operaciones.

2. Coordinación entre múltiples herramientas de IA

El flujo de trabajo real de muchas personas ya no se basa en una única herramienta de inteligencia artificial.

Puede verse así:

una herramienta escribe código
una herramienta busca información
una herramienta genera imágenes
una herramienta organiza documentos

Anteriormente, estas herramientas se conectaban mediante copiar y pegar manualmente.
En el futuro, un Agente puede convertirse en la capa intermedia: abre herramientas, pasa contexto, espera resultados y organiza resultados. Esto puede convertir “múltiples herramientas de IA trabajando juntas” de un proceso manual a un proceso semiautomático.

3. Automatización del software de oficina

Las hojas de cálculo, las presentaciones, los documentos y el correo electrónico comparten una característica: son potentes, pero muchas operaciones están fragmentadas.

Si los agentes pueden controlar este software de forma fiable, la barrera a la automatización de oficinas disminuirá notablemente.

No es necesario recordar dónde está un menú ni aprender atajos complicados.
Solo necesitas describir el objetivo, como por ejemplo:

convierta esta hoja de cálculo en un informe mensual
hacer un resumen de una página de este documento
combinar estos materiales en una explicación claramente estructurada

Las tediosas operaciones de los botones quedarán gradualmente ocultas detrás del lenguaje natural.

Qué significa para los usuarios comunes

Para los usuarios comunes, este tipo de característica puede tener un impacto más directo que “el modelo se volvió un poco más inteligente”.

Porque reduce la barrera operativa, no sólo la barrera del conocimiento.

Muchas personas pueden describir lo que quieren, pero no saben dónde hacer clic o cómo combinar funciones dentro del software.
Si los Agentes pueden hacerse cargo de esta parte, el uso de una computadora puede convertirse en:

1
2
3

I describe the goal
Agent operates the software
I check the result

Esto está más cerca de la productividad real que un simple chat.

Su impacto en el software

Si este tipo de capacidad del Agente continúa madurando, el software en sí también se verá afectado.

En el pasado, el diseño de software se basaba principalmente en el clic humano.
En el futuro, es posible que también sea necesario que el software sirva para la operación del Agente.

Esto significa:

los elementos de la interfaz deben ser más claros
la retroalimentación de operación debe ser más estable
los permisos locales deben ser más granulares
el software puede proporcionar interfaces más adecuadas para las llamadas de los agentes
A los usuarios les puede interesar más si la IA puede operar el software sin problemas

A largo plazo, los límites entre las aplicaciones pueden volverse más delgados.
Es posible que a los usuarios les importe menos “qué aplicación debo abrir” y más “qué tarea quiero completar”.

No lo exageres todavía

Por supuesto, todavía no es momento de dejarlo ir por completo.

Este tipo de capacidad todavía tiene varias limitaciones claras:

la estabilidad aún necesita observación
las tareas complejas pueden fallar en el medio
los límites de los permisos deben manejarse con cuidado
Las operaciones de eliminación de cuentas, pagos y archivos no deben delegarse a la ligera.
el consumo de cuotas no es algo que puedas ignorar por completo

Entonces, en esta etapa, el mejor caso de uso es no dejar que se haga cargo de toda la computadora, sino permitir que maneje tareas de bajo riesgo, revisables y con muchos pasos.

Por ejemplo:

organización de materiales
generar borradores
mover contenido entre herramientas
abrir y comprobar archivos
ejecutar flujos de trabajo semiautomáticos que pueden ser revisados por un humano

Una última línea

La verdadera importancia de esta actualización del Codex es que empuja a la IA de “responder preguntas” a “operar el entorno”.

A corto plazo, es una característica del uso de la computadora.
A largo plazo, puede marcar un cambio en la forma en que se utilizan las computadoras personales.

En el futuro, es posible que dediquemos menos tiempo a recordar botones, buscar menús y cambiar de ventana.
Más a menudo, describiremos el objetivo, dejaremos que un Agente lo ejecute y luego dejaremos que los humanos tomen el juicio final.

¿Por qué existe una habilidad del Codex en el directorio pero aún no aparece?

Wed, 29 Apr 2026 11:18:00 +0800

Este problema era fácil de pasar por alto: varias habilidades ya estaban ubicadas en ~/.codex/skills, pero después de abrir un nuevo hilo del Codex, la barra lateral todavía mostraba solo un pequeño subconjunto de ellas.

Al principio, parecía un problema de caché o de indexación. La causa real fue más específica: varios archivos SKILL.md comenzaron con una lista de materiales UTF-8. El cargador de habilidades de Codex 0.111.0 no omitió esa secuencia de bytes, por lo que calculó erróneamente que los archivos no tenían contenido YAML válido.

Síntoma

El directorio local contenía estas habilidades:

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

Pero después de abrir un hilo nuevo, las habilidades realmente expuestas fueron solo:

1
2

bilibili-speech-transcriber
product-cutout-normalize

En otras palabras, un archivo existente en el disco no significa que la sesión actual pueda cargarlo correctamente. Codex analiza primero la portada de cada SKILL.md. Si el análisis falla, esa habilidad se excluye directamente.

Investigación

Iniciar una nueva sesión con codex exec mostró un error más directo. En VS Code u otros IDE, es posible que estos registros no sean visibles:

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

Visualmente, estos archivos parecían tener un encabezado normal:

---
name: post-rewrite
description: ...
---

El verdadero problema estaba en el nivel de bytes.

El comienzo de un archivo fallido fue:

`1`	`EF-BB-BF-2D-2D-2D`

El comienzo de un archivo que se cargó correctamente fue:

`1`	`2D-2D-2D`

2D-2D-2D es ---. El EF-BB-BF anterior es la lista de materiales UTF-8.

Causa

En Codex 0.111.0, el cargador de habilidades espera que el primer byte de SKILL.md sea el primer - en ---.

Si el archivo comienza con una lista de materiales UTF-8, el comienzo real será:

`1`	`BOM + ---`

Entonces, el cargador piensa que el archivo no comienza con el delimitador inicial e informa:

`1`	`missing YAML frontmatter delimited by ---`

El contenido de la habilidad no era incorrecto y el directorio tampoco era incorrecto. Un pequeño detalle de codificación impidió que el analizador reconociera el archivo.

Arreglar

Convierta los archivos SKILL.md afectados a UTF-8 sin BOM.

En PowerShell, esto se puede hacer así:

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

Después del procesamiento, el encabezado del archivo debería cambiar de:

`1`	`EF-BB-BF-2D-2D-2D`

`1`	`2D-2D-2D`

Verificación

Después de reiniciar una sesión del Codex, las habilidades visibles se restauraron en:

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

Si la barra lateral todavía muestra la lista anterior, cierre la barra lateral o ventana actual del Codex y vuelva a abrir el proyecto. La lista de habilidades generalmente se carga cuando comienza la sesión, por lo que es posible que los cambios realizados en mitad de una sesión no se actualicen inmediatamente.

Una última línea

Este tipo de problema es fácil de confundir con “El Codex no se volvió a indexar” o “la habilidad no se instaló correctamente”.

Al solucionar problemas, verifique primero estas tres cosas:

si SKILL.md está realmente en el directorio correcto
si el archivo tiene un texto inicial --- válido en la parte superior
si el archivo es UTF-8 sin BOM

La clave en este caso fue el tercer punto: el archivo se veía bien, pero su primer byte no era “-”, por lo que Codex no lo trató como una habilidad válida.

¿Cuál es la diferencia entre ~/.codex/skills y Project .codex/skills en Codex?

Wed, 29 Apr 2026 11:08:00 +0800

Al organizar las habilidades del Codex, la gente suele quedarse estancada en dos preguntas:

¿Cuál es la diferencia entre ~/.codex/skills y project/.codex/skills?
¿Por qué existe una habilidad en el directorio pero no aparece en la sesión actual?

Aquí está la versión corta.

La diferencia

La forma más sencilla de recordarlo:

~/.codex/skills es tu biblioteca de habilidades global
project/.codex/skills es la biblioteca de habilidades local para ese repositorio

`~/.codex/skills`

Úselo para:

Habilidades que reutilizas personalmente en todos los proyectos.
flujos de trabajo generales que no están vinculados a un repositorio específico
flujos de trabajo que claramente pertenecen a sus propios hábitos

Por ejemplo:

post-reescritura
post-traducir -git-commit-push -hugo-rsync-deploy
bilibili-transcriptor-de-voz

El rasgo clave de este tipo de habilidad es: todavía tiene sentido fuera del proyecto actual.

`proyecto/.codex/skills`

Úselo para:

flujos de trabajo que solo se aplican a este repositorio
reglas estrechamente acopladas a la estructura, scripts o plantillas del proyecto actual
Habilidades que deben ser compartidas por el equipo.

Por ejemplo:

un flujo de trabajo de publicación específico para este repositorio
una plantilla de generación que solo funciona en este proyecto
pasos de automatización estrechamente vinculados a scripts de proyectos privados

El rasgo clave de este tipo de habilidad es: deja de ser significativo una vez que sale de este repositorio.

Cuándo utilizar habilidades globales y cuándo utilizar habilidades de proyecto

Esta regla general es suficiente:

Si se trata de tus hábitos personales, ponlo en ~/.codex/skills
Si se trata de reglas del repositorio, colóquelo en project/.codex/skills
Si se puede reutilizar en todos los proyectos, prefiera global
Si debe ser compartido por varias personas y evolucionar con el repositorio, prefiera el nivel de proyecto

El repositorio actual

Basado en el estado actual:

su máquina tiene ~/.codex/skills
este repositorio no tiene .codex/skills

Así que ahora mismo dependes principalmente de las habilidades globales.

Eso significa que flujos de trabajo como “post-reescritura”, “post-traducción” y “git-commit-push” son actualmente más bien parte de su flujo de trabajo personal, no algo incluido explícitamente con este repositorio.

Por qué existe una habilidad en el disco pero puede no aparecer en la sesión actual

Hay dos cosas diferentes aquí:

Existente en el disco: el archivo de habilidad existe en un directorio local
Expuesto a la sesión: la sesión actual lo registró en la lista de habilidades disponibles

Estos no son lo mismo.

Entonces esto puede suceder:

ya existe una habilidad en ~/.codex/skills
pero no aparece en la lista después de /

Por lo general, esto no significa que la habilidad esté rota. Más a menudo significa: la sesión actual no la ha vuelto a indexar.

Cómo hacer que una habilidad esté disponible en la sesión actual

La lista de verificación práctica es breve.

1. Colóquelo en el directorio correcto

Mundiales:

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

Nivel de proyecto:

`1`	`project/.codex/skills/<skill-name>/SKILL.md`

2. Haga que el encabezado `SKILL.md` sea reconocible

Como mínimo, necesita:

---
name: your-skill-name
description: What this skill does
---

3. Abra una nueva sesión después de crearla o editarla

En muchos casos, una habilidad no aparece porque la sesión actual ya fijó su lista de habilidades disponibles cuando comenzó.

Entonces, si crea una habilidad en medio de una sesión, es posible que ya exista en el disco, pero es posible que esta sesión no la reconozca.

El flujo de trabajo más confiable es:

Ponga en práctica la habilidad
Finalizar la sesión actual
Vuelva a ingresar al proyecto.
Abre una nueva sesión
Compruebe si aparece debajo de /

4. Implemente las habilidades para el proyecto antes de comenzar

Si desea que project/.codex/skills se reconozca de manera más confiable, coloque esas habilidades en el proyecto antes de ingresar al repositorio e iniciar la sesión.

Una última línea

La conclusión más corta es:

~/.codex/skills es tu biblioteca de habilidades personales
project/.codex/skills es la biblioteca de reglas local del repositorio
una habilidad existente en el directorio no significa que la sesión actual siempre la mostrará
la solución más común es colocarlo en el directorio correcto, escribir un SKILL.md válido y luego iniciar una nueva sesión

Guía práctica de codex-quota: uso local, web y de Docker con comandos CLI originales

Thu, 16 Apr 2026 18:13:04 +0800

Qué hace este proyecto

codex-quota es una herramienta liviana para verificar el uso de la cuota de ChatGPT Codex, con datos obtenidos de https://chatgpt.com/backend-api/wham/usage.

Características principales:

Admite consultas de una sola cuenta y de varias cuentas (account/*.auth.json).
Genera five_hour%, weekly%, weekly_reset y marca la fuente (network o cache).
Utiliza reintentos de retroceso exponencial para fallas temporales (408, 429, 5xx).
Incluye almacenamiento en caché local para reducir las solicitudes repetidas cuando la cuota ya está agotada.
Proporciona un panel web, API JSON y páginas de administración de archivos de autenticación.

Ventajas:

Ligero: se ejecuta con scripts simples y dependencias mínimas.
Práctico: admite puntos de entrada CLI y Web.
Implementable: funciona con Docker y Docker Compose.
Fácil de operar: incluye reintento, caché y soporte de actualización programada.

Prepare las credenciales de la cuenta primero

Cree archivos de credenciales en account/<name>.auth.json, por ejemplo:

{
  "tokens": {
    "access_token": "eyJ...",
    "account_id": "user-xxxxxxxx"
  }
}

Explicación:

La API de uso requiere access_token y account_id.
<nombre> en el nombre del archivo se utiliza como nombre de cuenta en la salida.

Uso de CLI local (conservar los comandos originales)

Instalar dependencias:

`1`	`pip install -r requirements.txt`

Explicación: instala las dependencias del proyecto.

Consultar todas las cuentas:

`1`	`python codex_quota.py`

Explicación: lee account/*.auth.json y genera un resumen de cuota para todas las cuentas.

Consulta una cuenta:

`1`	`python codex_quota.py your_account_name`

Explicación: solo consulta cuenta/nombre_de_cuenta.auth.json.

Forzar actualización (omitir caché):

`1`	`python codex_quota.py --refresh`

Explicación: ignora el caché local y recupera datos nuevos directamente.

Opciones CLI (alineadas con README)

account_name: nombre de cuenta opcional (sin .auth.json).
--account-dir: directorio de autenticación, cuenta predeterminada.
--chatgpt-url: punto final de API de cuota.
--raw-json: imprime el cuerpo completo de la respuesta JSON.
--raw-headers: imprime encabezados de respuesta.
--refresh: ignora el caché.
--retries: recuento de reintentos, valor predeterminado 3.
--retry-delay: retraso de reintento base en segundos, valor predeterminado 2.0.

Uso del panel web (conservar el comando original)

Iniciar el servicio:

`1`	`python codex_quota_service.py --host 0.0.0.0 --port 8081`

Explicación: inicia el servicio HTTP escuchando en el puerto 8081.

URL de acceso: http://localhost:8081

Opciones de servicio:

--host: dirección de enlace, predeterminado 0.0.0.0.
--port: puerto de servicio, predeterminado 8081.
--interval-segundos: intervalo de actualización programado, predeterminado 3600.
--account-dir: directorio de autenticación, cuenta predeterminada.
--state-file: ruta del archivo de estado, predeterminado <account-dir>/codex_quota_web_results.json.
--account-name: modo de cuenta única opcional.
--chatgpt-url: punto final de API de cuota.
--retries: recuento de reintentos.
--retry-delay: retraso de reintento base.
--refresh: ignora el caché CLI durante las ejecuciones programadas.

Puntos finales HTTP (para automatización)

GET /: página del panel de control.
GET /api/results: últimos resultados en JSON.
GET /refresh: activa la actualización inmediata y redirige a /.
GET /auth: enumera los archivos de autenticación.
GET /auth/new: formulario para crear un archivo de autenticación.
GET /auth/edit?name=<cuenta>: formulario para editar el archivo de autenticación.
POST /auth/save: crea/actualiza el archivo de autenticación.
POST /auth/delete: elimina el archivo de autenticación.

Uso de Docker (conservar los comandos originales)

Construir imagen:

`1`	`docker build -t codex-quota .`

Explicación: construye el proyecto actual como imagen codex-quota.

Ejecutar contenedor (mapa 8081):

`1`	`docker run --rm -p 8081:8081 -v ./account:/app/account codex-quota`

Explicación:

--rm: elimina el contenedor automáticamente después de salir.
-p 8081:8081: asigna el puerto del host al puerto del contenedor.
-v ./account:/app/account: monta las credenciales locales en el contenedor.

URL de acceso: http://localhost:8081

Uso de Docker Compose (conservar el comando original)

Inicio:

`1`	`docker compose up --build`

Explicación: cree e inicie servicios basados en docker-compose.yml.

URL de acceso: http://localhost:8081

Consejos de uso

Para escenarios de múltiples cuentas, use primero el Panel de control para una vista unificada y administración de autenticación.
Para alertas o automatización, prefiera GET /api/results.
No envíe valores reales de access_token a repositorios públicos.
Si ve muchas fallas temporales, aumente --retries y --retry-delay.

Uso de las habilidades de los agentes de IA para mantener un blog multilingüe de Hugo

Mon, 06 Apr 2026 10:00:00 +0800

Si mantiene un blog multilingüe de Hugo, probablemente se encuentre con un problema frecuente:

Después de terminar el contenido en chino, aún necesitarás las versiones sincronizadas en inglés y chino tradicional.
Todos los archivos de idioma deben mantener la misma estructura.
La portada debe traducirse respetando las reglas del formato Hugo.

sync-post-translations está diseñado exactamente para este escenario.

¿Qué problema resuelve esta habilidad?

El posicionamiento de sync-post-translations es sencillo:

Utilice index.zh-cn.md como archivo fuente
Genere o actualice index.en.md e index.zh-tw.md en el mismo directorio
Mantenga coherente la estructura de Markdown
Aplique reglas explícitas al principio (especialmente “fecha” y “slug”)

Ejemplos de frases desencadenantes:

“Sincronizar traducción al inglés y chino tradicional”
“Traducir esta publicación al inglés y chino tradicional”

Estructura del directorio de habilidades

.\sync-post-translations\
├─ SKILL.md
└─ agents\
   └─ openai.yaml

Código central 1: SKILL.md

A continuación se muestra el archivo de reglas básicas de esta habilidad:

---
name: sync-post-translations
description: 将 Hugo 文章从简体中文源文件（`index.zh-cn.md`）同步翻译为英文（`index.en.md`）和繁体中文（`index.zh-tw.md`）。当用户提出“en 繁体”“同步翻译英文繁体”或要求同时生成/更新两种语言版本且需保持 front matter 与 Markdown 结构一致时使用。
---

# 同步文章翻译

使用此技能为同一篇文章生成或更新多语言版本。

## 工作流程

1. 在目标文章目录中定位源文件 `index.zh-cn.md`。
2. 读取完整 front matter 与正文内容。
3. 在同目录创建或更新 `index.en.md` 与 `index.zh-tw.md`。
4. 确保三语结构对齐后执行 Hugo 构建检查。

## 翻译规则

1. 严格保留 `slug` 原值。
2. `date` 统一规范为 Hugo 常用带时间格式（RFC3339），示例：`2026-04-05T10:00:00+08:00`。
3. 自然翻译以下 front matter 字段：`title`、`description`、`tags`、`categories`。
4. 保持 Markdown 结构不变：标题层级、列表形态、代码块、链接与命令行示例。
5. 技术标识符保持原样：文件名、CLI 参数、模型名、设备名、URL、包名等。
6. 若 YAML 的 `title` 含有 `:`，必须加引号，避免解析报错。
7. 在不改变语义前提下，使用目标语言自然标点与表达习惯（`en`、`zh-tw`）。

## 输出约定

1. 仅在源文章同目录写入目标文件。
2. 汇报变更的文件路径。
3. 条件允许时执行 `hugo --source . --destination public`，并反馈通过/失败；失败时给出关键报错行。

## 质量标准

1. 全文术语前后一致。
2. 避免机器直译感，优先可发布文风。
3. 章节内容完整，不省略示例、注意点与总结。

Código central 2: agentes/openai.yaml

Este archivo define cómo se presenta y solicita la habilidad en el lado del agente:

interface:
  display_name: "同步文章翻译"
  short_description: "生成或更新 EN + ZH-TW 翻译稿"
  default_prompt: "使用该技能在同一 Hugo 文章目录中，从 `index.zh-cn.md` 生成或同步 `index.en.md` 与 `index.zh-tw.md`，保留 `date` 与 `slug`，保持 Markdown 结构一致，并执行 Hugo 构建校验。"

Ejemplo de uso práctico

1) Activador del lenguaje natural

1
2

请把 content/post/2026/04/06/index.zh-cn.md 同步翻译成英文和繁体，
要求 date 用 RFC3339，slug 不变，最后跑 hugo 校验。

2) Resultado esperado

已更新：
- content/post/2026/04/06/index.en.md
- content/post/2026/04/06/index.zh-tw.md

构建校验：
- hugo --source . --destination public
- 结果：PASS

Por qué son importantes estas reglas

Mantener “slug” sin cambios conserva las URL estables y los vínculos de retroceso históricos.
Normalizar la “fecha” a RFC3339 con zona horaria evita la ambigüedad en el análisis de Hugo/tema.
Mantener la estructura de Markdown sin cambios evita problemas de representación de TOC, bloques de código y códigos cortos.
No traducir identificadores técnicos reduce significativamente las discrepancias entre archivos y comandos rotos.

Errores comunes y cómo evitarlos

Si title contiene : sin comillas, el análisis de YAML puede fallar.
Traducir --flags, URL o nombres de paquetes interrumpirá los ejemplos de comandos.
Si los niveles de encabezado difieren entre idiomas (por ejemplo, ## se convierte en ###), los anclajes pueden volverse inconsistentes.
Traducir solo el contenido del cuerpo, pero no el texto inicial, puede romper las páginas de la lista y los metadatos de SEO.

Cómo utilizar Codex en VS Code (desde la configuración hasta un flujo de trabajo eficiente en el mundo real)

Fri, 20 Mar 2026 00:00:00 +0000

Codex puede ayudarlo a escribir código, corregir errores, comprender proyectos y ejecutar comandos directamente desde la barra lateral de VS Code.

1. Preparación

Antes de comenzar, asegúrese de:

VS Code se actualiza a una versión estable reciente.
Puedes acceder a los servicios de OpenAI con normalidad.
Su proyecto se abre localmente (preferiblemente en un repositorio Git).

2. Instale la extensión

Abra el panel Extensiones de VS Code.
Busque e instale: Codex - Codex - Agente de codificación de OpenAI.
Complete el flujo de inicio de sesión/autorización.

3. Abra la barra lateral del Códice

Puedes abrirlo de cualquier forma:

Haga clic en “Abrir barra lateral del Codex” en el área superior derecha del editor.
Utilice la paleta de comandos (Ctrl + Shift + P), busque Codex y ábralo.

Después de abrir, Codex lee el contexto del espacio de trabajo actual y está listo para conversar.

4. Patrones de uso comunes

4.1 Pídale que explique el código

Mensaje de ejemplo:

1
2

Please explain the core logic of this file,
and point out the 3 areas most likely to fail.

Excelente para comprender rápidamente el código heredado.

4.2 Pídale que implemente funciones

Mensaje de ejemplo:

1
2
3

Add a /healthz endpoint to the existing API.
It should return app version and database connectivity status,
and include basic tests.

Si establece claramente las restricciones y los criterios de aceptación, la calidad del resultado suele ser mucho más estable.

4.3 Pídale que solucione problemas

Mensaje de ejemplo:

1
2
3

This endpoint intermittently returns 500 under concurrency.
First identify the root cause, then propose a minimal-change fix,
and finally list regression test points.

“Diagnosticar primero, luego corregir” ayuda a reducir la refactorización excesiva accidental.

5. Plantilla de aviso de alta calidad

Puedes reutilizar esta plantilla directamente:

Background: This is a <tech stack> project. Current goal: <goal>
Constraints: Do not modify <module/interface>; keep compatibility with <version/platform>
Output:
1) File list to change
2) Key code explanation
3) Validation steps
4) Risks and rollback plan

Esto es especialmente útil para proyectos grandes y colaboración en equipo.

6. Preguntas frecuentes

6.1 Acerca de la cuota gratuita

Escriba \ en el cuadro de entrada, luego elija el estado para ver información relacionada con la cuota/tiempo de reinicio.

6.2 Los cambios no son los esperados

Una vez generados los cambios, abra el panel de revisión para inspeccionar los detalles. Si no está satisfecho, utilice deshacer/revertir. Puede dividir requisitos grandes en pasos más pequeños y ejecutarlos de forma incremental. Utilice Git y mantenga pequeñas confirmaciones para una reversión más sencilla.