Zendoric
← Volver al día · 30 de julio de 2026

Nate construye la "Token Saver Skill" para recortar un 90% el uso reutilizado de tokens en Codex y Claude Code

🕒 Publicado en Zendoric: 30 de julio de 2026 · 00:20

El autor arranca desde un problema muy concreto: uno alcanza los límites de un plan que ya paga sin haber hecho nada irrazonable, simplemente haciendo un puñado de preguntas, y en algún punto alrededor de la décima pregunta el consumo empieza a dispararse mucho más rápido de lo esperado.

Por Nate.

El autor arranca desde un problema muy concreto: uno alcanza los límites de un plan que ya paga sin haber hecho nada irrazonable, simplemente haciendo un puñado de preguntas, y en algún punto alrededor de la décima pregunta el consumo empieza a dispararse mucho más rápido de lo esperado.

Nate cuenta que, tras un día largo trabajando en Codex, abrió su propio rastreador de consumo de tokens ("Token Burn tracker") y encontró un total de 3.770 millones de tokens. Lo que más le inquietó no fue el total, sino el reparto: de los 3.750 millones de tokens de entrada registrados, 3.590 millones (un 95,73%) aparecían marcados como "input reutilizado" (reused input). Aclara que esta cifra proviene de su propio registro local de eventos —no de una factura de OpenAI— y que abarca actualizaciones acumulativas de uso a lo largo de 143 hilos de Codex y 28.877 registros locales. Por eso trata el dato como una señal para investigar, no como un total de tokens facturables limpio.

Un punto central del artículo es que "reutilizado" no significa "inútil": un trabajo complejo puede depender de una decisión tomada veinte minutos antes, de un archivo ya modificado, de un error que descartó la solución obvia, o de un párrafo aprobado tras cuatro versiones fallidas. Además, el material repetido elegible puede beneficiarse de un descuento de caché por parte del proveedor. Para Nate, esa continuidad es gran parte de lo que hace útiles a estas herramientas, pero tiene un coste: una petición posterior puede contener mucho más que la frase nueva que el usuario escribe, incluyendo intercambios previos, instrucciones permanentes, definiciones de herramientas, archivos, capturas de pantalla, resultados de navegación, salidas de comandos, respuestas descartadas y cualquier estado que el producto necesite para continuar el trabajo. Su frase resume la idea: "el décimo mensaje puede ser mucho más grande que el primero, aunque el prompt visible sea más corto. Tú escribiste menos. Tú pagaste más."

El autor recuerda que ya había defendido antes que un recuento de tokens es un rastro, no un marcador ("a token count is a trace, not a scoreboard"), y reitera que sigue creyendo eso: un día de uso elevado puede significar que un agente realizó trabajo real a través de archivos, navegadores, borradores y verificaciones, y que recortar la cifra sin preguntarse qué produjo ese trabajo es una mala forma de gestionar la IA. Aun así, el hallazgo del 95,73% de input reutilizado le lleva a plantear una pregunta distinta: cuánto de ese material todavía podía cambiar el resultado del trabajo, y cuánto simplemente permanecía porque nada en el sistema tenía motivo para descartarlo.

Con esa pregunta como punto de partida, se fija un objetivo agresivo: reducir el input reutilizado reportado en un 90%, sin que ello aumente los errores, los reintentos, el tiempo de revisión o el trabajo que haya que repetir.

El correo, a modo de avance de contenido de pago, enumera lo que incluye el artículo completo (accesible para suscriptores): una medición basada en un trabajo real ejecutado de dos formas distintas, comparando las cifras reportadas por el proveedor y explicando qué demuestra esa comparación y qué no; quince cambios propuestos, ordenados según qué tan respaldados están, cada uno con las condiciones en que ayuda, las condiciones en que perjudica, y si fue medido o si todavía es una suposición; nueve de esos cambios aplicables hoy mismo, hábitos para mantener material fuera de una petición en los propios productos que ya se usan, sin necesidad de instalar nada; la propia "Token Saver Skill", explicando qué hace por el usuario en Codex y en Claude Code, los cuatro cambios que impone y el único límite que no puede cruzar; una explicación de qué cuesta realmente el cacheo, comparando la matemática de caché de cinco minutos frente a una hora, y por qué el input cacheado nunca desaparece de la factura; y finalmente, qué es lo que el propio Nate reconoce que todavía no puede demostrar, los límites de haber analizado un único trabajo comparado y cuál sería la siguiente prueba necesaria.

El correo cierra indicando que los suscriptores de pago obtienen el análisis y la guía completos, además de acceso a la comunidad de Slack del autor. Los detalles concretos de los quince cambios, del funcionamiento exacto de la Token Saver Skill y de las cifras de la comparación del trabajo real quedan fuera de este correo introductorio, por lo que no se incluyen aquí al no aparecer en el cuerpo recibido.

🔗 Relacionadas en Zendoric

Fuentes y referencias