Codex on KnightLi Blog

Scientific Agent Skills: una biblioteca de skills para dar flujos de investigación a AI Agents

Sun, 17 May 2026 17:52:04 +0800

K-Dense-AI/scientific-agent-skills es una colección de Agent Skills para trabajo científico y de investigación.

Su objetivo no es crear otro chatbot. Convierte tareas frecuentes de investigación, como consultar documentación, conectar bases de datos, escribir scripts de análisis, procesar archivos, generar gráficos y preparar informes, en skills que un AI Agent puede descubrir y llamar.

Proyecto: https://github.com/K-Dense-AI/scientific-agent-skills

A fecha de 2026-05-17, la API de GitHub mostraba unos 23.4k stars, 2.5k forks, licencia MIT y último push el 2026-05-11. El README habla de 135 ready-to-use scientific and research skills, pero el directorio scientific-skills muestra 137 entradas vía API de GitHub. La diferencia puede venir del criterio de conteo, entradas recientes o retraso en actualizar el README.

Conclusión rápida

Scientific Agent Skills encaja con quienes ya usan Codex, Claude Code, Cursor, Gemini CLI u otra herramienta compatible con el estándar Agent Skills.

Su valor principal está en tres puntos:

Escribe el uso de herramientas científicas en SKILL.md, para que el agent no tenga que adivinar cada vez cómo se usa una librería.
Organiza bases de datos científicas, paquetes Python, procesamiento de documentos, escritura científica y visualización en una misma colección.
Hace que un AI Agent se parezca más a un asistente capaz de ejecutar flujos de investigación, no solo a un bot que responde conceptos.

Pero no es un botón mágico que “hace ciencia” al instalarlo. Las skills pueden ayudar al agent a elegir herramientas correctas y generar código y flujos más fiables, pero la calidad de datos, el diseño experimental, las hipótesis estadísticas, las decisiones clínicas y las conclusiones de investigación siguen requiriendo juicio humano.

Qué incluye

El README describe el proyecto como una colección de skills para investigación, computación científica, ingeniería, análisis, finanzas y escritura. Las áreas principales incluyen:

Bioinformática y genómica.
Quimioinformática y descubrimiento de fármacos.
Proteómica y espectrometría de masas.
Investigación clínica y medicina de precisión.
Healthcare AI y machine learning clínico.
Imagen médica y patología digital.
Machine learning y AI.
Ciencia de materiales y química.
Física y astronomía.
Simulación y optimización de ingeniería.
Análisis y visualización de datos.
Ciencia geoespacial y teledetección.
Automatización de laboratorio.
Escritura científica, revisión bibliográfica, peer review y gestión de citas.

Estas skills no buscan limitar al agent a ciertas librerías. El README también deja claro que el agent puede escribir Python y llamar cualquier API o paquete disponible. Las skills aportan documentación curada, ejemplos, buenas prácticas y rutas de integración.

En otras palabras, son una mezcla de manuales de herramientas científicas, plantillas de workflow y convenciones de llamada para agents.

Bases de datos y paquetes Python

La parte más atractiva para usuarios científicos es la cobertura de bases de datos y del ecosistema Python.

El README menciona:

Acceso unificado a 78 bases públicas mediante database-lookup.
Cobertura de PubChem, ChEMBL, UniProt, COSMIC, ClinicalTrials.gov, FRED, USPTO y más.
Skills dedicadas para DepMap, Imaging Data Commons, PrimeKG, U.S. Treasury Fiscal Data, Hugging Science y otras fuentes.
Más de 70 Python Package Skills optimizadas.

En el directorio aparecen muchos nombres conocidos:

rdkit
scanpy
biopython
bioservices
pydeseq2
scvelo
scvi-tools
pymatgen
qiskit
pennylane
openmm
mdanalysis
scikit-learn
statsmodels
matplotlib
seaborn
networkx
sympy
pytorch-lightning
transformers
timesfm-forecasting

Para un desarrollador, esas librerías no sorprenden por sí mismas. Lo útil es que el agent puede leer restricciones, ejemplos de código, flujos comunes y advertencias específicas mientras trabaja. Eso es más estable que depender solo de memoria antigua del modelo.

Escenarios típicos

Scientific Agent Skills sirve mejor para tareas de investigación con varios pasos que para preguntas de una sola vuelta.

En descubrimiento de fármacos, un agent podría consultar ChEMBL para inhibidores de EGFR, analizar relaciones estructura-actividad con RDKit, hacer screening virtual con DiffDock, buscar literatura y generar un informe.

En análisis single-cell, podría cargar datos 10X en Scanpy, hacer QC, integrar datasets, identificar tipos celulares, ejecutar expresión diferencial y enriquecimiento de vías.

En multi-omics, podría conectar RNA-seq, espectrometría de masas, metabolitos, interacciones de proteínas, ensayos clínicos y modelado estadístico.

Sin skills, estas tareas se convierten fácilmente en “el agent entiende la dirección general, pero hay que recordarle cada paso”. La biblioteca de skills guarda rutas frecuentes para reducir desvíos.

Instalación

El README recomienda la herramienta estándar de Agent Skills:

`1`	`npx skills add K-Dense-AI/scientific-agent-skills`

Si usas GitHub CLI v2.90.0+, también puedes instalar con gh skill:

`1`	`gh skill install K-Dense-AI/scientific-agent-skills`

Instalar una skill concreta:

`1`	`gh skill install K-Dense-AI/scientific-agent-skills scanpy`

Indicar un agent destino:

gh skill install K-Dense-AI/scientific-agent-skills --agent codex
gh skill install K-Dense-AI/scientific-agent-skills --agent cursor
gh skill install K-Dense-AI/scientific-agent-skills --agent claude-code
gh skill install K-Dense-AI/scientific-agent-skills --agent gemini

Para reproducibilidad, puedes fijar release tag o commit SHA:

1
2

gh skill install K-Dense-AI/scientific-agent-skills --pin v1.0.0
gh skill install K-Dense-AI/scientific-agent-skills --pin abc123def

Esto importa en investigación. Lo peor es “la semana pasada corría, esta semana cambió el resultado y nadie sabe por qué”. Si una skill participa en un análisis, registra skill, dependencias y versión de datos.

Requisitos de ejecución

El README lista:

Python 3.11+, recomendado 3.12+.
uv para instalar dependencias Python.
Un cliente compatible con Agent Skills.
macOS, Linux o Windows with WSL2.

Los usuarios de Windows deben fijarse en WSL2. Muchas librerías científicas pueden correr en Windows nativo, pero cadenas de dependencias, compiladores, paquetes binarios y rutas dan más problemas. La mención “Windows with WSL2” sugiere un entorno tipo Unix para computación científica.

Diferencia frente a una colección de prompts

Una colección de prompts suele decir al modelo cómo responder. Scientific Agent Skills va más allá: describe herramientas, librerías, bases de datos y workflows como skills descubribles.

Diferencias prácticas:

Una skill puede incluir instrucciones estructuradas y ejemplos de código.
Puede mantenerse alrededor de una librería o base de datos concreta.
El agent puede elegir skills según la tarea, en vez de cargar todas las reglas en el system prompt.
Un equipo puede instalar solo lo que necesita y reducir ruido de contexto.
Las skills pueden versionarse, revisarse y actualizarse con el repositorio.

Para investigación compleja, esto se mantiene mejor que copiar un prompt universal enorme. Modelos, bases de datos y paquetes Python cambian. Capturar esos cambios en skills es más controlable que dejarlos en documentos personales de prompts.

Seguridad y límites de confianza

La advertencia de seguridad del README es directa: las Skills pueden ejecutar código e influir en el comportamiento del coding agent.

Eso importa. Una skill científica puede instalar dependencias Python, acceder a bases de datos en red, leer y escribir archivos locales, ejecutar scripts de análisis, procesar datos experimentales o clínicos sensibles y generar informes que luego se citen.

No conviene instalar todo a ciegas. Una ruta más segura:

Instala solo las skills necesarias para la tarea.
Lee el SKILL.md correspondiente antes.
Revisa paquetes, API, archivos y servicios externos que puede llamar.
Ten más cuidado con skills aportadas por la comunidad.
Ejecuta tareas con datos y código en un entorno aislado.
Mantén revisión humana para conclusiones, sugerencias clínicas y resultados estadísticos.

El README también menciona Cisco AI Defense Skill Scanner y sugiere escanear skills de terceros localmente. El escaneo no sustituye la revisión humana, pero muestra conciencia del riesgo de supply chain de skills.

Para quién es

Este proyecto es más útil para quienes:

Ya usan AI coding agents a diario.
Procesan a menudo datos científicos, papers, gráficos e informes.
Cambian frecuentemente entre herramientas del ecosistema Python científico.
Quieren que un agent ejecute análisis de varios pasos, no solo explique conceptos.
Quieren convertir flujos de investigación del equipo en skills reutilizables.
Quieren estudiar cómo aplicar Agent Skills a dominios profesionales.

No encaja tanto si solo quieres que AI explique un paper de vez en cuando, no tienes entorno Python local, no quieres gestionar dependencias, no has definido límites de privacidad, red y ejecución de código, o necesitas un sistema clínico/productivo regulado sin revisión humana.

Para análisis ocasionales, pedir al agent que escriba un script puede ser más ligero. Si repites flujos parecidos, la biblioteca gana valor.

Consejos de uso

No empieces instalando todo el repositorio y entregando todas las tareas al agent.

Una ruta más práctica:

Elige una tarea de bajo riesgo, como organizar literatura, generar gráficos o explorar datos públicos.
Instala solo skills relevantes, como literature-review, scientific-writing, scanpy o rdkit.
Pide al agent que explique el plan antes de ejecutar código.
Conserva datos de entrada, scripts, entorno y versiones de skills.
Revisa manualmente los resultados.
Si el flujo se estabiliza, conviértelo en SOP o skill propia del equipo.

La clave de un agent científico no es automatizarlo todo. Es dar a las herramientas las partes repetitivas, tediosas y dependientes de documentación, y dejar juicio, hipótesis y conclusiones a las personas.

Resumen

Scientific Agent Skills importa porque lleva Agent Skills desde programación general hacia investigación.

El trabajo científico es naturalmente multi-herramienta, multi-base de datos, multi-archivo y multi-paso. Los prompts de chat por sí solos rara vez cubren esos detalles con estabilidad. Este proyecto convierte librerías, fuentes de datos y flujos de investigación comunes en skills, facilitando que un AI Agent entre en workflows reales.

Pero cuanto más potente es, más límites necesita. Las skills pueden cambiar el comportamiento del agent, ejecutar código, acceder a red y procesar archivos. Lee antes de instalar, aísla la ejecución y no saltes la validación humana de conclusiones científicas.

Si ya usas Codex, Claude Code, Cursor o Gemini CLI para investigación y análisis de datos, Scientific Agent Skills merece una mirada seria. Aunque no lo instales completo, su forma de dividir skills sirve como referencia para organizar workflows de AI científica en equipo.

Referencias:

Codex ya admite acceso remoto desde ChatGPT móvil y Access Tokens para espacios Enterprise

Sun, 17 May 2026 09:12:07 +0800

El 14 de mayo de 2026, OpenAI actualizó las notas de lanzamiento de ChatGPT Enterprise & Edu con dos cambios centrados en Codex: acceso remoto desde la app móvil de ChatGPT y Codex access tokens para automatización controlada en espacios Enterprise.

No es un lanzamiento de nuevas capacidades de modelo. Es un cambio en la forma del producto Codex. Codex está pasando de ser un asistente de programación local o web a un coding agent que puede ejecutarse durante más tiempo, gestionarse a distancia e integrarse en flujos de automatización empresarial.

Qué cambió

Según OpenAI Help Center, Codex ahora admite acceso remoto desde ChatGPT mobile app. Los usuarios pueden conectarse desde el teléfono a un entorno Codex en ejecución, seguir tareas largas e intervenir cuando sea necesario.

Al mismo tiempo, los espacios ChatGPT Enterprise reciben Codex access tokens. Están pensados para flujos locales confiables y no interactivos, permitiendo que la automatización use ChatGPT workspace identity y controles empresariales sin iniciar sesión en el navegador cada vez.

La actualización tiene dos entradas principales:

Acceso remoto móvil: resuelve qué hacer cuando Codex ejecuta una tarea larga y el usuario no está frente al ordenador.
Access Tokens: resuelve cómo los scripts empresariales de automatización pueden llamar flujos de Codex con una identidad controlada.

Qué problema resuelve el acceso remoto móvil

Las tareas típicas de Codex no siempre terminan en segundos. En desarrollo real, puede leer un repositorio, modificar varios archivos, ejecutar pruebas, esperar salida de comandos, corregir errores y pedir aprobación a mitad del proceso.

Antes, estas tareas solían exigir que el usuario estuviera cerca del Mac local, la app de escritorio, la CLI o el IDE. Ahora, ChatGPT móvil puede funcionar como una consola remota para seguir Codex incluso lejos del ordenador.

OpenAI indica que el móvil puede mostrar el estado en tiempo real del entorno subyacente, incluyendo:

Contexto del proyecto.
approvals.
screenshots.
terminal output.
diffs.
test results.

El usuario también puede responder preguntas de Codex, redirigir la ejecución, aprobar acciones, revisar salidas y cambiar entre distintos connected hosts. La tarea sigue ejecutándose en un Mac host o en un entorno remoto conectado; el teléfono sirve para revisar y controlar.

Valor para desarrolladores

Esta capacidad es especialmente útil para tareas largas que requieren confirmaciones ocasionales.

Por ejemplo:

Codex está ejecutando pruebas lentas y quieres revisar el resultado fuera de casa.
Codex modificó varios archivos y quieres revisar el diff en el móvil antes de aprobar el siguiente paso.
Codex espera confirmación antes de una operación riesgosa.
Hay varios connected hosts y quieres cambiar entre ellos desde el móvil.

El valor no es escribir código en el teléfono. El valor es no tener que permanecer frente al ordenador todo el tiempo. Codex sigue trabajando en el entorno original y el usuario interviene solo en momentos clave.

Esto también muestra que Codex se acerca a un modelo de “Agent en segundo plano”: las tareas pueden seguir ejecutándose, el usuario no necesita estar siempre conectado, pero la aprobación y el control siguen en manos humanas.

Qué resuelven los Access Tokens

Codex access tokens están dirigidos a espacios ChatGPT Enterprise. Su objetivo no es el inicio de sesión normal de usuarios personales, sino la automatización empresarial confiable.

En una empresa, a menudo hay flujos locales o internos que deben ejecutarse de forma no interactiva, por ejemplo:

Revisiones de código programadas.
Activación de flujos Codex en máquinas controladas.
Integración de Codex con herramientas internas de desarrollo.
Uso de identidad de workspace sin abrir el navegador.

Access tokens permiten que estos flujos se ejecuten con ChatGPT workspace identity y sigan sujetos a políticas empresariales. Frente al login manual, encajan mejor con automatización. Frente a compartir credenciales personales, son más fáciles de gobernar.

No es una API key genérica

Este punto es importante. Codex access tokens no deberían entenderse como una simple “API key universal”.

OpenAI señala que access tokens están disponibles para espacios ChatGPT Enterprise, los administradores pueden gestionar su disponibilidad a nivel de workspace, y los miembros con roles permitidos pueden crear sus propios tokens. Cuando esté disponible, la interfaz de gobernanza también puede reflejar actividad de access tokens.

Es decir, access tokens se integran en el marco de permisos, roles y auditoría empresarial:

El administrador decide si el workspace los habilita.
No todos los miembros pueden crearlos por defecto.
La actividad del token puede aparecer en vistas de gobernanza.
Heredan ChatGPT workspace identity y controles empresariales.

Esto no es lo mismo que crear casualmente un secreto personal de larga duración.

Valor seguro por defecto: Remote Control está apagado

Codex mobile remote access toca entornos de código, salida de terminal, diffs, resultados de pruebas y acciones de aprobación. Si estuviera habilitado por defecto, implicaría riesgos empresariales evidentes.

Por eso OpenAI adopta una postura conservadora: remote control está apagado por defecto y un admin u owner debe habilitarlo en Workspace settings.

Al activar el acceso remoto móvil, también pueden intervenir:

workspace-enabled Remote Control access.
SSO.
Autenticación multifactor.
passkey.

Esto muestra que es una capacidad que debe configurar el equipo de IT y seguridad, no algo disponible automáticamente para todos tras actualizar la app.

Qué hay que actualizar antes de usarlo

OpenAI indica que el acceso remoto móvil requiere actualizar ambos lados:

ChatGPT mobile app.
Codex app en macOS.

Si el workspace lo exige, la configuración móvil también puede activar SSO, autenticación multifactor o passkey.

