[🤖] Vi que el contexto se llenaba al iniciar la conversación y rehice las reglas compartidas

✨ Resumen de GPT-5.6 Sol

Un registro de cómo encontré en las reglas compartidas y las Skills la causa de que el contexto de 258k se llenara nada más empezar, rechacé una reducción de apenas unas líneas y lo reorganicé todo en inglés comprimido sin alterar el significado.

El contexto ya estaba lleno antes de empezar a trabajar

Abrí una conversación nueva con Codex y vi que una parte considerable del contexto ya estaba ocupada. El máximo era 258k, pero las reglas compartidas y la lista de Skills ya consumían espacio antes de que empezara el trabajo real.

Primero pregunté cuánto contenido se cargaba al iniciar una conversación. Codex respondió con una cifra absurdamente mayor y lo corregí de inmediato.

«No, 258k es el máximo. Parece que las reglas globales son demasiado grandes…»

Pensándolo bien, no tenía nada de extraño. Cada vez que la IA cometía un error, yo añadía otra regla compartida para impedir que repitiera lo mismo. Se habían acumulado límites de autoridad, Git, credenciales, despliegues, navegadores, UI/UX, documentación, Goals, trabajo en paralelo y separación entre proyectos de empresa y personales. Convertía las tareas repetidas en Skills y, cuando una Skill volvía a fallar, añadía excepciones y procedimientos de verificación.

Yo quería evitar que la IA perdiera el contexto cada vez. Incluso me había alegrado de haber conectado el hilo y el criterio de mi trabajo con Codex Skills. Pero cuando los mecanismos creados para conservar el contexto se vuelven demasiado largos, empiezan a comerse el espacio destinado al trabajo nuevo. Las pistas que mantenían el hilo se habían convertido poco a poco en equipaje.

Me negué a terminar después de borrar unas pocas líneas

Al principio pedí una auditoría limitada a los elementos cuya eliminación no pudiera degradar el rendimiento. Codex actuó con cautela y solo limpió algunas repeticiones y fragmentos evidentemente largos.

El resultado me frustró de inmediato.

«¿Solo eso…? ¿Y comprimir descripciones innecesariamente largas y cosas así? ¿De verdad aplicaste todos los métodos que consideras mejores?»

Yo no quería borrar unas cuantas frases. Quería corregir la propia estructura: la misma condición de seguridad repetida en varios párrafos, una decisión dando vueltas en una descripción larga y detalles que ya estaban en una reference o un script copiados otra vez en el cuerpo de la Skill.

Pero perseguir únicamente la brevedad habría sido aún más peligroso. Si aprobación explícita se convertía simplemente en aprobación, o el objetivo y el alcance exactos se diluían en comprobar cuando sea necesario, bajarían los tokens, pero también cambiaría el comportamiento de la IA. En reglas sobre credenciales, cambios destructivos, propiedad de Git, despliegue y UI para clientes, una diferencia que parece menor puede mover el límite real de autoridad.

Así que fijé de nuevo el criterio: reducir ejemplos y explicaciones repetidas, pero conservar las condiciones, prohibiciones, excepciones, verificaciones y criterios de parada que determinan el comportamiento.

Medí si el coreano o el inglés consumían menos tokens

Durante el proceso pensé en cambiar todas las Skills al coreano. Para mí es más fácil leer y editar en coreano, pero el objetivo no era la comodidad de mis ojos, sino reducir los tokens que consumía Codex.

Preparé muestras comprimidas en coreano y en inglés con el mismo significado y las pasé por el tokenizer real. En varias descripciones de Skills que yo había creado, el inglés comprimido era claramente más corto. Eso no significaba que el coreano siempre saliera perdiendo. Sin embargo, muchas de las reglas compartidas que se habían acumulado podían mantener su significado con menos tokens al expresarse en inglés.

En ese momento, la dirección quedó clara.

«Entonces sería mejor cambiar todas las reglas compartidas y las Skills a inglés comprimido, ¿no? Así se ahorran tokens.»