En la práctica, los administradores deberían revisar primero la configuración de remote control en Workspace settings y decidir qué miembros o roles pueden usar estas capacidades.

Impacto en el uso empresarial de Codex

Esta actualización empuja Codex en dos direcciones.

Primero, Codex se vuelve más apto para tareas largas. Antes, el problema era que el usuario debía vigilarlo constantemente. Ahora puede revisar estado y aprobar acciones desde el móvil, lo que hace más natural que Codex trabaje en segundo plano.

Segundo, Codex se vuelve más apto para automatización empresarial. Access tokens dan a los flujos no interactivos una identidad formal, facilitando integraciones futuras con CI interno, revisión de código, scripts y plataformas de desarrollo.

Juntas, estas dos direcciones significan que Codex deja de ser solo un asistente de IA junto al desarrollador y se convierte en un agent administrable dentro del flujo de desarrollo empresarial.

Límites que siguen importando

La actualización es útil, pero no significa que Codex pueda ejecutarse sin supervisión.

Las empresas todavía deben considerar:

Qué proyectos permiten control remoto.
Qué comandos requieren aprobación.
Cómo crear, rotar y revocar tokens.
Si mobile remote access encaja con la política de gestión de dispositivos.
Si terminal output, screenshots y diffs pueden contener información sensible.
Si los logs de auditoría y vistas de gobernanza cumplen los requisitos internos.

Especialmente los access tokens: una vez que entran en flujos de automatización, deben gestionarse como otras credenciales empresariales, con mínimo privilegio, rotación, sin hardcoding y revocación rápida de tokens que ya no se usen.

Resumen

La actualización de Codex es clara: ChatGPT móvil puede acceder remotamente a tareas largas de Codex, y los espacios Enterprise pueden usar Codex access tokens para automatización controlada.

Lo primero evita que el desarrollador tenga que estar siempre frente al ordenador. Lo segundo permite a las empresas integrar Codex de forma más formal en flujos internos. Juntas, ambas funciones muestran que Codex avanza desde un asistente interactivo de programación hacia un coding agent empresarial, gestionable, auditable y preparado para automatización.

Referencia:

OpenAI Help Center: ChatGPT Enterprise & Edu - Release Notes

Por qué se reinician de repente los límites de Codex: historial y fuentes

Sun, 17 May 2026 08:36:15 +0800

Los usuarios de Codex a veces se encuentran con algo extraño: sus usage limits vuelven a estar disponibles aunque todavía no haya llegado su hora normal de reset. Este tipo de reinicio sin aviso no es nuevo, y no significa necesariamente que las reglas de cuota se hayan vuelto más generosas de forma permanente. Puede deberse a compensación por incidentes, promociones de producto, hitos de crecimiento o a un reset interno que solo afecta a ciertas ventanas o estados de cuenta.

La captura proviene de una publicación en X de Tibo Sottiaux (@thsottiaux), responsable del equipo de OpenAI Codex. Para quienes siguen de cerca sus límites, la parte clave no es el detalle del modelo, sino que Tibo dijo que resetearía los usage limits esa misma noche. Por el contexto, se trató de un reset compensatorio, no de una renovación normal del ciclo.

Resumen rápido

Los reinicios repentinos de límites en Codex suelen entrar en estas categorías:

Compensación por incidente: un problema en Codex o en un modelo hace que los usuarios gasten cuota de forma anormal, y OpenAI reinicia límites para compensar.
Lanzamiento o promoción: un nuevo modelo, cliente o función se acompaña de más capacidad temporal o de un reset.
Hito de crecimiento: OpenAI reinicia o aumenta límites cuando Codex alcanza cierto nivel de adopción.
Cambio de política interna: solo se resetean algunas ventanas de cuota o ciertos estados de cuenta, y la UI no siempre explica el alcance.

El malentendido más común es creer que “reset” significa que todas las ventanas visibles se han recuperado. En la práctica, Codex puede tener ventanas cortas, weekly limit, pesos de consumo por modelo y reglas por plan. Un reset especial puede afectar solo a una parte del sistema.

Qué muestra esta captura

La captura muestra que Tibo publicó una actualización el 15 de mayo de 2026, diciendo que el equipo seguiría monitoreando y que reiniciaría los usage limits esa noche. La publicación cita un mensaje anterior en el que el equipo decía estar investigando reportes de algunos usuarios.

Para el usuario, hay tres ideas prácticas:

No fue el ciclo normal de reset de cada cuenta; fue un reset activo del equipo.
El reset tuvo un contexto concreto y no fue un aumento permanente de límites.
La expresión “usage limits” no aclara por sí sola si incluía tanto la ventana de 5 horas como el weekly limit.

Por eso, si tu cuota se recuperó, conviene tratarlo primero como un reset event especial, no como prueba de que las reglas futuras cambiaron.

Por qué los resets de Codex pueden parecer inesperados

Los límites de Codex no funcionan simplemente como “se actualizan todos los días a una hora fija”. El backend puede rastrear varias cosas a la vez:

Ventanas cortas de uso, por ejemplo de unas horas.
Límites semanales o de periodos más largos.
Pesos de consumo distintos para diferentes modelos.
Entradas distintas, como Codex local, Cloud Tasks, IDE y CLI.
Diferencias entre Plus, Pro, Business y Team.
Si una cuenta es elegible para un reset especial.

Cuando OpenAI aplica un reset especial, la UI puede no decir con claridad si se trata de una renovación normal o de una compensación. Si solo se reinicia la ventana corta, algunos usuarios pueden asumir que el weekly limit también debería recuperarse. Si el weekly no cambia, parece que el reset falló.

En el repositorio de OpenAI Codex en GitHub también se planteó este problema de transparencia: el mensaje público decía que se habían reseteado los Codex rate limits, pero la UI no mostraba claramente qué ventanas se habían reiniciado, si el weekly limit estaba incluido o si todos los planes de pago se veían afectados de la misma forma.

Patrones históricos

1. Febrero de 2026: periodo de lanzamiento y capacidad temporal

Durante el periodo de promoción de la app de escritorio de Codex y GPT-5.3-Codex, usuarios de la comunidad hablaron de usage limit reset y de 2x rate limits temporales. En Reddit, algunos mencionaron que el lanzamiento de Codex app incluyó 2x rate limits por tiempo limitado y un usage limit reset.

Este tipo de reset parece una acción de lanzamiento: animar a más usuarios a probar el nuevo cliente, modelo o flujo de trabajo.

2. Marzo de 2026: resets aleatorios y consumo anormal

Alrededor de marzo, la comunidad discutió varias veces comportamientos como “random usage reset” y “weekly limit reset daily”. Algunos usuarios dijeron que su weekly limit se recuperó antes de tiempo, mientras que otros lo relacionaron con nuevos modelos de Codex, bloqueos de seguridad, consumo anormal de cuota o correcciones de bugs.

Estas discusiones no son anuncios oficiales, pero muestran que los usuarios ya habían observado recuperaciones fuera del calendario normal.

3. Abril de 2026: hitos de crecimiento y resets para planes de pago

A finales de abril, algunos reportes públicos indicaron que Codex alcanzó 3 millones de usuarios activos semanales y que OpenAI reseteó rate limits, con la intención de dar más margen en futuros hitos de crecimiento.

Un issue de GitHub también citó una publicación de Tibo del 28 de abril, donde decía que había reseteado los Codex rate limits para planes de pago tras una “good week”, para que los usuarios pudieran crear más con GPT-5.5. Ese mismo issue señalaba que la UI no explicaba con claridad qué ventanas se habían reseteado ni si el weekly limit estaba incluido.

Esto muestra por qué los resets vinculados a actividad o crecimiento también pueden confundir: los usuarios oyen un mensaje amplio, pero ven resultados distintos en su cuenta.

4. Mayo de 2026: reset compensatorio

La captura de este artículo es un ejemplo más claro de reset compensatorio. Tibo dijo que el equipo había encontrado problemas y que resetearía los usage limits esa noche. OpenAI Status también registró errores elevados y latencia degradada relacionados con Codex el 13 de mayo de 2026.

Para usuarios normales, lo importante no es el detalle exacto del modelo. La lección es que, cuando un problema del servicio hace que los usuarios quemen cuota de forma anormal, OpenAI puede compensar con un reset especial.

Cómo interpretar un reset repentino

Si tu cuota de Codex se recupera de repente, revisa en este orden:

Comprueba si llegó tu hora normal de reset.
Revisa OpenAI Status para ver incidentes de Codex, errores de modelo, latencia o rendimiento degradado.
Busca actualizaciones de Tibo, cuentas oficiales de OpenAI o issues de Codex en GitHub.
Mira si la comunidad reporta el mismo reset, consumo anormal o confusión con el weekly limit.
Separa las ventanas cortas del weekly limit; no asumas que siempre se mueven juntas.

Si es compensación oficial por un incidente, normalmente habrá una entrada en la página de estado, un anuncio del equipo o muchos reportes concentrados. Si solo es una actualización parcial del backend, puede que no haya anuncio claro.

Cómo evaluar la fiabilidad de las fuentes

Conviene separar las fuentes por nivel de fiabilidad:

OpenAI Status: mejor para confirmar incidentes, tasas de error, latencia y tiempos de recuperación.
Tibo / cuentas oficiales de OpenAI: útiles para confirmar resets especiales, compensaciones o promociones.
OpenAI Codex GitHub issues: útiles para ver reportes de usuarios sobre UI, ventanas de cuota y comportamiento real del producto.
Reddit / X: útiles para detectar patrones amplios entre usuarios, pero no son confirmación oficial.
Noticias o blogs de terceros: útiles para completar la línea temporal, pero conviene contrastarlos con fuentes originales.

Al escribir o tomar decisiones, conviene mantener separadas estas capas. “OpenAI Status registró un incidente” es una señal oficial. “Usuarios de Reddit reportaron resets aleatorios” es una observación de la comunidad. “Un GitHub issue señaló falta de transparencia en la UI” es un problema reportado por un usuario.

Resumen

Un reset repentino de usage limits en Codex no suele ser simplemente “cuota gratis”. Puede venir de compensación por incidentes, promociones de lanzamiento, actividades de crecimiento o cambios internos. Lo confuso es que Codex tiene varias ventanas de cuota, y un reset especial no siempre las incluye todas. La UI tampoco siempre muestra claramente el reset scope.

Cuando ocurra, revisa primero la cuota real en el cliente, luego compárala con OpenAI Status, publicaciones de Tibo, GitHub issues de Codex y reportes de la comunidad. No asumas que un reset cambia las reglas a largo plazo, ni que weekly limit, ventanas cortas y todos los planes se recuperan al mismo tiempo.

Referencias:

Acceso remoto móvil de Codex: sigue tareas de programación en Mac desde la app ChatGPT

Sat, 16 May 2026 17:42:40 +0800

OpenAI llevó Codex remote access a la app móvil de ChatGPT a mediados de mayo de 2026. La idea no es programar en el teléfono, sino seguir y dirigir Codex mientras trabaja en un Mac.

Codex sigue leyendo el proyecto, ejecutando comandos, editando archivos y revisando pruebas en el ordenador. El móvil sirve para revisar progreso, responder preguntas, añadir instrucciones y aprobar acciones.

Qué puede hacer

Según la documentación de OpenAI, desde el móvil puedes:

iniciar nuevos threads en proyectos del host o continuar existentes;
enviar instrucciones, responder preguntas y ajustar la dirección del trabajo;
aprobar comandos y otras acciones;
revisar salidas, diffs, resultados de pruebas, terminal y capturas;
recibir notificaciones cuando Codex termina o necesita atención;
cambiar entre hosts y threads conectados.

No es solo una ventana de chat pequeña: conecta con el contexto real de trabajo de Codex en el host.

Requisitos

Necesitas acceso a Codex en la misma cuenta y workspace de ChatGPT en el móvil y en el Mac. También necesitas la última app móvil de ChatGPT en iOS o Android.

El host actualmente debe ser un Mac despierto, en línea, ejecutando Codex App y con la misma cuenta y workspace. La configuración móvil y el control del dispositivo requieren por ahora Codex App for macOS; no se configuran desde Codex CLI ni desde la IDE Extension.

Si tu cuenta usa MFA, SSO o passkey, debes completar ese flujo. En un workspace de ChatGPT, un administrador puede tener que habilitar Remote Control access.

Límites

Primero, requiere un macOS host. El teléfono se conecta a Codex App en un Mac, no directamente a Codex CLI, a la IDE Extension ni a cualquier equipo Linux / Windows.

Segundo, el host debe estar en línea. El Mac debe permanecer despierto, conectado y con Codex App abierto. Si duerme, pierde red o cierra Codex, la sesión remota puede desconectarse.

Tercero, la conexión usa QR. Debes abrir Set up Codex mobile en el Mac, escanear el código y completar la vinculación en ChatGPT.

Cuarto, las acciones remotas siguen pasando por aprobaciones. Antes de aprobar desde el móvil, conviene leer qué quiere hacer Codex, sobre todo si implica terminal, cambios de archivos, pruebas o acceso externo.

Cómo conectarlo

Abre Codex en el Mac.
Elige Set up Codex mobile en la barra lateral.
Codex activa el acceso remoto para ese host y muestra un QR.
Escanea el QR con el teléfono para abrir el flujo en ChatGPT.
Confirma la misma cuenta y workspace.
Completa MFA, SSO o passkey si hace falta.
El Mac aparecerá en Codex dentro del móvil.

Después puedes gestionar dispositivos en Settings > Connections desde Codex en el Mac, y revisar opciones como mantener el equipo despierto, Computer Use o Chrome extension.

Para qué sirve el móvil

El móvil sirve sobre todo para aprobar, corregir dirección y revisar resultados. Puedes aprobar comandos, añadir una instrucción cuando Codex se equivoca o falla una prueba, y mirar diffs, logs de terminal, pruebas y capturas sin volver al escritorio.

El valor no es escribir código en el móvil, sino convertirlo en una consola ligera para tareas de ingeniería que siguen ejecutándose en el host.

Problemas comunes

Si el host no aparece, confirma que Codex App sigue abierto en el Mac, que Allow other devices to connect está activado y que ambos dispositivos usan la misma cuenta y workspace.

Si no aparece una solicitud de aprobación, abre Codex dentro de la app móvil de ChatGPT, vuelve a escanear el QR o reinicia la configuración desde el host. En equipos, revisa si el administrador habilitó Remote Control access.

Si la sesión se desconecta, revisa si el Mac se durmió, perdió red o cerró Codex App. Si la autenticación bloquea la configuración, completa MFA, SSO o passkey primero.

Cuándo conviene

Encaja bien si ejecutas tareas largas con Codex, necesitas aprobar comandos lejos del escritorio, gestionas varios proyectos o threads y usas Mac como máquina principal.

Encaja peor si trabajas principalmente en Windows o Linux, solo usas Codex CLI o IDE Extension, esperas un entorno de desarrollo completo en el teléfono o tienes una red inestable.

Mi lectura

El acceso remoto móvil de Codex no mueve el desarrollo al teléfono. Hace más manejables los momentos en los que Codex se detiene por aprobación, preguntas, fallos de pruebas o cambios de dirección.

Si ya usas Codex intensivamente en Mac, merece la pena activarlo. Si solo haces preguntas de código ocasionales, su valor será menos evidente.

Referencias

Superpowers: un framework de skills que devuelve los coding agents al proceso de ingeniería

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers es un framework de skills para coding agents y también una metodología de desarrollo de software. Su objetivo no es crear otro prompt universal, sino hacer que el agente siga un proceso: aclarar objetivos, producir diseño, escribir un plan, implementar con TDD, revisar y cerrar.

Proyecto: https://github.com/obra/superpowers

En el momento de escribir, la API de GitHub muestra más de 190.000 stars, licencia MIT y actividad reciente. El README lo describe como An agentic skills framework & software development methodology that works.

Qué problema resuelve

Muchas herramientas de AI Coding no fallan por no saber escribir código, sino por escribirlo demasiado pronto.

El usuario da una petición vaga, el agente edita archivos y el resultado parece terminado, aunque los límites, tests y arquitectura sigan sin estar claros. En tareas pequeñas puede pasar; en proyectos complejos se convierte en retrabajo y deuda técnica.

Superpowers hace que el agente entre en un workflow antes de tocar código:

Si detecta que el usuario quiere construir algo, pregunta primero por el objetivo.
Convierte la conversación en una especificación y la confirma por partes.
Tras aprobar el diseño, genera un plan de implementación.
Solo cuando el usuario dice “go” empieza a implementar.
Durante la implementación enfatiza TDD, YAGNI, DRY y revisión.

No es ingeniería nueva, pero los agentes rápidos necesitan barandillas más fuertes.

Herramientas soportadas