No eliminé el coreano indiscriminadamente. Conservé las frases de activación en coreano que uso de verdad, los nombres de estado y ejemplos de salida visibles para el usuario y los términos propios del trabajo de la empresa cuya traducción podía debilitar el reconocimiento. El resto de explicaciones y procedimientos pasó a frases breves en inglés.

Codex carga en el contexto inicial el nombre, la descripción y la ruta de cada Skill, y solo lee el SKILL.md completo cuando esa Skill se activa.¹ Por eso reduje primero las reglas globales y las descripciones de Skill discovery que siempre están presentes, y después comprimí por separado el inventario de red y la Skill de escritura que entraban como bloques pesados al activarse.

Comprobé por separado que las frases reducidas produjeran el mismo comportamiento

Esta vez no consideré que «estar traducido al inglés» fuera el criterio de finalización. Primero reescribí un conjunto representativo: parte de las reglas de seguridad compartidas, una Skill de auditoría y una Skill de registro de tiempo. Un reviewer independiente comparó los originales con las versiones comprimidas y detectó inicialmente que una condición de la Skill de auditoría se había debilitado: también había que preservar el comportamiento no relacionado con la architecture existente.

Restauré esa condición y el mismo reviewer volvió a revisarla. Después extendí el patrón al resto de las reglas compartidas y a las trece Skills creadas por el usuario. Por último, una session distinta de la que había hecho la primera revisión comparó los veintinueve archivos completos con sus originales. Verificó que el texto reducido siguiera produciendo los mismos límites de aprobación, condiciones de parada, procedimientos de verificación y contratos de salida. Ya no apareció ninguna omisión importante.

Las cifras también mostraban la diferencia. Con el tokenizer o200k, las reglas globales que siempre se leen bajaron de 14.933 tokens a 10.644, aproximadamente un 28,7 %. Las descripciones de Skills expuestas al inicio de una conversación se redujeron cerca de un 31,1 %. Dos references grandes que se leen al activarse bajaron alrededor de un 50,5 %. En todo el alcance comparado, el total pasó de 81.347 tokens a 62.765, aproximadamente un 22,8 % menos.

Como los cuerpos completos de todas las Skills no se cargan al principio, ese 22,8 % no puede llamarse directamente «coste de inicio de conversación». Aun así, la parte que siempre entra se redujo de inmediato y la carga adicional al invocar una Skill pesada también bajó.

El contexto necesitaba densidad, no solo volumen

Antes, cuando la IA cometía un error, yo solo pensaba en escribir más reglas. Creía que una explicación más concreta evitaría fallos y que conservar ejemplos ayudaría a entender la situación la próxima vez. No era una idea completamente equivocada. De hecho, aquellas reglas habían evitado muchos problemas.

El problema era que solo añadía reglas y casi nunca volvía a comprimirlas. Aparecían en varios lugares frases para impedir el mismo fallo, las explicaciones de incidentes recientes quedaban como reglas permanentes y un texto largo escrito para aclarar una sola vez algo se convertía en el coste básico de todas las tareas.

Esta vez no quité las salvaguardas. Quité la repetición y la extensión que envolvían su explicación. Conservé qué hay que proteger, cuándo hay que detenerse, quién debe aprobar y cómo se verifica, y retiré las frases que repetían una y otra vez por qué existía la regla.

Dar más contexto a una IA y darle mejor contexto son cosas distintas.

A partir de ahora, mantener una regla compartida o una Skill no terminará al añadir una frase nueva. También tendré que comprobar si ese significado ya existe, si un incidente puede convertirse en un invariant y cuántas palabras no cambian el comportamiento real. El contexto no es un almacén infinito.

Más que acumular más memoria, quiero reproducir el mismo criterio con menos tokens.

Esta vez avancé un paso más en esa dirección.

Referencias

1. OpenAI, Codex Skills. Explica la carga progresiva de los metadatos de Skill discovery y de las instrucciones completas. ↩