Superpowers no está ligado a un único agente. El README lista Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor y GitHub Copilot CLI.

Su papel se parece más a una capa de workflow entre harnesses que a un truco para un modelo concreto.

Workflow base

Primero está brainstorming: antes de implementar, el agente convierte ideas vagas en diseño ejecutable y lo confirma.

Después using-git-worktrees: crea un worktree y una rama aislados, y comprueba que instalación y tests parten de una base limpia.

Luego writing-plans: divide el diseño en tareas pequeñas con rutas, alcance de código y pasos de validación.

En ejecución puede usar subagent-driven-development para delegar o executing-plans para avanzar por lotes. Cada tarea debe poder revisarse y verificarse.

Después llega test-driven-development: RED-GREEN-REFACTOR real. Escribir un test que falla, confirmar el fallo, implementar lo mínimo, confirmar el paso y refactorizar.

requesting-code-review introduce revisión entre tareas, y los hallazgos críticos bloquean el avance.

Finalmente finishing-a-development-branch valida tests y ofrece opciones como merge, PR, conservar o descartar el worktree.

Qué hay en la Skills Library

La parte de testing gira alrededor de test-driven-development.

La parte de debugging incluye systematic-debugging y verification-before-completion: reproducir, minimizar, formular hipótesis, validar y no declarar completado sin verificar.

Las skills de colaboración incluyen:

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

También hay skills meta como writing-skills y using-superpowers.

Juntas dan al agente hábitos de ingeniería: cuándo preguntar, planificar, testear y detenerse para review.

Diferencia frente a un prompt normal

Un prompt normal suele apilar reglas en un system prompt: no cambies de más, piensa primero, prueba, explica, sé breve. Cuantas más reglas, más fácil es que el modelo olvide algunas en tareas complejas.

Superpowers divide las reglas en módulos de workflow activables. Cada skill es más corta y enfocada. El agente sabe en qué fase está, el proceso se vuelve revisable y el equipo puede codificar sus propias prácticas.

La lección no es solo usar un modelo más inteligente, sino darle una forma repetible de trabajar.

Para quién sirve

Superpowers encaja mejor con desarrolladores que ya usan coding agents en proyectos reales: tareas de varios archivos, diseño antes de implementación, TDD o validación, ramas o worktrees paralelos, subagents para implementación o review, y equipos que quieren convertir su flujo en skills reutilizables.

Para cambiar una línea de configuración puede ser pesado. Para trabajos de varias fases, sus restricciones aportan valor.

Precauciones

No es piloto automático. Da proceso al agente, pero requisitos, límites y aceptación final siguen siendo humanos.

TDD y review añaden coste inicial. En tareas pequeñas pueden parecer lentos; en tareas complejas reducen retrabajo.

Los subagents en paralelo no siempre ayudan. Funcionan si los límites y el alcance de escritura son claros. Si el requisito es borroso, el paralelismo multiplica la confusión.

También hay que mantener la calidad de las skills. Procesos obsoletos, instrucciones vagas y reglas conflictivas perjudican al agente.

Resumen

Superpowers vale porque aleja al coding agent de “recibir petición y editar código” y lo devuelve al proceso de ingeniería de software.

Lo que falta en AI Coding no suele ser velocidad de generación, sino aclaración, planificación, verificación, review y cierre. Cuanto más fuerte sea el modelo, menos conviene saltarse esos pasos.

Si usas Codex, Claude Code, Cursor o Gemini CLI en proyectos reales, Superpowers merece una lectura. Aunque no lo instales, su forma de dividir skills sirve como referencia para diseñar tu propio workflow de agentes.

Rechazar el Vibe Coding: el repositorio skills de Matt Pocock añade restricciones de ingeniería a la programación con IA

Fri, 15 May 2026 08:46:23 +0800

Cuanto más rápido escribe código la IA, más rápido puede perder el control un proyecto. La cuestión real no es si un modelo puede generar funciones, sino si entiende el requisito, respeta el lenguaje del equipo y avanza con cambios pequeños dentro de la arquitectura existente.

El repositorio mattpocock/skills de Matt Pocock apunta en la dirección opuesta al vibe coding: no dejar que la IA tome todo el proceso de desarrollo, sino ponerla dentro de restricciones maduras de ingeniería de software.

Proyecto: https://github.com/mattpocock/skills

No se trata de un prompt mágico. Es un conjunto de agent skills que convierten aclaración de requisitos, modelado de dominio, TDD, diagnóstico y revisión arquitectónica en workflows adecuados para herramientas de AI Coding.

Primero resolver la falta de alineación

El fallo más común en AI Coding es creer que el modelo entendió cuando en realidad solo adivinó a partir de una descripción vaga.

grill-me invierte la interacción. Antes de escribir código, el agente actúa como un revisor exigente y pregunta por ramas, límites y decisiones pendientes.

Si pides una página de login, debería preguntar primero:

Cómo funcionará recuperar contraseña.
Si habrá login de terceros.
Qué error mostrar cuando falle el login.
Si bloqueo de cuenta, CAPTCHA o control de riesgo están dentro del alcance.
A dónde redirigir tras el éxito.

Parece más lento, pero reduce retrabajo. Cuanto más barato es generar código, más caro se vuelve no haber aclarado el requisito.

Escribir el lenguaje de dominio en el contexto

Otro problema es el vocabulario genérico. El modelo no conoce los términos internos del equipo, así que los nombres de variables, funciones y documentos empiezan a desviarse.

grill-with-docs pregunta mientras revisa CONTEXT.md, ADRs o documentos de dominio. Los términos y decisiones confirmados pueden volver a esos documentos.

Esto se parece al lenguaje ubicuo de DDD. Si el equipo dice customer en lugar de user, o transaction en lugar de order, la IA debe heredar esa terminología.

El valor del contexto no está en acumular datos, sino en reducir la necesidad de adivinar.

Usar TDD para limitar la velocidad

La IA es peligrosa porque es rápida. Antes, escribir mucho mal código tomaba tiempo; ahora aparecen cientos de líneas en segundos. El problema no es la velocidad, sino la falta de ciclos de feedback.

El skill tdd devuelve el ciclo rojo-verde-refactor:

Escribir un test fallido para un comportamiento.
Implementar lo mínimo para pasarlo.
Refactorizar.
Continuar con el siguiente corte vertical.

La clave es avanzar comportamiento por comportamiento. La IA ejecuta; la persona controla dirección y límites.

Diagnosticar con un ciclo

Ante un bug, muchos agentes adivinan y parchean varias veces hasta empeorar el código.

diagnose exige crear primero un ciclo de feedback:

Reproducir el problema
Minimizar el caso
Formular una hipótesis
Añadir observación o logs
Corregir
Añadir una prueba de regresión

Es un proceso clásico, pero en AI Coding es aún más importante. La IA prueba rápido; el proceso la mantiene cerca de la causa raíz.

Revisar la arquitectura con regularidad

Que una tarea pase no significa que el código esté mejor. Muchas pequeñas modificaciones de IA pueden difuminar límites de módulos, complicar interfaces y hacer más difíciles los tests.

Skills como improve-codebase-architecture hacen que el agente mire el código desde más arriba:

Qué módulos mezclan responsabilidades.
Qué interfaces son demasiado complejas.
Qué rutas son difíciles de probar.
Qué nombres no encajan con el lenguaje de dominio.
Qué duplicaciones conviene consolidar.

No es una gran refactorización automática. Es observación estructurada y dirección de mejora; la decisión sigue siendo humana.

Lo que hay que limitar es la libertad

La idea central es sencilla: programar con IA no consiste en dejar improvisar al modelo, sino en darle objetivos, contexto, tests y condiciones de parada.

Las personas definen el problema, los límites de arquitectura, las decisiones de negocio y los criterios de aceptación. La IA genera código, completa tests, repite cambios y hace refactors locales.

Los fundamentos de ingeniería de software no quedaron obsoletos porque la IA mejoró. Aclarar requisitos, usar lenguaje de dominio, TDD, diagnóstico y revisión de arquitectura es cada vez más importante.

Cada vez más personas podrán escribir código. La diferencia estará en quién puede insertar la IA en un sistema de ingeniería mantenible, verificable y capaz de evolucionar.

Codex /goal vs Claude Code /goal: ejecutar tareas largas hasta terminarlas

Thu, 14 May 2026 22:25:31 +0800

/goal se está convirtiendo en un comando importante dentro de las herramientas de programación con IA.

No se trata de hacer que el modelo escriba unas cuantas líneas más de código. Resuelve un problema más práctico: cuando una tarea tiene condiciones claras de finalización, ¿puede el Agent seguir avanzando hasta cumplirlas, en lugar de detenerse después de cada turno y esperar a que el usuario escriba “continúa”?

Codex CLI ya añadió un /goal experimental en su documentación oficial. Claude Code también publicó su propia documentación de /goal, y lo describe como una capacidad de automatización que puede seguir trabajando durante varios turnos. El nombre es el mismo, pero la orientación del producto no es exactamente igual.

Qué problema resuelve `/goal`

Una conversación normal de programación con IA suele funcionar turno por turno:

El usuario plantea una tarea.
El Agent analiza, modifica código y ejecuta pruebas.
El Agent informa el resultado.
El usuario decide el siguiente paso.

Ese flujo funciona bien para tareas cortas. Pero cuando se trata de migraciones, refactors, correcciones de pruebas o limpieza de un issue backlog, se vuelve fragmentado. El Agent puede avanzar solo un poco y luego detenerse hasta que escribas “continúa”.

La idea de /goal es cambiar la pregunta de “qué hago ahora” a “qué estado final cuenta como terminado”. Por ejemplo:

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

Este tipo de objetivo encaja de forma natural con tareas largas, porque tiene un punto final claro: las pruebas pasan, la compilación funciona, los archivos se han dividido, una cola queda vacía o se cumplen los criterios de aceptación.

`/goal` en Codex: experimental y ligado al hilo actual

La documentación de Codex CLI de OpenAI marca /goal como experimental. No es una capacidad estable activada por defecto; primero hay que habilitar features.goals.

Hay dos formas de hacerlo:

`1`	`/experimental`

O añadir esto a config.toml:

1
2

[features]
goals = true

Una vez habilitado, se puede usar así:

`1`	`/goal Finish the migration and keep tests green`

Los comandos habituales incluyen:

/goal
/goal pause
/goal resume
/goal clear

Según la documentación de OpenAI, Codex adjunta el goal al active thread actual y sigue ese objetivo mientras avanza una tarea más grande.

Aquí hay un detalle importante: el lenguaje oficial sobre Codex /goal es prudente. Enfatiza configurar un objetivo experimental para trabajo de larga duración y adjuntar ese objetivo al hilo actual, pero no describe con el mismo detalle que la documentación de Claude Code un evaluator independiente que revise cada turno y arranque automáticamente el siguiente. Por eso, de momento conviene tratar Codex /goal como un mecanismo experimental para objetivos de tareas largas, no como un modo de ejecución desatendida plenamente estable.

`/goal` en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

La documentación de /goal en Claude Code es más explícita: después de que el usuario define una completion condition, Claude sigue trabajando entre turnos hasta cumplirla.

Ejemplo:

`1`	`/goal all tests in test/auth pass and the lint step is clean`

El mecanismo de Claude Code, a grandes rasgos, es este:

Cuando termina el turno actual, el control no vuelve inmediatamente al usuario.
Un modelo pequeño y rápido revisa si la condición del objetivo ya se cumplió.
Si no se cumplió, Claude empieza automáticamente el siguiente turno.
Si se cumplió, el goal se borra automáticamente y el estado de finalización queda registrado en el transcript.

Esto hace que /goal en Claude Code se parezca más a “continuar automáticamente hasta satisfacer la condición de finalización”. No solo fija un objetivo en la conversación; delega en un paso de evaluación independiente la decisión de si debe continuar.

Claude Code también permite ver el estado directamente:

/goal

El estado muestra la condición del objetivo, el tiempo transcurrido, la cantidad de turnos evaluados, el consumo de tokens y la razón más reciente del evaluator.

Para detenerlo antes de tiempo, se puede usar:

`1`	`/goal clear`

stop, off, reset, none y cancel también funcionan como alias de limpieza. Después de activar un objetivo, si la sesión se interrumpe y más tarde se reanuda con --resume o --continue, un goal activo puede recuperarse. Sin embargo, el tiempo, el número de turnos y la línea base de tokens se recalculan.

La diferencia principal

Codex y Claude Code están empujando la programación con IA desde respuestas de un solo turno hacia la ejecución de tareas largas, pero la posición de /goal no es la misma.

Comparación	Codex CLI `/goal`	Claude Code `/goal`
Estado	experimental	documentado en una página oficial dedicada
Activación	requiere `features.goals`	usable directamente en un workspace confiable
Alcance del objetivo	active thread actual	session actual
Operaciones habituales	set / view / pause / resume / clear	set / view / clear
Evaluación automática	la documentación enfatiza adjuntar y seguir el objetivo	la documentación describe checks del evaluator después de cada turno
Continuación automática	el lenguaje oficial es prudente	empieza el siguiente turno automáticamente si las condiciones no se cumplen
Mejor caso de uso	mantener un objetivo de largo plazo en una tarea de Codex	dejar que Claude Code avance según condiciones de finalización

En resumen, /goal en Codex se parece más a “adjuntar un objetivo experimental de largo plazo al hilo actual”. /goal en Claude Code se parece más a “definir una condición verificable de parada para la sesión actual y dejar que siga trabajando hasta satisfacerla”.

Cómo escribir un buen `/goal`

Uses la herramienta que uses, /goal no es un buen lugar para deseos vagos.

Un mal ejemplo:

`1`	`/goal 把项目优化一下`

Un mejor ejemplo:

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

Un buen objetivo suele incluir tres cosas:

Un estado final claro.
Un método de validación ejecutable.
Límites que deben respetarse.

Si el objetivo es grande, conviene añadir una condición de parada:

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

Esto importa. Cuanto más potente sea /goal, más necesita límites. Si no, el Agent puede modificar demasiados archivos, ejecutarse durante demasiado tiempo, consumir demasiados tokens o seguir adelante con una cuestión que debería haberse detenido para pedir criterio humano.

Cuándo conviene usar `/goal`

Encaja bien con:

Corrección de pruebas: hasta que pasen pruebas específicas.
Migraciones de código: hasta que todos los puntos de llamada estén actualizados y la compilación funcione.
Limpieza por lotes: hasta eliminar una clase de errores de lint o tipos.
Documentación: hasta que todos los módulos especificados tengan explicación.
Gestión de issues: hasta que todos los issues bajo una etiqueta estén tratados o clasificados con claridad.

No encaja bien con:

Requisitos que todavía no están claros.
Tareas que requieren juicio de producto frecuente.
Eliminaciones de alto riesgo, migraciones de datos o cambios de permisos.
Criterios de aceptación puramente subjetivos.
Tareas que cruzan muchos módulos no relacionados.

Una regla práctica: si puedes escribir “qué comando ejecutar, qué resultado esperar y qué archivos no se deben tocar”, es buen candidato para /goal. Si solo puedes escribir “hazlo mejor”, sigue siendo más seguro usar conversación normal, plan mode o revisión humana.

Qué significa esto para las herramientas de programación con IA

/goal apunta a una dirección clara: las herramientas de programación con IA están pasando de asistentes interactivos a unidades de trabajo que pueden ejecutarse de forma continua.

Antes, usar un Agent solía implicar quedarse cerca. Si se atascaba, lo guiabas. Si terminaba las pruebas, le decías que continuara. Si aparecía un error, dabas otra orden. /goal comprime esa interacción en una condición de finalización y deja que el Agent decida qué debe hacer el siguiente turno.

Pero esto también sube el listón para los usuarios. Escribir prompts ya no consiste solo en describir una tarea; también implica definir criterios de aceptación, comandos de validación, límites de modificación y reglas de parada. Dicho de otro modo, el trabajo del usuario pasa de “pedirle que continúe” a “definir qué significa terminado”.

Que Codex y Claude Code hayan llegado a /goal muestra que los Agents de tareas largas ya no pertenecen solo a tareas en segundo plano o colas en la nube. Las herramientas locales de programación en terminal también empiezan a necesitar una capacidad más fuerte de avance autónomo.

Resumen

Codex CLI y Claude Code tienen /goal, pero por ahora no conviene tratarlos como la misma función.

El /goal de Codex sigue siendo experimental, requiere features.goals y encaja mejor como una forma de mantener un objetivo de largo plazo en el hilo actual de Codex. El /goal de Claude Code conecta de forma más explícita las condiciones de finalización con la continuación automática, usando un evaluator independiente para decidir si debe seguir.

Para el desarrollo diario, este tipo de comando funciona mejor en tareas de ingeniería con criterios de aceptación claros. No reemplaza el juicio de producto ni la revisión de código, pero puede reducir mucho el ciclo repetitivo de “continúa”, “ejecútalo otra vez” y “corrige hasta que pasen las pruebas”.

La habilidad importante no es memorizar el comando, sino aprender a escribir tareas como objetivos claros, verificables y detenibles.

Referencias

OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
Documentación de Claude Code Goal: https://code.claude.com/docs/en/goal

¿Cómo conectar Codex con modelos chinos? Gestionar APIs compatibles con OpenAI usando CCX

Wed, 13 May 2026 23:20:40 +0800

CCX es una pasarela de proxy y conversión de protocolos para APIs de IA. Coloca Claude Messages, OpenAI Chat Completions, OpenAI Images, Codex Responses y Gemini API detrás de una única entrada de servicio, y ofrece una interfaz web para configurar canales, claves, mapeos de modelos, prioridades, failover y monitoreo de tráfico.

Si usas Claude, OpenAI, Gemini y Codex al mismo tiempo, o mantienes varios servicios aguas arriba compatibles con OpenAI API, el valor de CCX está en unificar la entrada y la gestión. Los clientes se conectan a una sola dirección; CCX decide qué canal aguas arriba debe atender cada solicitud.

Proyecto: https://github.com/BenedictKing/ccx

Qué problema resuelve CCX

Cuando se mezclan varias APIs de IA, aparecen rápidamente algunos problemas:

Cada proveedor tiene rutas, autenticación y formatos de solicitud diferentes.
Una misma clase de modelos puede tener varios upstreams, lo que obliga a cambiar manualmente base URL y API key.
Cuando una clave o canal falla, el cliente normalmente no cambia automáticamente a un canal de respaldo.
En equipos, cuesta centralizar allowlists de modelos, proxies, cabeceras personalizadas y logs.
Al conectar Claude, Gemini, OpenAI Chat, APIs de imagen y Codex Responses, la configuración se dispersa.

La idea de CCX es concentrar esas diferencias en una capa proxy. Las herramientas frontend, scripts o servicios de negocio llaman a CCX; luego CCX enruta la solicitud al upstream adecuado según tipo de API, modelo, estado del canal, prioridad y salud.

Endpoints soportados

CCX expone una entrada backend unificada. El puerto predeterminado es 3000. Las rutas principales incluyen:

GET  /                         -> Interfaz web de administración
GET  /health                   -> Health check
/api/*                         -> API de administración
POST /v1/messages              -> Proxy de Claude Messages
POST /v1/chat/completions      -> Proxy de OpenAI Chat
POST /v1/responses             -> Proxy de Codex Responses
POST /v1/images/generations    -> Generación con OpenAI Images
POST /v1/images/edits          -> Edición con OpenAI Images
POST /v1/images/variations     -> Variaciones con OpenAI Images
GET  /v1/models                -> Lista de modelos
POST /v1beta/models/*          -> Proxy de Gemini

Es decir, CCX no se limita a un protocolo. Gestiona APIs comunes de IA como tipos de canal separados: Messages, Chat, Responses, Gemini e Images. Cada protocolo mantiene su propio estado de salud y espacio de logs, lo que ayuda al diagnóstico.

Arquitectura

CCX usa backend en Go y frontend en Vue 3. El build del frontend se incrusta en el binario del backend, por lo que puede desplegarse en un solo puerto: el mismo servicio ofrece Web UI, API de administración y API proxy.

Una solicitud pasa aproximadamente por esta cadena:

`1`	`Client -> Auth Middleware -> Route Handler -> Channel Scheduler -> Provider / Converter -> Upstream API -> Metrics / Channel Logs -> Client Response`

Los módulos principales:

handlers: reciben solicitudes de distintos protocolos y operaciones de administración.
providers: encapsulan el manejo de solicitudes y respuestas del upstream.
converters: gestionan conversiones de protocolo en escenarios como Responses.
scheduler: elige canales según prioridad, periodo promocional, salud, circuito abierto y afinidad de traza.
metrics: registra volumen, tasa de éxito, latencia, logs y estado de circuit breaker.
config: mantiene configuración en tiempo de ejecución, con hot reload y respaldo.

El objetivo no es forzar todas las APIs a un único formato, sino proxyar cada tipo de protocolo por separado y unificar gestión, planificación, logs y autenticación.

Diferencias entre CCX y CodexBridge

CCX y CodexBridge están relacionados con Codex y las APIs compatibles con OpenAI, pero resuelven problemas distintos.

CodexBridge es más bien un puente dedicado para Codex. Su objetivo principal es encapsular Codex CLI/SDK como un servicio /v1/chat/completions compatible con OpenAI, para que OpenWebUI, Cherry Studio, scripts u otros clientes compatibles puedan llamar a Codex local. En resumen, CodexBridge se centra en exponer Codex.

CCX se parece más a una pasarela unificada de APIs de IA. No solo maneja Codex Responses; también soporta Claude Messages, OpenAI Chat, OpenAI Images y Gemini API, con interfaz web, prioridad de canales, failover, monitoreo de logs y gestión de múltiples claves. En resumen, CCX se centra en gestionar varios modelos y proveedores juntos.

Comparación rápida:

Aspecto	CodexBridge	CCX
Posicionamiento	Puente local para Codex	Pasarela AI API multiprotocolo
Objetivo principal	Convertir Codex en endpoint compatible con OpenAI	Gestionar juntos Claude, OpenAI, Gemini, Codex y otros canales
Interfaz de gestión	Se centra en el servicio API	Ofrece interfaz web de administración
Planificación multicanal	No es el foco	Soporta prioridad, failover y monitoreo de logs
Mejor escenario	Llamadas locales o de un solo servicio a Codex	Equipos, múltiples claves, proveedores y protocolos

Si solo quieres conectar Codex a OpenWebUI o Cherry Studio, CodexBridge es más directo. Si quieres gestionar Codex, Claude, Gemini, DeepSeek, Qwen, Kimi y otros upstreams juntos, CCX encaja mejor.

Despliegue rápido

La forma más sencilla es descargar el binario. Luego crea .env en el mismo directorio:

PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3000
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=zh-CN

Tras iniciar, abre:

`1`	`http://localhost:3000`

Si desde WSL, Docker, PowerShell u otro entorno en Windows localhost no funciona, usa la IPv4 LAN del host Windows, por ejemplo:

`1`	`http://192.168.1.23:3000`

CCX escucha por defecto en :PORT para todas las interfaces, así que debes controlar el acceso si lo expones a la LAN.

Despliegue con Docker

Docker es adecuado para mantener el servicio en ejecución:

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=zh-CN \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

Si el repositorio ya incluye docker-compose.yml, también puedes ejecutar:

`1`	`docker compose up -d`

Para actualizaciones automáticas, añade la configuración de Watchtower:

`1`	`docker compose -f docker-compose.yml -f docker-compose.watchtower.yml up -d`

Tras desplegar, .config guarda configuración de runtime y datos persistentes. Conviene montarlo en el host para no perder configuración al recrear el contenedor.

Ejecutar desde código fuente

Para desarrollo o builds personalizados:

git clone https://github.com/BenedictKing/ccx
cd ccx
cp backend-go/.env.example backend-go/.env
make run

Comandos comunes:

make dev
make run
make build
make frontend-dev

Desarrollo solo del frontend:

1
2
3

cd frontend
bun install
bun run dev

Desarrollo solo del backend:

1
2

cd backend-go
make dev

Variables de entorno clave

Una configuración mínima suele incluir:

PORT=3000
ENV=production
ENABLE_WEB_UI=true
PROXY_ACCESS_KEY=your-proxy-access-key
ADMIN_ACCESS_KEY=your-admin-secret-key
APP_UI_LANGUAGE=zh-CN
LOG_LEVEL=info
REQUEST_TIMEOUT=300000

Notas:

PROXY_ACCESS_KEY se usa para la API proxy y debe cambiarse.
ADMIN_ACCESS_KEY se usa para la Web UI y /api/*; conviene separarlo de la clave proxy.
ENABLE_WEB_UI controla si la interfaz de administración está activa.
REQUEST_TIMEOUT controla el timeout; aumenta el valor para contextos largos o tareas de imagen.
LOG_LEVEL controla la verbosidad; en producción suele usarse info o warn.

Para limitar el tamaño del cuerpo:

`1`	`MAX_REQUEST_BODY_SIZE_MB=50`

La edición de imágenes, imágenes base64 y solicitudes multimodales pueden aumentar mucho el cuerpo.

Orquestación de canales y failover

La interfaz de CCX permite configurar múltiples canales, con opciones como:

Tipo de servicio upstream.
API key o rotación de múltiples claves.
Dirección proxy.
Cabeceras personalizadas.
Allowlist de modelos.
Prefijo de ruta.
Prioridad.
Health checks y recuperación de circuit breaker.

La planificación considera estado del canal, prioridad, periodo promocional, afinidad de traza, estado de circuit breaker y claves disponibles. En simple:

Normalmente se usan primero los canales de mayor prioridad.
Si un canal falla, CCX puede cambiar a un canal de respaldo.
El circuit breaker evita seguir llamando a un upstream claramente no disponible.
La afinidad de traza intenta mantener sesiones relacionadas en canales adecuados.

Estas funciones son útiles con múltiples claves, proveedores o upstreams regionales. Para uso personal ligero, también puedes configurar un solo canal y usar CCX como capa proxy con Web UI.

Logs y monitoreo

CCX ofrece métricas de canal y logs de solicitudes, incluyendo:

Volumen de solicitudes.
Tasa de éxito.
Tasa de fallo.
Latencia media.
Historial por modelo.
Estado de canales y circuit breakers.

En producción conviene una configuración de logs contenida:

ENV=production
LOG_LEVEL=info
ENABLE_REQUEST_LOGS=true
ENABLE_RESPONSE_LOGS=false

Así conservas información básica sin escribir respuestas completas en logs. Para investigar problemas puedes activar logs más detallados temporalmente, pero después deberías volver a una configuración segura, sobre todo en producción.

Recomendaciones de seguridad

CCX es una pasarela proxy y almacena API keys aguas arriba, así que no basta con que “funcione”. Como mínimo:

No uses un PROXY_ACCESS_KEY predeterminado o demasiado corto.
Define un ADMIN_ACCESS_KEY separado.
No expongas directamente la Web UI a internet.
Si necesitas acceso público, colócala detrás de reverse proxy, VPN, control de acceso o SSO.
No subas .env, .config ni logs a Git.
No mantengas logs completos de cuerpo de solicitud y respuesta en producción.

Puedes generar claves aleatorias así:

1
2

PROXY_ACCESS_KEY=$(openssl rand -base64 32)
ADMIN_ACCESS_KEY=$(openssl rand -base64 32)

Para quién es adecuado

CCX encaja mejor en estos escenarios:

Mantener Claude, OpenAI, Gemini, Codex o APIs de imagen al mismo tiempo.
Tener varias API keys que requieren rotación, enrutamiento y failover.
Gestionar upstreams desde una Web UI en vez de editar archivos manualmente.
Observar tasa de éxito, latencia y logs de cada canal.
Proporcionar a un equipo una entrada AI API unificada.

Si solo llamas ocasionalmente a un modelo en tu equipo local, el SDK oficial o un proxy compatible con OpenAI más simple será suficiente. La ventaja de CCX está en múltiples canales, múltiples protocolos y operación unificada.

Resumen

CCX es una pasarela AI API, no un cliente para un modelo concreto. Coloca Claude Messages, OpenAI Chat, OpenAI Images, Codex Responses y Gemini en una capa proxy, y ofrece orquestación de canales, failover, logs, monitoreo y Web UI.

Para usuarios individuales, reduce la molestia de cambiar direcciones API y claves. Para equipos o servicios de larga duración, se parece más a una pasarela ligera de IA. Antes de producción, lo importante no es solo configurar modelos, sino también claves, entrada de administración, niveles de log, prioridades de canal y estrategia de failover.

Referencias

Proyecto GitHub: https://github.com/BenedictKing/ccx
Arquitectura: https://github.com/BenedictKing/ccx/blob/main/ARCHITECTURE.md
Variables de entorno: https://github.com/BenedictKing/ccx/blob/main/ENVIRONMENT.md

¿Cómo conectar Codex con modelos chinos? APIs compatibles con OpenAI y el enfoque de CodexBridge

Wed, 13 May 2026 23:08:28 +0800

CodexBridge es una herramienta local de puente cuyo objetivo es claro: exponer Codex CLI/SDK como un servicio HTTP compatible con OpenAI. Así, Codex deja de estar limitado al terminal y puede ser llamado desde OpenWebUI, Cherry Studio, scripts, sistemas de automatización o cualquier cliente compatible con OpenAI Chat Completions.

Sus endpoints principales son /v1/chat/completions y /v1/models. El primero gestiona conversaciones y admite respuestas normales y transmisión SSE. El segundo permite a los clientes descubrir modelos como si leyeran una lista de modelos estilo OpenAI. Para herramientas que ya soportan OpenAI API, normalmente basta con cambiar el base URL, la API key y el nombre del modelo.

Proyecto: https://github.com/begonia599/CodexBridge

Cuándo usarlo

CodexBridge encaja cuando quieres integrar Codex en clientes o flujos de trabajo existentes. Por ejemplo:

Seleccionar Codex directamente en OpenWebUI o Cherry Studio.
Llamar a Codex local desde curl, Python, Node.js u otros scripts.
Conectar un mismo frontend a OpenAI, Ollama, otras APIs compatibles y Codex.
Conservar los hilos locales, sandbox, directorio de trabajo y aprobaciones de Codex.
Ofrecer a herramientas internas una entrada unificada /v1/chat/completions.

No es un nuevo LLM ni un reemplazo completo de Codex CLI. Es más bien una capa adaptadora: Codex sigue siendo el motor aguas arriba, y el puente convierte solicitudes estilo OpenAI en entradas de conversación que Codex entiende.

Requisitos básicos

Antes de ejecutarlo necesitas:

Node.js 18 o superior.
Codex CLI instalado y con sesión iniciada.
npm, o pnpm / yarn si lo prefieres.

Despliegue básico desde código fuente:

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

Luego edita .env o .env.local para definir la API key, modelo predeterminado, directorio de trabajo, modo sandbox, acceso de red y otras opciones.

Inicia el servicio HTTP:

`1`	`npm run codex:server`

El puerto predeterminado es 8080, configurable con PORT. Tras iniciar, el servicio expone:

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

Modo de conversación CLI

Además del servicio HTTP, CodexBridge conserva una CLI ligera:

`1`	`npm run codex:chat`

Desde la CLI puedes escribir mensajes en lenguaje natural para conversar con Codex. Dos comandos útiles son:

/reset: crear un nuevo hilo de Codex.
/exit: salir de la CLI.

El ID del hilo actual se guarda en .codex_thread.json. Si este archivo sigue existiendo al iniciar la CLI de nuevo, puedes continuar la conversación anterior.

Ejemplo HTTP

Una solicitud mínima:

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

Puntos importantes:

El token de authorization debe coincidir con CODEX_BRIDGE_API_KEY.
model puede incluir nivel de razonamiento, por ejemplo gpt-5-codex:medium o gpt-5-codex:high.
session_id vincula la solicitud a una conversación y permite reutilizar el mismo hilo de Codex.

Para salida en streaming, añade stream: true:

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"Explica paso a paso cómo crear un proyecto Node.js"}]}'

Para clientes que soportan respuestas en streaming de OpenAI, esta forma se siente más cercana a una conversación normal.

Persistencia de sesiones

Una función importante de CodexBridge es el mapeo de sesiones. La solicitud puede pasar un ID de sesión mediante estos campos:

session_id
conversation_id
thread_id
user

También puede pasarse por cabeceras:

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

En producción conviene activar:

`1`	`CODEX_REQUIRE_SESSION_ID=true`

Así todas las solicitudes deben incluir un ID de sesión, evitando que distintos usuarios o ventanas de chat se mezclen en el mismo contexto temporal. El mapeo del puente se guarda en .codex_threads.json. Borrar este archivo restablece la relación del puente; los hilos propios de Codex siguen en ~/.codex/sessions.

Si CODEX_REQUIRE_SESSION_ID=false y la solicitud no incluye ID de sesión, el puente expande los messages actuales como una entrada de un solo uso para Codex. Sirve para llamadas temporales, pero no para conversaciones largas.

Entrada multimodal

CodexBridge admite bloques de contenido estilo OpenAI y convierte imágenes en entradas local_image utilizables por Codex.

Imagen remota:

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

Imagen local:

{
  "type": "local_image",
  "path": "./images/demo.png"
}

Los recursos remotos se descargan primero en un directorio temporal y se limpian al final del turno. En uso real, presta atención al tamaño del cuerpo de la solicitud, especialmente cuando envías imágenes en base64. Puede que necesites aumentar CODEX_JSON_LIMIT.

Salida estructurada

Si el cliente soporta response_format, CodexBridge puede mapearlo al outputSchema de Codex. Es útil cuando quieres que Codex devuelva una estructura JSON fija, como resultados de revisión, resúmenes, clasificación o informes de automatización.

Ejemplo mínimo:

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "Revisa los problemas de lint en src/ y devuelve el resultado como JSON"
    }
  ]
}

type: "json_schema" debe incluir schema; de lo contrario, el servicio devuelve 400.

Variables de entorno clave

La configuración común puede agruparse así.

Servicio y autenticación:

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

Modelo predeterminado:

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Entorno de ejecución de Codex:

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

Acceso de red:

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

Si solo lo usas para chat desde un frontend, es más seguro mantener la red desactivada por defecto. Activa estas opciones solo cuando Codex necesite ejecutar curl, git clone o búsqueda web.

Docker y scripts de instalación

El proyecto también ofrece despliegue con Docker para mantener el servicio en ejecución:

1
2

docker compose up -d
docker compose logs -f codexbridge

También hay un script de instalación para Linux:

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

El script instala dependencias, clona o actualiza el repositorio, copia .env.example e inicia el servicio con Docker Compose. Requiere sudo, por lo que encaja mejor en un servidor limpio. Si la máquina ya tiene un entorno complejo de Node.js, Docker o Codex, revisa el script antes de ejecutarlo.

Problemas comunes

La solicitud devuelve 413

Normalmente el cuerpo es demasiado grande, a menudo por imágenes base64. Aumenta:

`1`	`CODEX_JSON_LIMIT=20mb`

La API key no es válida

Comprueba que la cabecera incluya:

`1`	`Authorization: Bearer <tu CODEX_BRIDGE_API_KEY>`

o usa x-api-key.

Codex informa una restricción de repositorio Git

Si el directorio de ejecución no es un repositorio confiable, Codex puede activar una verificación. Úsalo solo en entornos seguros:

`1`	`CODEX_SKIP_GIT_CHECK=true`

Restablecer conversaciones

El mapeo del puente está en .codex_threads.json, y los hilos propios de Codex están en ~/.codex/sessions. Detén el servicio y borra los archivos o directorios correspondientes para restablecerlos.

Recomendaciones

Para pruebas locales, empieza con la API key predeterminada y el sandbox read-only. Cuando OpenWebUI, Cherry Studio o tus scripts llamen al servicio correctamente, ajusta gradualmente CODEX_WORKDIR, CODEX_SANDBOX_MODE, CODEX_NETWORK_ACCESS y CODEX_APPROVAL_POLICY.

Si lo usarán varias personas, al menos:

Exige session_id.
Cambia la API key predeterminada.
Limita claramente el directorio de trabajo y los permisos del sandbox.

El valor de CodexBridge no está en tener muchas funciones, sino en colocar Codex dentro del ecosistema compatible con OpenAI. Si un cliente permite cambiar el base URL, puede tratar Codex como un modelo de chat normal y conservar al mismo tiempo sus hilos locales, sandbox y llamadas a herramientas.

ProgramBench 0% explicado: lo inquietante no es el fallo, sino que la hoja de ruta ya está clara

Sun, 10 May 2026 12:32:39 +0800

En el mundo de AI Coding acaba de aparecer un nuevo benchmark: ProgramBench. A primera vista, su resultado parece tranquilizador para los programadores: nueve modelos principales obtuvieron 0% en la métrica fully resolved, y ningún modelo completó por completo ni una sola tarea.

Pero lo verdaderamente inquietante no es que los grandes modelos actuales todavía fallen. Lo importante es que, por primera vez, la ingeniería de software completa se ha convertido en un conjunto claro de tareas evaluables, clasificables y optimizables de forma repetida.

Una vez que una tarea queda definida con claridad, la industria de IA suele hacer lo que mejor sabe hacer: resolver el benchmark, iterar, perseguir el leaderboard y empujar poco a poco lo que antes parecía imposible hacia el borde de lo utilizable.

Qué mide ProgramBench

Muchos benchmarks de programación miden completar funciones, corregir bugs, pasar unit tests o añadir una pequeña función a un proyecto existente. ProgramBench es mucho más duro. No proporciona código fuente, ni estructura de proyecto, ni test cases ya preparados.

El modelo recibe principalmente solo dos cosas:

Un ejecutable ya compilado.
La documentación de uso de ese programa.

El modelo debe ejecutar el binario por su cuenta, observar el comportamiento de entrada y salida, entender argumentos de línea de comandos, casos límite, mensajes de error y formas de almacenamiento de datos, y luego volver a implementar un programa con comportamiento equivalente.

Esto ya no es “escribir un fragmento de código”. Es una tarea de ingeniería de software simplificada pero completa: entender requisitos, explorar comportamiento, elegir lenguaje, diseñar estructura, escribir código fuente, proporcionar un método de build e intentar pasar las pruebas ocultas.

Según la descripción oficial de ProgramBench, actualmente contiene 200 tareas, desde pequeñas herramientas de línea de comandos hasta proyectos reales grandes como PHP, FFmpeg y SQLite. El conjunto de pruebas se genera mediante agent-driven fuzzing y supera las 248.000 pruebas de comportamiento.

Si descomponemos el flujo de evaluación, ProgramBench mide aproximadamente cuatro capacidades:

Leer documentación: entender qué comandos, argumentos y salidas debe ofrecer el programa.
Explorar comportamiento: ejecutar repetidamente el binario y observar entradas normales, entradas inválidas y casos límite.
Reconstruir la implementación: elegir lenguaje y estructura de proyecto, y escribir un reemplazo con comportamiento cercano.
Pasar pruebas ocultas: no basta con acertar el comportamiento normal; también cuentan el manejo de errores, el formato de salida y las condiciones de borde.

Por eso su valor de búsqueda no es simplemente “otro ranking”. Responde a una pregunta más concreta: ¿puede un gran modelo recrear software real desde cero, sin código fuente, usando solo documentación y comportamiento de caja negra?

Por qué el resultado es 0%

La métrica principal de ProgramBench es fully resolved: una tarea solo cuenta como completada si todas sus pruebas pasan. En el leaderboard actual, los nueve modelos tienen 0% en esta métrica.

Los modelos evaluados incluyen familias como Claude, GPT y Gemini, todos usando mini-SWE-agent como agent base. Claude Opus 4.7 es el mejor en la métrica almost resolved, con alrededor de 3.0% de tareas que pasan al menos el 95% de las pruebas. Claude Opus 4.6 llega a 2.5%, y Claude Sonnet 4.6 a 1.0%. GPT 5.4, GPT 5.4 mini, Gemini 3.1 Pro, Gemini 3 Flash y otros quedan en 0.0% en almost resolved.

Esto muestra que los grandes modelos actuales, combinados con un agent ligero, todavía no pueden reconstruir software completo desde cero. Incluso en las tareas más simples, alinear todos los detalles resulta difícil.

Pero hay un matiz importante: esta evaluación usó mini-SWE-agent, no Claude Code ni Codex. Con un coding agent más fuerte, más soporte de herramientas y un ciclo de exploración más largo, los resultados podrían mejorar. La interpretación más precisa es: los modelos actuales con un agent ligero aún no bastan para completar de forma estable la reconstrucción de software completo.

Qué significan fully resolved y almost resolved

Al leer los resultados de ProgramBench, estas dos métricas son fáciles de confundir.

fully resolved es la métrica más estricta: todas las pruebas ocultas de una tarea deben pasar para que se considere completamente resuelta. Si falta un caso límite, un formato de error o un comportamiento de argumento de línea de comandos, la tarea no cuenta como fully resolved.

almost resolved se parece más a “casi completado”: si una tarea pasa al menos el 95% de sus pruebas, entra en almost resolved. Refleja si el modelo logró reproducir la mayor parte del comportamiento, pero no significa que el programa ya pueda sustituir al software original.

Por eso el 0% debe leerse por partes. El 0% en fully resolved indica que los modelos aún no pueden entregar una solución completa. La diferencia en almost resolved muestra qué modelos ya se acercan al éxito en algunas tareas. Por ejemplo, Claude Opus 4.7 alcanza alrededor de 3.0% en almost resolved, lo que indica que se acerca más en unas pocas tareas relativamente simples, pero sigue muy lejos de reconstruir software completo de forma estable.

Por qué mini-SWE-agent afecta el resultado

La evaluación usa un mini-SWE-agent unificado, lo cual tiene una ventaja clara: equidad. Todos los modelos corren sobre el mismo marco ligero de agent, así que la comparación horizontal es más sencilla.

Pero también limita el techo. La reconstrucción de software completo no depende solo del modelo. También depende de si el agent puede planificar una estrategia de exploración, gestionar tareas largas, generar tests automáticamente, localizar causas de fallo de forma repetida y organizar la estructura del proyecto.

mini-SWE-agent se parece más a una línea base común que al entorno de ingeniería más potente posible.

Coding agents más completos como Claude Code o Codex suelen ofrecer mejor uso de herramientas, organización de contexto, descomposición de tareas y reparación en múltiples rondas. Si se usaran esas herramientas, los resultados podrían ser mejores.

Así que el resultado de ProgramBench se entiende mejor así: los modelos actuales no pueden realizar reconstrucción completa de software en un entorno de agent ligero. No demuestra que los modelos nunca podrán hacerlo, ni mide por completo el techo de todos los coding agents comerciales.

Diferencias con SWE-bench

SWE-bench ya es un benchmark importante en AI Coding. Pide a los modelos leer issues en repositorios reales de GitHub, modificar código y enviar parches, para evaluar su capacidad de resolver bugs reales.

Pero SWE-bench sigue siendo, en esencia, reparar un coche existente: el coche ya está ahí, y el stack tecnológico, la estructura de directorios, la organización del código y la arquitectura ya fueron creados por humanos. El modelo solo necesita encontrar el problema y arreglar la pieza rota.

ProgramBench se parece más a construir el coche de nuevo: solo sabes qué comportamiento debe tener, por ejemplo detenerse ante un semáforo rojo o tocar la bocina cerca de peatones. La estructura, el lenguaje, los módulos y el método de build deben decidirse desde cero.

Por eso es mucho más difícil. Ya no evalúa solo la capacidad de hacer parches locales, sino arquitectura de software, razonamiento de sistemas, exploración de comportamiento, pruebas automáticas, corrección en múltiples rondas y diseño de ingeniería a largo plazo.

La diferencia puede resumirse así:

Dimensión	SWE-bench	ProgramBench
Punto de partida	Repositorio de GitHub e issue existentes	Ejecutable compilado y documentación de uso
Código fuente disponible	Sí	No
Tarea principal	Corregir un bug en un proyecto existente	Reimplementar un programa completo a partir del comportamiento
Stack tecnológico	Ya definido por el proyecto	Elegido por el modelo
Estructura del proyecto	Ya existe	Diseñada por el modelo
Método de prueba	Ejecutar tests tras enviar un parche	Usar pruebas ocultas de comportamiento para medir la reconstrucción
Enfoque principal	Leer código, localizar problemas, reparar con parches	Explorar comportamiento, abstraer sistemas, diseñar arquitectura, implementar completo

Por eso ProgramBench encaja mejor como objetivo de la siguiente etapa de AI Coding: empuja el problema desde “arreglar código existente” hacia “reconstruir software completo”.

0% no significa seguridad

Al ver 0%, la primera reacción de muchas personas puede ser: el trabajo de los programadores está a salvo por ahora.

A corto plazo, eso es cierto. Los grandes modelos actuales todavía no pueden completar ingeniería de software completa de forma estable, especialmente sin código fuente, test cases ni estructura de proyecto. La aclaración de requisitos, el diseño de arquitectura, el mantenimiento a largo plazo, el control de seguridad, la colaboración de equipo y la comprensión del negocio siguen siendo ventajas importantes de los ingenieros humanos.

Pero interpretar 0% como “AI Coding llegó a su límite” sería demasiado optimista.

Lo que ProgramBench cambia de verdad es la definición del problema. Antes ya sabíamos que la IA podía completar código y corregir bugs, pero “reconstruir software completo a partir de un ejecutable y documentación” no estaba colocado en una pista común. Ahora son 200 tareas, una evaluación unificada y un ranking unificado.

Eso significa que las empresas de modelos, agents y herramientas de desarrollo saben hacia dónde empujar: hacer que la IA evolucione de escribir fragmentos de código a mantener, reconstruir y entregar sistemas de software completos.

Por qué hacen falta modo offline y anti-cheating

Hay un detalle importante en el diseño de ProgramBench: evitar trampas.

En pruebas iniciales, los modelos intentaban encontrar directamente el código fuente en GitHub, descargar paquetes que contenían el código mediante package managers, o incluso buscar paquetes ya descargados en directorios de caché del sistema. Eso rompe el propósito de la evaluación, porque la pregunta deja de ser “puede reconstruir software desde el comportamiento” y pasa a ser “puede encontrar el código fuente original”.

Por eso ProgramBench usa sandbox y entorno offline. No permite acceso a internet, ni decompilación, ni desensamblado, ni lectura del contenido del ejecutable. El modelo solo puede ejecutar el programa, observar su comportamiento y luego implementar su propia versión.

Esta restricción hace la evaluación más limpia y la acerca a la pregunta real: ¿puede un gran modelo de lenguaje partir del comportamiento y la documentación de un programa para construir por sí mismo un proyecto de software ejecutable?

Qué deben mejorar realmente los programadores

El resultado de ProgramBench no es simplemente una buena noticia ni una mala noticia para los programadores.

A corto plazo, la ingeniería de software completa sigue siendo difícil, y los programadores no van a perder su trabajo de inmediato por este benchmark. En especial, el juicio arquitectónico, la aclaración de requisitos, el control de seguridad, la validación de calidad y la comprensión del negocio todavía requieren responsabilidad humana.

A largo plazo, el trabajo del programador seguirá subiendo de nivel. Las personas más vulnerables no son quienes “no saben escribir código”, sino quienes solo saben escribir código y no saben definir problemas, verificar resultados, organizar toolchains ni controlar riesgos.

El ingeniero de software del futuro podría parecerse más a esto:

Definidor de requisitos: convertir problemas de negocio difusos en objetivos ejecutables.
Validador de sistemas: juzgar si el resultado generado por IA realmente cumple los requisitos.
Organizador de toolchains: combinar modelos, agents, tests, despliegue y monitorización.
Responsable de calidad: controlar seguridad, mantenibilidad, casos límite y riesgos a largo plazo.
Traductor entre negocio y tecnología: convertir problemas reales en restricciones que un sistema de ingeniería pueda manejar.

Si la IA realmente evoluciona de asistente de código a ingeniero de software completo, el valor del programador humano ya no será escribir cada línea a mano. Será definir qué vale la pena construir, qué cuenta como correcto y dónde no se puede fallar.

Resumen

El 0% de ProgramBench no es el final. Es el comienzo de una nueva etapa.

Muestra que los grandes modelos actuales todavía no pueden reconstruir de forma estable sistemas de software completos desde cero. Pero también define con claridad el objetivo de la próxima generación de AI Coding agents: pasar de parches locales a proyectos completos, de fragmentos de código a entrega de sistemas.

Para los programadores, a corto plazo se puede respirar un poco. Pero a largo plazo no conviene quedarse mirando solo que “la IA todavía no puede”. Lo más importante es subir cuanto antes de ejecutor de código a definidor de problemas, validador de resultados y controlador de riesgos.

Lo verdaderamente inquietante no es que la IA haya sacado 0% hoy. Es que el examen ya está escrito.

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.

OpenAI presenta Advanced Account Security: una capa más fuerte para proteger cuentas de ChatGPT y Codex

Fri, 01 May 2026 06:15:29 +0800

OpenAI presentó Advanced Account Security el 30 de abril de 2026 como una opción de alta seguridad para cuentas de ChatGPT.

Está pensada sobre todo para dos grupos: personas con mayor riesgo de ataques dirigidos, como periodistas, cargos electos, disidentes políticos o investigadores; y usuarios especialmente sensibles a la seguridad que quieren más protección para sus cuentas de ChatGPT y Codex.

Una vez activada, la función protege no solo ChatGPT, sino también Codex cuando se accede con la misma cuenta.

Por qué las cuentas de ChatGPT necesitan más seguridad

Cada vez más personas usan ChatGPT para trabajo privado o de alto impacto. Una cuenta puede contener:

preguntas personales y conversaciones largas;
documentos de trabajo y contexto de proyectos;
herramientas conectadas y flujos de trabajo;
código y tareas de desarrollo en Codex;
materiales empresariales, de investigación o de seguridad.

Si una cuenta se compromete, el daño no se limita al historial de chat. Un atacante puede acceder a herramientas conectadas, ver contexto sensible o interferir con trabajo en curso.

Por eso OpenAI no está añadiendo solo otra forma de inicio de sesión, sino un conjunto más estricto de protección de cuenta.

Qué incluye Advanced Account Security

OpenAI coloca esta opción en la sección Security de ChatGPT web, donde el usuario puede activarla.

Primero, el inicio de sesión se vuelve más fuerte.

Advanced Account Security requiere passkeys o llaves físicas de seguridad y desactiva el inicio de sesión con contraseña. El objetivo es que la autenticación resistente al phishing sea el valor por defecto para quienes más la necesitan.

Segundo, la recuperación de cuenta se vuelve más estricta.

La recuperación tradicional suele depender de correo o SMS. Si un atacante controla el correo o el número del usuario, puede usarlo para restablecer la cuenta. Para reducir este riesgo, Advanced Account Security desactiva la recuperación por email y SMS y usa métodos más fuertes, como passkeys de respaldo, llaves de seguridad y claves de recuperación.

Hay una contrapartida importante: después de activar la función, recuperar la cuenta depende mucho más de que el usuario guarde bien esos métodos. OpenAI indica explícitamente que, si los usuarios inscritos pierden sus métodos de recuperación, OpenAI Support no podrá recuperar la cuenta.

Tercero, las sesiones son más cortas y más fáciles de gestionar.

OpenAI reduce la duración de las sesiones para acortar la ventana de exposición si un dispositivo o sesión activa se ve comprometido. El usuario recibe alertas de inicio de sesión y puede revisar y gestionar sesiones activas en sus dispositivos.

Cuarto, la exclusión de entrenamiento se activa automáticamente.

Para quienes manejan información sensible, impedir que las conversaciones se usen para entrenar modelos es una opción de privacidad importante. Al activar Advanced Account Security, las conversaciones de esas cuentas no se usarán para entrenar modelos de OpenAI.

Colaboración con Yubico

OpenAI también anunció una colaboración con Yubico para ofrecer un paquete personalizado de llaves de seguridad.

Incluye:

YubiKey C Nano: pensada para quedarse conectada al portátil y reducir fricción diaria;
YubiKey C NFC: pensada como respaldo y para uso entre portátiles y móviles.

OpenAI dice que también se pueden usar otras llaves físicas compatibles con FIDO o passkeys de software. La función no depende de un hardware concreto, sino de métodos resistentes al phishing.

Trusted Access for Cyber tendrá que activarlo

OpenAI también indica que los miembros individuales de Trusted Access for Cyber que acceden a modelos de ciberseguridad más capaces y permisivos deberán activar Advanced Account Security desde el 1 de junio de 2026.

Las organizaciones pueden cumplir de otra forma: certificando que su flujo de SSO ya usa autenticación resistente al phishing.

La lógica es clara. Cuanto más potente es la capacidad del modelo, más fuerte debe ser la protección de cuenta, sobre todo en investigación de seguridad, análisis de vulnerabilidades y red teaming.

Quién debería considerarlo

No es una función necesaria para todo el mundo.

Si usas ChatGPT solo para conversaciones comunes y no quieres gestionar recuperación estricta, puede tener sentido esperar.

Pero estos usuarios deberían considerarla en serio:

personas que manejan materiales sensibles en ChatGPT;
usuarios de Codex con repositorios privados;
periodistas, profesionales públicos, investigadores, ejecutivos y otros usuarios de alto riesgo;
profesionales de ciberseguridad;
personas cómodas con passkeys o llaves físicas;
usuarios preocupados por phishing, SIM swapping o toma de control del correo.

Antes de activarla, conviene preparar passkeys de respaldo, llaves de seguridad y claves de recuperación, y guardarlas de forma segura.

Qué significa para productos de IA

Advanced Account Security no es una mejora del modelo, pero muestra que los productos de IA están entrando en usos de mayor riesgo.

Cuando ChatGPT y Codex cargan flujos de trabajo, código, documentos, conectores empresariales y contexto de largo plazo, la cuenta ya no es solo una entrada a un chat. Es la llave de un entorno de trabajo con IA.

Cuanto más se parecen estos productos a espacios personales de trabajo, más importantes se vuelven seguridad de cuenta, recuperación, sesiones y controles de datos de entrenamiento.

Conclusión

Advanced Account Security puede entenderse como un modo de alta seguridad para ChatGPT y Codex.

Reduce el riesgo de toma de cuenta mediante inicio de sesión más fuerte, recuperación más estricta, sesiones más cortas, alertas y exclusión automática de entrenamiento. La contrapartida es que el usuario debe cuidar mejor sus métodos de recuperación: después de activarlo ya no existe recuperación tradicional por correo o SMS, y OpenAI Support no sirve como respaldo.

Si ya usas ChatGPT o Codex para trabajo importante, especialmente con código privado, documentos sensibles o una identidad de alto riesgo, esta función merece atención.

Referencia:

Introducing Advanced Account Security - OpenAI

mattpocock/skills: una colecci贸n pr谩ctica de habilidades para agentes de codificaci贸n con IA

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills es una colección pública de habilidades de agentes de codificación IA de Matt Pocock.

No es una aplicación completa ni un nuevo cliente de chat. Es un conjunto de habilidades funcionales que pueden ser utilizadas por asistentes de codificación IA. La idea es práctica: desglosar problemas comunes de codificación de IA en pequeñas habilidades que un Agent puede llamar en la tarea adecuada, en lugar de depender de un solo prompt enorme cada vez.

Si a menudo utilizas Claude Code, Codex, Cursor o herramientas de codificación IA similares, vale la pena observar este tipo de colección de habilidades. Lo que realmente afecta la experiencia de codificación con IA a menudo no es si el modelo puede escribir código, sino si puede avanzar en la tarea según tu estilo de trabajo preferido.

false

Qué Problema Resuelve

Los asistentes de codificación de IA son potentes, pero pueden cometer errores fácilmente.

Las situaciones comunes incluyen:

Comenzar cambios de código sin entender el requisito
Modificar demasiados archivos a la vez
Producir mucha explicación pero poca acción útil
Intentar cosas a ciegas después de errores
No ejecutar pruebas o verificaciones a tiempo
Ignorar patrones de proyecto existentes
Introducir abstracciones innecesarias para terminar una tarea
Escribir código sin revisar realmente los riesgos después

Estos problemas no siempre son causados por una débil capacidad del modelo. A menudo, el flujo de trabajo no está lo suficientemente restringido.

El valor de mattpocock/skills es que transforma estos modos de fallo comunes en métodos operativos reutilizables, haciendo que el Agent se comporte más como un colaborador de ingeniería experimentado en diferentes escenarios.

false

¿Qué son los Skills

En el contexto de AI Agent, un skill se puede entender como una instrucción de tarea reutilizable, un método de trabajo o un flujo de trabajo profesional.

No tiene por qué ser un código plugin, y no siempre necesita llamar a un servicio externo. En muchos casos, un skill es simplemente un conjunto claro de reglas:

Cuándo usarlo
Qué hacer primero
Qué no hacer
Qué salida se requiere
Cómo juzgar la finalización de la tarea

Esto es algo parecido a una normal prompt template, pero la granularidad está más cerca de una capacidad de tarea.

Las normal prompt templates suelen copiarse y pegarse manualmente por el usuario. Los skills son mejores como parte de una toolbox de agente, lo que permite al Agent elegir el flujo de trabajo correcto para la tarea.

false

Por qué es importante la pequeñez y la componibilidad

El README enfatiza que estas habilidades son pequeñas y componibles.

Esta dirección es importante.

Si una habilidad intenta manejarlo todo, rápidamente se convierte en un nuevo prompt gigante: largo, vago y difícil de mantener. La ventaja de las habilidades pequeñas son los límites claros.

Por ejemplo, una habilidad puede centrarse en:

Planificar primero
Arreglar errores de TypeScript
Ejecutar pruebas y corregir basándose en los resultados
Realizar revisión de código (code review)
Resumir convenciones del proyecto
Mejorar prompts
Eliminar abstracciones innecesarias

Estas habilidades se pueden combinar según la tarea. Una tarea simple puede necesitar solo una habilidad, mientras que una tarea compleja puede encadenar varias.

Esto se acerca más al trabajo de ingeniería real. No utilizas el mismo flujo de trabajo (workflow) para cada problema; eliges las herramientas según la situación.

false

Manteniendo al Ingeniero en Control

Una dirección importante de este repositorio es mantener al ingeniero en control.

La codificación con IA puede derivarse fácilmente en dos extremos.

El primero es completamente manual. La IA solo ayuda a escribir unas pocas líneas de código, mientras que todo el contexto, la planificación y la verificación todavía dependen de ti.

El segundo es completamente automatizado (hands-off). Tú envías una tarea a un Agent, lo dejas cambiar muchas cosas, y luego te enfrentas a un diff que es difícil de revisar.

Las habilidades ayudan a encontrar una posición intermedia más estable.

Permiten que la IA asuma más flujo de trabajo repetitivo, mientras la sigue limitando con reglas:

Entender la tarea antes de actuar
Leer los archivos relevantes antes de editar
Mantener el alcance de la modificación controlado
Informar sobre la incertidumbre
Verificar después de los cambios
No refactorizar código no relacionado solo para demostrar

Esto no debilita a la IA. Hace que las acciones de la IA sean más fáciles de revisar y asumir para los humanos.

false

Problemas de Alineación

El primer tipo de fallo de codificación de IA suele ser un fallo de alineación.

El usuario quiere un cambio muy específico, pero el Agent puede entenderlo como una refactorización más amplia. El usuario solo quiere que se arregle un bug, pero cambia estilos en el proceso. El usuario quiere que se siga la arquitectura existente, pero introduce un patrón nuevo.

Las habilidades pueden ayudar al Agent a hacer varias cosas al comienzo de una tarea:

Restatear el objetivo
Identificar el alcance del impacto
Reconocer los patrones de implementación existentes
Proporcionar un plan
Aclarar lo que no se hará

Este paso es como una autocomprobación del ingeniero antes de comenzar el trabajo.

Si el Agent no puede declarar claramente los límites de la tarea y comienza a escribir código directamente, es fácil que la tarea se desvíe.

false

Problemas del Bucle de Retroalimentación

La IA no debe escribir código únicamente mediante la generación one-shot.

En el desarrollo real, los bucles de retroalimentación son importantes:

Cambiar una pequeña parte
Ejecutar pruebas o type checks
Leer los errores
Corregirlos
Verificar de nuevo

Muchos Agents fallan porque omiten la retroalimentación intermedia. Cambian muchas cosas a la vez y luego resumen por intuición que “it should work”.

Las Skills pueden hacer explícito el bucle de retroalimentación. Por ejemplo, pueden exigir al Agent que:

Ejecute comprobaciones relevantes después de la modificación
Lea los mensajes de error primero si las comprobaciones fallan
Evite cambiar ciegamente archivos no relacionados
Verifique de nuevo después de cada ronda de correcciones
Informe los resultados finales de la verificación

Esto hace que la codificación con IA se parezca más al depurado (debugging) real y menos a la escritura one-shot.

false

Problemas de Control de Arquitectura

AI es bueno generando abstracciones, y también bueno sobregenerando abstracciones.

Para completar un requisito pequeño, puede crear una capa de servicio (service layer), funciones auxiliares (helper functions), objetos de configuración, type wrappers y adaptadores, haciendo que el código sea mucho más complejo que el requisito en sí.

Esto es especialmente peligroso en proyectos grandes. Las abstracciones generadas por AI a menudo parecen profesionales, pero pueden no coincidir con el estilo del proyecto existente y pueden aumentar el costo de mantenimiento.

Las buenas habilidades recuerdan al Agent que:

Preferir patrones existentes
Evitar nuevas abstracciones innecesarias
Evitar la refactorización de áreas no relacionadas
Ajustar el cambio al tamaño de la tarea
Comprender el código antes de diseñar la estructura

Esto reduce la producción que parece ingenierizada pero que en realidad es más difícil de mantener.

false

Por qué son importantes las habilidades de revisión

Escribir código y revisar código son estados diferentes.

Cuando un Agent escribe código, generalmente tiende a demostrar que su implementación funciona. Puede explicar por qué el cambio debería funcionar, pero no siempre busca activamente riesgos.

El propósito de una habilidad de revisión es cambiar el rol del Agent:

Encontrar posibles errores (bugs)
Encontrar regresiones de comportamiento
Encontrar pruebas faltantes
Encontrar casos límite (edge cases)
Encontrar mayor complejidad
Encontrar inconsistencias con las convenciones existentes

Esto es importante para la programación con IA porque la IA genera código rápidamente. Sin revisión, los usuarios pueden sentirse fácilmente abrumados por grandes diffs.

Una buena salida de revisión debe listar los problemas primero, no alabar la implementación primero. Debe ayudar al ingeniero a decidir si el cambio se puede fusionar (merged).

false

Diferencia con los archivos de reglas normales

Muchas herramientas de codificación de IA admiten reglas, instrucciones o memoria.

Estos archivos generalmente registran reglas a largo plazo, como:

Stack tecnológico del proyecto
Convenciones de nomenclatura
Comandos de prueba
Directorios que no deben modificarse
Preferencias de estilo de respuesta

Las habilidades (Skills) se centran más en el flujo de trabajo de la tarea.

Las reglas le dicen al Agent “cómo comportarse a largo plazo”, mientras que las habilidades le dicen al Agent “cómo ejecutar este tipo de tarea”.

Ambos funcionan mejor juntos.

Por ejemplo, las reglas pueden indicar que el proyecto usa pnpm test, mientras que una habilidad de revisión requiere verificar la cobertura de pruebas después de los cambios. Entonces el Agent sabe no solo el comando, sino también cuándo usarlo.

false

Escenarios Adecuados

Los repositorios como mattpocock/skills son adecuados para:

Uso frecuente de AI coding tools
Agents que trabajan en codebases reales
Reducir ediciones de AI fuera de alcance
Hacer que el Agent verifique los resultados de forma más activa
Convertir tus hábitos de ingeniería en skills
Aprender cómo otros diseñan workflows de agentes
Convertir prompts temporales en una colección de skills mantenible

Si solo pides ocasionalmente a AI que escriba una función pequeña, quizás no necesites mantener skills.

Pero si ya tratas a AI como un socio de desarrollo a largo plazo, las skills se vuelven cada vez más importantes. Son como un método de trabajo reutilizable para el Agent.

false

Cómo aprender de este repositorio

Incluso si no utilizas cada habilidad directamente, puedes aprender varias cosas de este repositorio.

Primero, anota los modos de fallo.

No solo te quejes cuando la AI comete un error. Convierte los patrones que a menudo se equivoca en reglas, para que una habilidad pueda evitarlos la próxima vez.

Segundo, mantén las habilidades cortas.

Una habilidad debe resolver un problema claro. Cuanto más corta sea, más fácil será llamarla correctamente y mantenerla.

Tercero, haz que el formato de salida sea claro.

Si quieres que el Agent enumere un plan primero, ejecute después y resuma los resultados de verificación al final, escribe esa estructura claramente. Los requisitos vagos suelen producir resultados vagos.

Cuarto, conserva puntos de traspaso humano.

Una buena habilidad no debe permitir que la AI funcione sola durante demasiado tiempo. Cuando haya incertidumbre, un alcance de impacto expandido, pruebas fallidas o una decisión de producto, debe detenerse y explicar la situación.

false

Notas de uso

Primero, no conviertas todo en habilidades (skills).

Demasiadas habilidades hacen que el sistema sea complejo, y el Agent podría no saber cuál elegir. Empieza con los escenarios más frecuentes y más problemáticos.

Segundo, las habilidades necesitan iteración.

La primera versión de una habilidad puede no ser buena. Observa cómo la IA la ejecuta realmente, luego elimina, añade y reescribe gradualmente.

Tercero, no permitas que las habilidades reemplacen el juicio de la ingeniería.

Las habilidades pueden mejorar el flujo de trabajo, pero no pueden garantizar una implementación correcta. Las pruebas (tests), la revisión, las comprobaciones de compilación (build checks) y el juicio humano siguen siendo importantes.

Cuarto, presta atención a las diferencias entre los Agents.

Claude Code, Codex, Cursor y Copilot soportan las instrucciones, las habilidades y las reglas de manera diferente. La misma idea se puede reutilizar, pero el formato específico debe ajustarse para cada herramienta.

false

Referencia

mattpocock/skills

false

Pensamiento Final

Lo que hace que mattpocock/skills merezca la pena es no un único prompt mágico dentro de él, sino la idea práctica de codificación con IA que demuestra: dividir la experiencia de ingeniería en pequeñas habilidades y luego permitir que el Agent las combine según el escenario.

A medida que la codificación con IA pasa de ser una asistencia ocasional a formar parte del flujo de trabajo diario, las habilidades se convierten en herramientas importantes para limitar a los Agents, mantener a los ingenieros en control y mejorar la calidad de la retroalimentación. false

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

OpenAI lanza GPT-5.5: codificaci贸n ag茅ntica, trabajo de conocimiento e investigaci贸n m谩s fuertes

Fri, 24 Apr 2026 08:39:56 +0800

OpenAI publicó Introducing GPT-5.5 el 23 de abril de 2026. A juzgar por la página oficial, este lanzamiento no se trata solo de hacer que el modelo sea “más inteligente”; se trata más de si el modelo puede seguir ejecutando tareas complejas.

OpenAI posiciona GPT-5.5 como un modelo más adecuado para el trabajo real. Se espera que no solo responda preguntas, sino que también escriba código, depure, investigue en línea, analice datos, cree documentos y hojas de cálculo, opere software y se mueva entre herramientas hasta que la tarea esté terminada.

false

1. Dónde es más fuerte GPT-5.5

La página de lanzamiento destaca repetidamente cuatro áreas:

Codificación agentica
Uso de la computadora y uso de herramientas
Trabajo de conocimiento
Asistencia en investigación científica temprana

En otras palabras, GPT-5.5 está dirigido menos a preguntas y respuestas cortas y más a tareas de larga duración. Por ejemplo, un problema de ingeniería no es solo “¿cómo debe cambiarse este código?”; el modelo necesita entender la estructura del proyecto, localizar la causa de la falla, editar archivos relacionados, añadir pruebas, verificar resultados y reducir la solicitud de prompting repetida por parte del usuario.

OpenAI también enfatiza que GPT-5.5 utiliza menos tokens en tareas de Codex. Esto es importante en la práctica porque los agentes de codificación pueden consumir tokens rápidamente una vez que comienzan a leer archivos, ejecutar comandos y arreglar bugs. Si un modelo puede completar la misma tarea en menos pasos, tanto el costo como el tiempo de espera disminuyen.

false

2. La codificación es el principal escaparate

OpenAI llama a GPT-5.5 su modelo de codificación agentico más potente hasta la fecha.

Los números públicos más destacados incluyen:

Terminal-Bench 2.0: GPT-5.5 alcanza el 82.7%
SWE-Bench Pro: GPT-5.5 alcanza el 58.6%
Expert-SWE interno de OpenAI: GPT-5.5 también obtiene una puntuación más alta que GPT-5.4

Estas evaluaciones tienen algo en común: están más cerca de flujos de trabajo de ingeniería reales que de preguntas de algoritmo aisladas. Terminal-Bench, en particular, implica operaciones de línea de comandos, planificación, prueba y error, coordinación de herramientas y verificación de múltiples pasos.

Para los desarrolladores cotidianos, la implicación es directa: si un modelo puede asumir tareas más grandes depende de si puede mantener el contexto durante mucho tiempo, verificar sus propias suposiciones, saber cuándo ejecutar pruebas y entender qué más puede afectar un cambio.

El valor de GPT-5.5 en Codex también se manifiesta principalmente en estos comportamientos. Se siente más como un colaborador que puede asumir parte de una tarea de ingeniería, en lugar de una herramienta que solo completa fragmentos de código.

false

3. El Trabajo del Conocimiento se Convierte en un Escenario Central

Más allá de la codificación, OpenAI está integrando GPT-5.5 en un contexto de trabajo de oficina más amplio.

El anuncio dice que GPT-5.5 puede generar documentos, hojas de cálculo (spreadsheets) y presentaciones (slide decks) mejor en Codex, y también es más adecuado para la investigación operativa, el modelado de hojas de cálculo y la organización de materiales de negocio. Combinado con el uso de la computadora, su objetivo no es simplemente ofrecer sugerencias, sino participar en el flujo de trabajo completo de encontrar información, comprender el contenido, usar herramientas, revisar la salida y convertir materia prima en un resultado.

La página también señala que OpenAI ya utiliza Codex en muchos departamentos internos, incluyendo ingeniería de software, finanzas, comunicaciones, marketing, data science y product management. Lo interesante no es ningún ejemplo en particular, sino la dirección: OpenAI está expandiendo Codex de una herramienta para desarrolladores a una herramienta de trabajo más general.

En ChatGPT, GPT-5.5 Thinking está disponible para usuarios Plus, Pro, Business y Enterprise; GPT-5.5 Pro está dirigido a preguntas más difíciles y trabajo de mayor precisión, y está disponible para usuarios Pro, Business y Enterprise.

false

4. La Capacidad de Investigación es Más que Respuestas Mejores

GPT-5.5 también recibe una fuerte presentación enfocada en la investigación.

OpenAI afirma que ha mejorado en genética, biología cuantitativa, bioinformática, prueba matemática y áreas relacionadas. La clave no es si el modelo puede recordar un hecho, sino si puede manejar problemas de investigación más realistas: leer datos, detectar anomalías, proponer análisis, interpretar resultados y continuar basándose en hallazgos intermedios.

La página de lanzamiento menciona GeneBench y BixBench, ambos centrados más en el análisis científico multifase. OpenAI también dice que una versión interna de GPT-5.5, con un harness personalizado, ayudó a descubrir una nueva prueba relacionada con los números de Ramsey y la verificó con Lean.

Estos ejemplos no deben simplificarse a “la IA ahora puede hacer investigación de forma independiente”. Pero sí sugieren que los modelos están pasando de ser motores de respuesta a ser colaboradores en la investigación. En escenarios donde se mezclan código, datos, artículos, ideas de experimentos y notas, el razonamiento de horizonte largo y el uso de herramientas de GPT-5.5 se vuelven especialmente importantes.

false

5. Eficiencia de Inferencia: Más Potente Sin Volverse Mucho Más Lento

Un punto fácilmente pasado por alto es que OpenAI afirma que GPT-5.5 iguala a GPT-5.4 en la latencia por token en el mundo real.

Normalmente, los modelos más grandes y más capaces tienen una latencia más alta. Esta vez, OpenAI enfatiza que la optimización del sistema de inferencia ayudó a GPT-5.5 a volverse más capaz mientras mantenía la velocidad estable. La página de lanzamiento también menciona que Codex analizó patrones de tráfico de producción y escribió algoritmos heurísticos de balanceo de carga, aumentando la velocidad de generación de tokens en más de 20%.

Ese detalle es interesante: el modelo no solo es atendido por la infraestructura, sino que también ayuda a mejorar la infraestructura que lo sirve.

false

6. La seguridad se vuelve más estricta, especialmente en ciberseguridad

Dado que GPT-5.5 tiene capacidades de ciberseguridad más sólidas, OpenAI también está reforzando los controles de seguridad.

El anuncio indica que GPT-5.5 mejora respecto a GPT-5.4 en capacidad de ciberseguridad, por lo que OpenAI está implementando clasificadores más estrictos, especialmente para actividades de alto riesgo, solicitudes sensibles de ciberseguridad y uso indebido repetido.

Esto significa que algunos usuarios pueden experimentar más rechazos o fricción al trabajar en tareas relacionadas con la ciberseguridad. OpenAI también ofrece Trusted Access for Cyber, diseñado para reducir barreras innecesarias para usuarios defensivos verificados.

Para los desarrolladores comunes, la conclusión simple es: el refuerzo legítimo de la seguridad (security hardening), la corrección de vulnerabilidades y la auditoría de código deben seguir siendo compatibles, mientras que los flujos de trabajo de ataque de alto riesgo estarán más controlados.

false

7. Disponibilidad y Precios de la API

Según la página de lanzamiento de OpenAI, la disponibilidad de GPT-5.5 es la siguiente:

ChatGPT: GPT-5.5 Thinking para usuarios Plus, Pro, Business y Enterprise
ChatGPT: GPT-5.5 Pro para usuarios Pro, Business y Enterprise
Codex: GPT-5.5 para planes Plus, Pro, Business, Enterprise, Edu y Go
Codex: ventana de contexto de 400K
Codex Modo Fast: velocidad de generación de tokens de aproximadamente 1.5x a un coste de 2.5x

Para la API, OpenAI dice que gpt-5.5 y gpt-5.5-pro estarán disponibles pronto.

Los precios de la API anunciados son:

gpt-5.5: US$5 / 1M tokens de entrada y US$30 / 1M tokens de salida
gpt-5.5-pro: US$30 / 1M tokens de entrada y US$180 / 1M tokens de salida
Ventana de contexto API de gpt-5.5: 1M
Batch y Flex tienen la mitad del precio estándar de la API
El procesamiento prioritario es 2.5x el precio estándar

Esto es claramente más caro que muchos modelos cotidianos, por lo que es más adecuado para tareas de alto valor: cambios de ingeniería complejos, análisis de documentos largos, automatización de oficinas, asistencia de investigación y flujos de trabajo empresariales importantes, en lugar de conversaciones casuales.

false

8. Cómo leer este lanzamiento

En una frase, GPT-5.5 trata sobre cómo OpenAI impulsa los modelos más allá de “responder preguntas” hacia “realizar trabajo”.

La parte más importante no son solo las puntuaciones de referencia (benchmark scores) más altas, sino la convergencia de varias capacidades:

Mejor persistencia en tareas largas
Uso de herramientas más confiable
Comprensión de contexto de ingeniería más sólida
Mejor adaptación a documentos, hojas de cálculo, investigación y flujos de trabajo empresariales
Contexto más largo y mayor eficiencia de tokens
Controles más estrictos en capacidades de alto riesgo

Para los desarrolladores, lo más interesante de probar es trabajo de ingeniería complejo en Codex. Para los usuarios empresariales (enterprise users), la pregunta más grande es si puede convertir trabajo inter-herramental, inter-documental e inter-proceso en resultados entregables.

GPT-5.5 no es una pequeña actualización dirigida solo a la experiencia de chat. Parece más bien otro paso en el avance de OpenAI hacia la IA como una capa de ejecución para el trabajo.

false

Enlaces Relacionados

Presentando GPT-5.5 - OpenAI false

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.

Cómo funcionan los límites de uso de Codex: límites de 5 horas, límites semanales y créditos

Wed, 15 Apr 2026 22:50:00 +0800

Cuando la gente mira por primera vez los límites de uso de Codex, es fácil asumir que el 5-hour limit es un saldo de corto plazo y que el weekly limit solo empieza a bajar cuando se agota la cuota de 5 horas.

No funciona así. Codex se entiende mejor como un sistema que revisa varias ventanas de límite al mismo tiempo: una ventana corta evita el uso en ráfaga, mientras la ventana semanal controla el uso total de la semana. Una solicitud de Codex normalmente cuenta contra ambas.

Así que esta situación suele ser normal:

1
2

5-hour quota still has plenty left
but weekly quota has already decreased

01 Versión corta

Puedes entender el uso de Codex con tres reglas:

El 5-hour limit y el weekly limit se aplican al mismo tiempo.
Si se agota el límite semanal, normalmente no puedes seguir usando el mismo pool de cuota de suscripción aunque la cuota de 5 horas aún tenga margen.
Codex no se cobra por simple número de mensajes. El uso depende del modelo, tokens, complejidad de tarea, tamaño de contexto y ubicación de ejecución.

En pseudocódigo:

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && no other product policy is triggered

Cuando se reinicia la ventana de 5 horas, solo se restaura esa cuota. No restaura la cuota semanal. La cuota semanal se reinicia según su propio calendario, o puede que puedas comprar créditos extra en planes compatibles.

02 Por qué bajan ambas ventanas

Piensa en los límites de Codex como dos puertas:

Window	Purpose
5-hour window	Prevents high-frequency burst usage
Weekly window	Controls total weekly usage

Cada tarea de Codex crea uso real. Ese uso se refleja en las ventanas de rate limit relevantes.

No es:

1
2
3

Use 5-hour quota first
After the 5-hour quota runs out
Start using weekly quota

Se parece más a:

1
2
3

One Codex request
=> counts toward the 5-hour window
=> also counts toward the weekly window

Por eso el uso semanal puede bajar aunque la cuota de 5 horas no esté agotada.

03 Mira los créditos basados en tokens

OpenAI no publica una fórmula que permita a los usuarios reproducir exactamente el cargo de Codex. Lo público es la rate card, los factores principales y el precio de créditos por modelo.

A fecha de 2026-04-15, el modelo principal de la rate card de Codex es token-based credits. El uso se estima a partir de tokens de entrada, tokens de entrada cacheados y tokens de salida.

Ejemplos de tarifas oficiales:

Model	Input / 1M tokens	Cached input / 1M tokens	Output / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

Una estimación aproximada es:

usage
~= input tokens / 1,000,000 * model input price
+ cached input tokens / 1,000,000 * model cached input price
+ output tokens / 1,000,000 * model output price

No es una fórmula exacta de facturación, pero explica la tendencia: la salida es cara, el contexto largo es caro y los modelos más potentes cuestan más. La rate card oficial también dice que Fast mode usa 2x créditos y que Code review usa precios de GPT-5.3-Codex.

04 No cuentes solo mensajes

Diez mensajes de Codex pueden consumir cantidades muy distintas.

Las tareas ligeras suelen ser más baratas:

Editar una función pequeña
Explicar un snippet corto
Escribir un párrafo breve
Hacer un cambio local en un archivo claramente especificado

Las tareas pesadas cuestan más:

Escanear una codebase grande
Ejecutar una sesión larga de agente
Bucles repetidos de leer, editar, probar y corregir
Generar mucho código o un informe largo
Usar tareas cloud
Activar fast mode

Así que el número de mensajes solo da una impresión aproximada. No refleja el uso real.

05 Tareas locales frente a tareas cloud

La ubicación de ejecución puede marcar una gran diferencia.

Una local task trabaja en tu workspace local: lee archivos, edita código y ejecuta comandos. Una cloud task se delega a un entorno cloud alojado, mejor para flujos más largos y automatizados.

Las tareas cloud suelen ser más caras porque implican:

Un entorno de ejecución alojado
Tareas más largas
Más llamadas a herramientas
Contexto más grande
Un bucle de automatización más completo

Para ediciones normales de código, limpieza de artículos o correcciones pequeñas, las tareas locales suelen ser más baratas. Usa tareas cloud cuando el trabajo realmente necesite ejecución alojada.

06 Por qué el uso semanal baja rápido

Si tu cuota de 5 horas apenas se mueve pero el uso semanal baja mucho, causas comunes incluyen:

Usaste tareas cloud.
Usaste un modelo más caro.
Activaste fast mode.
El contexto era grande, con muchos archivos o una conversación larga.
La salida fue larga, como mucho código, un informe extenso o análisis de logs.
La cadena de tareas fue larga: buscar, editar, probar, corregir y probar otra vez.
Tu script de cuota etiquetó mal las ventanas de límite.

Si lees campos desde algo como /backend-api/wham/usage, no confíes solo en etiquetas procesadas como five_hour% o weekly%. Revisa los campos raw JSON:

limit_window_seconds
percent_left
reset_at
bucket / feature name

Ventanas típicas:

limit_window_seconds = 18000
=> about 5 hours

limit_window_seconds = 604800
=> about 7 days

Si tu script etiqueta las ventanas al revés, la visualización de cuota será engañosa.

07 Cómo ahorrar cuota

Para hacer que la cuota semanal dure más:

Divide trabajos grandes en tareas más pequeñas.
Prefiere tareas locales cuando sea posible.
Indica a Codex las rutas relevantes para reducir escaneo innecesario.
Evita volcar logs enormes, archivos largos o contexto no relacionado.
Usa modelos mini más baratos para trabajo ligero.
Pide un plan antes de empezar una tarea larga.
Pide respuestas concisas cuando no necesites un informe largo.

Un modelo mental útil:

can continue using
= short window has quota
&& weekly window has quota

usage speed
= model price
* tokens
* output length
* task complexity
* execution location

No es matemática exacta de facturación, pero explica la mayoría del comportamiento de límites de uso de Codex.

Enlaces relacionados

Comprobar uso y cuota de Codex

Sun, 12 Apr 2026 00:01:33 +0800

Si quieres comprobar la cuota restante de una cuenta de Codex, un pequeño script local puede llamar directamente al endpoint /backend-api/wham/usage de ChatGPT.

El flujo general es simple:

Leer tokens.access_token y tokens.account_id desde auth.json
Enviar una solicitud a https://chatgpt.com/backend-api/wham/usage
Incluir Authorization: Bearer ... y ChatGPT-Account-Id en los headers
Analizar las ventanas de cuota de cinco horas y semanal en la respuesta

Para qué sirve

Este enfoque es útil cuando quieres confirmar rápidamente:

cuánta cuota de cinco horas queda
cuánta cuota semanal queda
cuándo se reinicia la cuota

Si gestionas varias cuentas, el script también puede escanear account/*.auth.json e imprimir una tabla compacta de resumen. El archivo auth.json de la cuenta de ChatGPT con sesión iniciada suele encontrarse en ~/.codex/.

Entradas clave

En la práctica, el script depende principalmente de dos valores:

access_token
account_id

Ambos suelen estar disponibles en un auth.json local. Con ellos, los headers de la solicitud suelen tener este aspecto:

headers = {
    "Authorization": f"Bearer {auth_token}",
    "Accept": "application/json",
    "ChatGPT-Account-Id": auth_account_id,
    "Origin": "https://chatgpt.com",
    "Referer": "https://chatgpt.com/",
    "User-Agent": "Mozilla/5.0",
}

Cómo leer la respuesta

Cuando la solicitud funciona, las entradas más importantes son las dos ventanas de cuota:

five_hour
weekly

Un script práctico suele normalizarlas en:

porcentaje restante
hora de reinicio
duración de la ventana

También conviene admitir nombres alternativos de campos como primary_window, secondary_window, five_hour_limit y weekly_limit.

Problemas comunes

Una respuesta 401 normalmente significa que el access_token ha expirado o no es válido.

Una respuesta 403 normalmente significa que la cuenta no puede acceder a este endpoint, o que la cuenta está en un estado anómalo.

Si la respuesta usa nombres de campos inconsistentes, es mejor normalizarlos antes de imprimir el resumen.

Referencia

codex-auth-manager: https://github.com/RioArisk/codex-auth-manager

Código

import argparse
import base64
import json
import os
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path
from typing import Any

import requests


UTC = timezone.utc
CST = timezone(timedelta(hours=8), name="CST")
JSONDict = dict[str, Any]


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Query ChatGPT Codex usage from /backend-api/wham/usage."
    )
    parser.add_argument(
        "account_name",
        nargs="?",
        help="Account name used to load account/<account_name>.auth.json. If omitted, load all *.auth.json files in account/.",
    )
    parser.add_argument(
        "--account-dir",
        default="account",
        help="Directory containing <account_name>.auth.json files.",
    )
    parser.add_argument(
        "--chatgpt-url",
        default="https://chatgpt.com/backend-api/wham/usage",
        help="ChatGPT usage endpoint.",
    )
    parser.add_argument(
        "--raw-json",
        action="store_true",
        help="Print the full JSON response body.",
    )
    parser.add_argument(
        "--raw-headers",
        action="store_true",
        help="Print response headers.",
    )
    return parser.parse_args()


def print_json(data: Any) -> None:
    print(json.dumps(data, indent=2, ensure_ascii=False))


def load_auth_json(path_str: str | Path | None) -> JSONDict | None:
    if not path_str:
        return None
    path = Path(path_str).expanduser()
    if not path.is_file():
        return None
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError):
        return None


def get_nested_string(data: JSONDict | None, *keys: str) -> str | None:
    current: Any = data
    for key in keys:
        if not isinstance(current, dict):
            return None
        current = current.get(key)
    return current if isinstance(current, str) and current else None


def format_dt(dt: datetime | None) -> str:
    if dt is None:
        return "-"
    return dt.astimezone(CST).strftime("%Y-%m-%d %H:%M:%S %Z")


def format_cst(dt: datetime | None) -> str:
    return format_dt(dt)


def epoch_ms_to_dt(value: Any) -> datetime | None:
    if value is None:
        return None
    try:
        raw = int(value)
    except (TypeError, ValueError):
        return None
    # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds.
    timestamp = raw / 1000 if raw > 10**11 else raw
    return datetime.fromtimestamp(timestamp, tz=UTC)


def first_dict(data: Any, *keys: str) -> JSONDict | None:
    for key in keys:
        value = data.get(key) if isinstance(data, dict) else None
        if isinstance(value, dict):
            return value
    return None


def decode_jwt_exp(token: str) -> datetime | None:
    parts = token.split(".")
    if len(parts) != 3:
        return None
    try:
        payload = parts[1]
        payload += "=" * (-len(payload) % 4)
        data = json.loads(base64.urlsafe_b64decode(payload.encode("ascii")))
        exp = data.get("exp")
        if exp is None:
            return None
        return datetime.fromtimestamp(int(exp), tz=UTC)
    except (ValueError, TypeError, json.JSONDecodeError):
        return None


def get_percent_left(value: JSONDict) -> float | int | None:
    percent_left = value.get("percent_left")
    if percent_left is None:
        percent_left = value.get("remaining_percent")
    if percent_left is not None:
        return percent_left

    used_percent = value.get("used_percent")
    try:
        if used_percent is not None:
            return max(0, 100 - float(used_percent))
    except (TypeError, ValueError):
        return None
    return None


def resolve_limit_window(value: JSONDict) -> JSONDict:
    if (
        "reset_at" not in value
        and "reset_time_ms" not in value
        and isinstance(value.get("primary_window"), dict)
    ):
        return value["primary_window"]
    return value


def parse_limit_entry(name: str, value: Any) -> JSONDict | None:
    if not isinstance(value, dict):
        return None

    value = resolve_limit_window(value)

    percent_left = get_percent_left(value)
    reset_time_ms = value.get("reset_time_ms")
    if reset_time_ms is None:
        reset_time_ms = value.get("reset_at")

    window_seconds = value.get("limit_window_seconds")

    return {
        "name": name,
        "percent_left": percent_left,
        "reset_time_ms": reset_time_ms,
        "reset_at": epoch_ms_to_dt(reset_time_ms),
        "limit_window_seconds": window_seconds,
    }


def infer_limit_name(window_seconds: Any) -> str | None:
    if not isinstance(window_seconds, (int, float)):
        return None
    if window_seconds <= 6 * 3600:
        return "five_hour"
    if window_seconds >= 6 * 24 * 3600:
        return "weekly"
    return None


def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -> tuple[JSONDict | None, JSONDict | None]:
    for entry in (primary, secondary):
        if not entry:
            continue
        inferred_name = infer_limit_name(entry.get("limit_window_seconds"))
        if inferred_name:
            entry["name"] = inferred_name

    if primary and secondary and primary.get("name") == secondary.get("name"):
        if primary.get("name") == "weekly":
            primary["name"] = "five_hour"
        else:
            secondary["name"] = "weekly"

    if primary and primary.get("name") == "weekly" and secondary is None:
        return None, primary

    if secondary and secondary.get("name") == "five_hour" and primary is None:
        return secondary, None

    return primary, secondary


def parse_rate_limits(data: JSONDict) -> tuple[JSONDict | None, JSONDict | None]:
    primary = None
    secondary = None

    for primary_key in ("five_hour", "five_hour_limit", "five_hour_rate_limit", "primary"):
        if primary_key in data:
            primary = parse_limit_entry("five_hour", data.get(primary_key))
            if primary:
                break

    for secondary_key in ("weekly", "weekly_limit", "weekly_rate_limit", "secondary"):
        if secondary_key in data:
            secondary = parse_limit_entry("weekly", data.get(secondary_key))
            if secondary:
                break

    if primary is None:
        primary = parse_limit_entry("five_hour", data.get("primary_window"))
    if secondary is None:
        secondary = parse_limit_entry("weekly", data.get("secondary_window"))

    return relabel_rate_limits(primary, secondary)


def format_percent(value: Any) -> str:
    return f"{value:g}" if isinstance(value, (int, float)) else str(value if value is not None else "-")


def percent_sort_value(value: Any, descending: bool) -> tuple[int, float]:
    if isinstance(value, (int, float)):
        numeric_value = float(value)
        return (0, -numeric_value if descending else numeric_value)
    return (1, 0.0)


def get_auth_paths(account_dir: str, account_name: str | None) -> list[Path]:
    base_dir = Path(account_dir)
    if account_name:
        return [base_dir / f"{account_name}.auth.json"]
    return sorted(base_dir.glob("*.auth.json"))


def get_account_name_from_path(path: Path) -> str:
    suffix = ".auth.json"
    return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem


def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -> JSONDict:
    return {
        "account": account_name,
        "five_hour_percent": five_hour["percent_left"] if five_hour else None,
        "weekly_percent": weekly["percent_left"] if weekly else None,
        "weekly_reset_at": weekly["reset_at"] if weekly else None,
    }


def print_summary_rows(rows: list[JSONDict]) -> None:
    if not rows:
        return

    sorted_rows = sorted(
        rows,
        key=lambda row: (
            percent_sort_value(row.get("five_hour_percent"), descending=True),
            percent_sort_value(row.get("weekly_percent"), descending=True),
            format_cst(row.get("weekly_reset_at")),
            row["account"],
        ),
    )

    display_rows = []
    for row in sorted_rows:
        display_rows.append(
            {
                "account": str(row["account"]),
                "five_hour": format_percent(row.get("five_hour_percent")),
                "weekly": format_percent(row.get("weekly_percent")),
                "weekly_reset": format_cst(row.get("weekly_reset_at")),
            }
        )

    headers = {
        "account": "account",
        "five_hour": "five_hour%",
        "weekly": "weekly%",
        "weekly_reset": "weekly_reset",
    }
    widths = {
        key: max(len(headers[key]), max(len(item[key]) for item in display_rows))
        for key in headers
    }

    print(
        f"{headers['account']:<{widths['account']}}  "
        f"{headers['five_hour']:>{widths['five_hour']}}  "
        f"{headers['weekly']:>{widths['weekly']}}  "
        f"{headers['weekly_reset']:<{widths['weekly_reset']}}"
    )
    for item in display_rows:
        print(
            f"{item['account']:<{widths['account']}}  "
            f"{item['five_hour']:>{widths['five_hour']}}  "
            f"{item['weekly']:>{widths['weekly']}}  "
            f"{item['weekly_reset']:<{widths['weekly_reset']}}"
        )


def validate_token_inputs(
    token: str,
    account_id: str,
    auth_token: str | None,
    auth_account_id: str | None,
) -> int | None:
    if token.startswith("sess-"):
        print("status: invalid_token_type", file=sys.stderr)
        print(
            "message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.",
            file=sys.stderr,
        )
        if auth_token:
            print(
                "hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.",
                file=sys.stderr,
            )
        return 1

    token_exp = decode_jwt_exp(token)
    if token_exp is not None and token_exp <= datetime.now(UTC):
        print("status: expired", file=sys.stderr)
        print(f"message: access_token expired at {format_dt(token_exp)}", file=sys.stderr)
        if auth_token and auth_token != token:
            auth_token_exp = decode_jwt_exp(auth_token)
            hint = format_dt(auth_token_exp) if auth_token_exp else "unknown time"
            print(f"hint: auth.json contains a different access_token expiring at {hint}", file=sys.stderr)
        return 1

    if auth_account_id and account_id != auth_account_id:
        print("warning: supplied --account-id does not match auth.json tokens.account_id", file=sys.stderr)

    return None


def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -> int | None:
    if response.status_code == 401:
        print("status: expired", file=sys.stderr)
        print("message: access_token expired or invalid", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code == 403:
        print("status: forbidden", file=sys.stderr)
        print("message: account has no access to this endpoint or is in an abnormal state", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code >= 400:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print_json(data)
        return 3

    return None


def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -> tuple[int, JSONDict | None]:
    auth_data = load_auth_json(auth_path)
    account_name = get_account_name_from_path(auth_path)
    auth_token = get_nested_string(auth_data, "tokens", "access_token")
    auth_account_id = get_nested_string(auth_data, "tokens", "account_id")

    if not auth_data:
        print(f"{account_name}: auth file not found or invalid", file=sys.stderr)
        return 1, None

    if not auth_token:
        print(f"{account_name}: missing access_token", file=sys.stderr)
        return 1, None

    if not auth_account_id:
        print(f"{account_name}: missing account_id", file=sys.stderr)
        return 1, None

    validation_error = validate_token_inputs(
        auth_token,
        auth_account_id,
        auth_token,
        auth_account_id,
    )
    if validation_error is not None:
        return validation_error, None

    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "ChatGPT-Account-Id": auth_account_id,
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
        "User-Agent": "Mozilla/5.0",
    }

    try:
        response = requests.get(args.chatgpt_url, headers=headers, timeout=60)
    except requests.RequestException as exc:
        print(f"Request failed: {exc}", file=sys.stderr)
        return 2, None

    if args.raw_headers:
        print("=== Headers ===")
        print_json(dict(response.headers))
        print()

    try:
        data = response.json()
    except ValueError:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print(response.text, file=sys.stderr)
        return 3, None

    error_response = handle_error_response(response, data, args.raw_json)
    if error_response is not None:
        return error_response, None

    if args.raw_json:
        print("=== Raw JSON ===")
        print_json(data)
        print()

    rate_limits = first_dict(data, "rate_limit", "rate_limits")

    if rate_limits is None:
        return 0, build_summary_row(account_name, None, None)

    five_hour, weekly = parse_rate_limits(rate_limits)
    return 0, build_summary_row(account_name, five_hour, weekly)


def main() -> None:
    args = parse_args()
    auth_paths = get_auth_paths(args.account_dir, args.account_name)
    if not auth_paths:
        print("No auth files found.", file=sys.stderr)
        sys.exit(1)

    exit_code = 0
    summary_rows: list[JSONDict] = []
    for auth_path in auth_paths:
        current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args)
        exit_code = max(exit_code, current_exit_code)
        if summary_row is not None and not args.raw_json:
            summary_rows.append(summary_row)

    if summary_rows:
        print_summary_rows(summary_rows)
    sys.exit(exit_code)


if __name__ == "__main__":
    main()

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.

Codex on KnightLi Blog

Scientific Agent Skills: una biblioteca de skills para dar flujos de investigación a AI Agents

Conclusión rápida

Qué incluye

Bases de datos y paquetes Python

Escenarios típicos

Instalación

Requisitos de ejecución

Diferencia frente a una colección de prompts

Seguridad y límites de confianza

Para quién es

Consejos de uso

Resumen

Codex ya admite acceso remoto desde ChatGPT móvil y Access Tokens para espacios Enterprise

Qué cambió

Qué problema resuelve el acceso remoto móvil

Valor para desarrolladores

Qué resuelven los Access Tokens

No es una API key genérica

Valor seguro por defecto: Remote Control está apagado

Qué hay que actualizar antes de usarlo

Impacto en el uso empresarial de Codex

Límites que siguen importando

Resumen

Por qué se reinician de repente los límites de Codex: historial y fuentes

Resumen rápido

Qué muestra esta captura

Por qué los resets de Codex pueden parecer inesperados

Patrones históricos

1. Febrero de 2026: periodo de lanzamiento y capacidad temporal

2. Marzo de 2026: resets aleatorios y consumo anormal

3. Abril de 2026: hitos de crecimiento y resets para planes de pago

4. Mayo de 2026: reset compensatorio

Cómo interpretar un reset repentino

Cómo evaluar la fiabilidad de las fuentes

Resumen

Acceso remoto móvil de Codex: sigue tareas de programación en Mac desde la app ChatGPT

Qué puede hacer

Requisitos

Límites

Cómo conectarlo

Para qué sirve el móvil

Problemas comunes

Cuándo conviene

Mi lectura

Referencias

Superpowers: un framework de skills que devuelve los coding agents al proceso de ingeniería

Qué problema resuelve

Herramientas soportadas

Workflow base

Qué hay en la Skills Library

Diferencia frente a un prompt normal

Para quién sirve

Precauciones

Resumen

Rechazar el Vibe Coding: el repositorio skills de Matt Pocock añade restricciones de ingeniería a la programación con IA

Primero resolver la falta de alineación

Escribir el lenguaje de dominio en el contexto

Usar TDD para limitar la velocidad

Diagnosticar con un ciclo

Revisar la arquitectura con regularidad

Lo que hay que limitar es la libertad

Codex /goal vs Claude Code /goal: ejecutar tareas largas hasta terminarlas

Qué problema resuelve /goal

/goal en Codex: experimental y ligado al hilo actual

/goal en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

La diferencia principal

Cómo escribir un buen /goal

Cuándo conviene usar /goal

Qué significa esto para las herramientas de programación con IA

Resumen

Referencias

¿Cómo conectar Codex con modelos chinos? Gestionar APIs compatibles con OpenAI usando CCX

Qué problema resuelve CCX

Endpoints soportados

Arquitectura

Diferencias entre CCX y CodexBridge

Despliegue rápido

Despliegue con Docker

Ejecutar desde código fuente

Qué problema resuelve `/goal`

`/goal` en Codex: experimental y ligado al hilo actual

`/goal` en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

Cómo escribir un buen `/goal`

Cuándo conviene usar `/goal`