Cuatro mil millones de tokens después: un mes con un asistente de IA en cifras

🌐 También en: English · Deutsch · Français

Desde hace unos meses, buena parte de este blog y del código Ansible que hay detrás se escribe junto con un asistente de IA: Claude, en su versión de línea de comandos, Claude Code. Escribe código, ejecuta comandos en los servidores, lee ficheros de log y redacta borradores de artículos; yo decido, compruebo y digo bastante a menudo «no, así no». En algún momento quise saber a cuánto asciende todo eso de verdad. No a ojo, sino en cifras.

Para eso existe una pequeña herramienta de la comunidad, ccusage. Lee los ficheros de log que Claude Code guarda en mi propio ordenador y los suma. Una línea en el terminal:

npx ccusage@latest daily --since 20260923

npx descarga la herramienta, la ejecuta una vez y la olvida. Solo lee los logs locales y no envía nada de su contenido a ninguna parte; lo único que descarga de Internet es la lista de precios actual. Esto es lo que salió para las cuatro semanas del 23 de septiembre al 21 de octubre de 2026.

🔢 Las cifras en bruto

🧩 ¿Qué es un token?

Un modelo de lenguaje no lee letras ni palabras enteras, lee tokens: trozos de palabras. «Firewall» quizá son dos tokens, «el» es uno, una palabra alemana larga como «Datenbankverbindung» puede ser cuatro o cinco. Como regla general, 100 tokens son unas 75 palabras en inglés. Todo se cuenta en tokens: lo que entra, lo que sale y, esta es la parte interesante, lo que el modelo tiene que volver a leer.

📚 98 % de relectura

La línea más sorprendente de la tabla es la caché. De casi cuatro mil millones de tokens, 3.900 millones no eran nuevos en absoluto. Eran la misma conversación, leída otra vez.

Así funciona un asistente de este tipo: entre dos pasos no tiene memoria. Antes de cada respuesta, cada comando que ejecuta y cada fichero que lee, recibe de nuevo toda la conversación hasta ese momento: mis preguntas, sus respuestas, cada fragmento de log, cada fichero. Una sesión de trabajo larga en un servidor alcanza enseguida el tamaño de un libro pequeño, y ese libro se vuelve a leer para el siguiente paso. Y para el siguiente. Y para el siguiente.

Imagine a un administrativo que, antes de escribir cada frase de una carta, se lee el expediente completo desde la primera página. Ese es mi asistente. Por cada token que escribe, relee unos 450. La buena noticia: releer es barato. El proveedor mantiene la conversación lista en una caché, de modo que un token releído cuesta solo una décima parte de uno nuevo. Lo que también explica por qué cuatro mil millones de tokens suenan mucho más dramáticos de lo que son.

✍️ Lo que significa en el día a día

• 80 novelas. Los 8,7 millones de tokens que escribió el asistente son unos 6,5 millones de palabras, unas 80 novelas de extensión media. Impresas, una pila de papel de unos 2,6 metros. Hay que reconocer que casi nada de eso es literatura, sino ficheros de configuración, comandos de shell y explicaciones de por qué el cortafuegos hizo algo inesperado.
• 23 años de lectura. Si una persona quisiera leer los cuatro mil millones de tokens a un ritmo normal, sin dormir, sin café y sin fines de semana, necesitaría unos 23 años. A ocho horas diarias, sería toda una vida laboral.
• 475 veces más respuesta que pregunta. Mi propia entrada nueva fueron 18.342 tokens, unas pocas páginas de texto en cuatro semanas. Instrucciones cortas como «revisa los logs», «sí, hazlo así» o «¿por qué está en rojo?». El resto viene del asistente: todo lo que leyó en los servidores, escribió y explicó.
• Cuatro días libres. Se trabajó 25 de 29 días. Por lo visto, incluso un asistente de IA tiene fin de semana de vez en cuando, o más bien su humano.

💸 La factura que nunca llegó

La herramienta también calcula un precio: 1.407 dólares por cuatro semanas, unos 56 dólares por día activo y 118 el día de más actividad. Parece mucho, y no es lo que pagué.

La cifra es lo que costaría este uso a la tarifa de lista de la API, la interfaz con la que las empresas integran el modelo en sus propios productos. Allí se cobra cada token: entrada nueva, salida, escritura en la caché, lectura de la caché, cada una con su propia tarifa. ccusage simplemente multiplica mis cifras de tokens por esas tarifas.

Yo uso en cambio una suscripción, el plan Pro, con un precio de lista de unos 20 dólares al mes. Una suscripción es una tarifa plana con límites de uso: se puede trabajar hasta agotar la cuota de una franja de tiempo y luego se espera a que se renueve. Así que los 1.407 dólares son un «¿y si…?»: lo que costaría el mismo trabajo si cada token se cobrara uno a uno. Para un proyecto personal, la tarifa plana es la opción evidente; para una empresa que integra el modelo en su producto, el precio por token es lo normal.

Por cierto, esos límites no son teóricos. La tarea más cara del mes fue traducir el blog a posteriori: los 111 artículos existentes al alemán, al francés y al español. Se alargó varios días y muchas sesiones, porque una y otra vez llegaba al límite de cinco horas: el trabajo se detenía en mitad de un artículo y una sesión nueva lo retomaba en cuanto la franja se renovaba. Traducir es leer y escribir a la vez, y en grandes cantidades; se ve en las estadísticas, donde el 9 y el 11 de octubre están entre los días de más actividad. Un traductor humano habría necesitado meses. El asistente necesitó unos días y mi paciencia con el temporizador.

⚡ ¿Y cuántos ordenadores tuvieron que funcionar para esto?

Es la pregunta que más me gustaría responder, y la que no puedo responder honestamente con una cifra. El modelo no corre en mi ordenador, sino en centros de datos, en chips especializados construidos exactamente para este tipo de cálculo. Qué tamaño tiene el modelo, cuántos chips responden una petición y cuánta energía cuesta un token: el proveedor no lo publica, y cualquier cifra precisa aquí sería inventada.

Lo que sí se puede decir: un modelo de esta categoría no funciona en absoluto en un PC doméstico. Necesita bastante más memoria de la que tiene un ordenador normal. Y releer desde la caché requiere mucho menos cálculo que calcular algo nuevo, precisamente por eso es tanto más barato. El 98 % de relectura supone, por tanto, mucho menos trabajo en el centro de datos de lo que sugiere la simple cifra de tokens.

🏗️ Lo que salió de todo esto

Contar tokens es divertido, pero la verdadera pregunta es para qué sirvieron. En unos cinco meses se creó esto:

¿Cuánto habría llevado a la manera clásica, tecleado a mano? Para código de infraestructura se suele calcular, a grandes rasgos, entre 30 y 80 líneas terminadas y probadas al día, incluyendo investigación, pruebas en servidores reales y la búsqueda de errores, que a menudo lleva más tiempo que escribir. Si se añaden documentación y traducciones, la estimación llega a dos o tres años de trabajo a tiempo completo para una persona con experiencia. Esa persona tendría además que dominar a fondo, a la vez, SELinux, Kubernetes, cortafuegos, bases de datos, Nextcloud, WordPress y monitorización, algo poco habitual.

Esa persona tampoco soy yo. Pero he aprendido mucho por el camino, y mucho más deprisa de lo que habría aprendido de otro modo. Cada vez que algo no funcionaba, recibía la explicación en ese mismo momento: por qué SELinux rechaza una transición, qué es una cabecera hop-by-hop, por qué una base de datos corre sin protección aunque todo diga «enforcing». Es aprender justo en el momento en que surge la pregunta: un profesor particular que siempre tiene tiempo y nunca dice «lee primero el capítulo 7». Un manual explica muchas cosas que en ese momento no necesito, y la única página que sí necesito está en algún lugar del medio. Aquí me documenté de forma dirigida, pregunté, y los deep dives de este blog son lo que ha quedado de ello.

Las líneas de código son una medida tosca, y la estimación da un orden de magnitud, no una factura. Más importante es lo que las cifras no muestran: el asistente no decidió nada por su cuenta. Cada cambio en un servidor en producción se discutió antes, cada resultado se comprobó, y algunos de los mejores hallazgos vinieron de un simple «eso tiene mala pinta, ¿lo revisas otra vez?». El deep dive de SELinux describe dos de ellos. Hacia el día 20, por cierto, entendí de dónde viene ese viejo chiste de informáticos: que algunos hablamos más con nuestra IA que con personas de verdad, incluida la propia pareja. En mi defensa: la IA nunca se ha quejado de que le explique reglas de cortafuegos durante la cena. La IA se encarga del trabajo laborioso; la responsabilidad sigue siendo del humano. Y esto es un proyecto personal, así que compite con todo lo demás de la vida por el tiempo. Precisamente ahí está la clave: justo porque ese tiempo es limitado, la velocidad de trabajar con una IA marcó la diferencia. Unas pocas horas libres no bastan para teclear un cortafuegos a mano. Sí bastan para discutirlo, revisarlo y desplegarlo.

🔍 Lo que revelan las estadísticas

• Los grandes temas hacen grandes días. El día de más actividad, el 19 de octubre, fue cuando se escribieron y probaron las últimas partes del tour de Ansible y el artículo de SELinux: mucha lectura en los servidores y mucho texto.
• El contexto es lo que realmente dispara el coste. No lo que yo escribo, ni siquiera lo que escribe el asistente, sino cuánto tiene que tener presente. Las sesiones largas con muchos fragmentos de log son caras; las tareas cortas y concretas, baratas.
• El modelo no es el que más escribe. Lee. 450 tokens leídos por cada token escrito: menos «máquina de escribir creativa» y más «compañero muy rápido que se lee todo el expediente cada vez».

🧔 Mi opinión personal (algo afilada, y solo mía)

Para mí, el verdadero valor de todo esto no son las respuestas ingeniosas. Es el tiempo. Dos o tres años de trabajo en unos cinco meses: esa es la diferencia entre un proyecto con el que habría soñado y un proyecto que funciona. Endurecimiento, monitorización, documentación en tres idiomas, un blog en cuatro: nada de eso existiría así sin el asistente, sencillamente porque una vida humana tiene un número limitado de tardes.

Así que esta es mi opinión muy personal, como alguien con 20 años de experiencia profesional que ha tecleado a mano más que suficientes ficheros de configuración: para mis propios proyectos privados, escribir código de infraestructura línea a línea, a mano, ya no es propio de nuestro tiempo. A mí me parece la tarjeta perforada de nuestra época: honesta, admirable y, para mí personalmente, una forma de pasarme tres años con algo que hoy hago en pocos meses. No es un juicio sobre nadie: algunos de los administradores más cuidadosos que conozco escriben ellos mismos cada regla, y tienen buenas razones. Yo simplemente he llevado mi propio cuidado a otra parte: a las preguntas, la revisión, las pruebas y las decisiones. Ahí es donde considero al humano insustituible, y ahí va mi tiempo ahorrado.

El Ansible escrito a mano sobrevivirá, por supuesto, y con razón, junto a los vinilos, los teclados mecánicos y la persona que por principio compila su propio kernel. Quizá algún día me una a ellos por nostalgia. Para mis propios proyectos, sin embargo, en el poco tiempo libre que me dejan la familia y el trabajo, ya no es el método que elijo.

Y sin embargo hay una cara menos alegre, y sería deshonesto omitirla. Dos o tres años de trabajo de una persona en cinco meses: dicho al revés, también significa que un proyecto que antes habría tenido ocupado mucho tiempo a un pequeño equipo ahora necesita una persona y un asistente. Para mí, con un proyecto personal y poco tiempo, es pura ganancia. Para los equipos y las profesiones que vivían precisamente de este trabajo manual y cuidadoso, es una pregunta real, y nadie tiene todavía una buena respuesta. El camino de la derecha es más rápido. También está más vacío.

Creo que muchos de nosotros estamos ahora mismo en esta bifurcación, queramos o no: administradores, desarrolladores, redactores técnicos, traductores. Yo he tomado el camino de la derecha, porque para mi situación es claramente el mejor; en otras situaciones la respuesta puede ser muy distinta. Pero de vez en cuando miro por encima del hombro. Quien sigue delante del poste indicador no se ha quedado atrás. Está sopesando algo que merece ser sopesado.

🎬 Conclusión

Cuatro mil millones de tokens suenan a ciencia ficción. Traducidos a la vida diaria, son un compañero que nunca se cansa de releer todo el expediente, que escribe 80 novelas de configuración en cuatro semanas y que habría enviado una factura de 1.400 dólares si no existiera la tarifa plana. Lo que queda es código que funciona, servidores mejor protegidos que antes y un blog que ahora habla cuatro idiomas. Y la constatación de que la frase más corta de todos esos miles de millones, «sí, hazlo así», seguía siendo la más importante.

Y una última nota personal. Oficialmente, llamo a este blog y al código en GitHub mi voluntariado de 2026: en las fiestas, sencillamente, suena mejor 😉 Pero, siendo sincero, es sobre todo la mejor formación continua que he tenido nunca: aprendo muchísimo a nivel técnico, más en unos meses que en más de un curso, porque cada pregunta recibe su respuesta justo cuando surge, y mi escaso tiempo libre se dedica a entender en lugar de a buscar. Eficiente, eficaz, sin perder un minuto. Escrito por un xennial, nacido en 1979 y, por tanto, justo un año demasiado pronto para contar oficialmente como nativo digital, pero lo bastante tarde como para haber crecido entre el radiocasete y el primer módem: la curva de aprendizaje es empinada, pero la diversión también. El voluntariado viene de regalo: al final surge algo que cualquiera, en cualquier parte del mundo, puede usar gratis si tiene las mismas tareas: hacer funcionar WordPress o Nextcloud de forma segura en sus propios servidores. Si a alguien en otro país le ahorra unas cuantas tardes, los cuatro mil millones de tokens habrán estado bien empleados.

Si quiere ver sus propias cifras: npx ccusage@latest daily en un terminal del ordenador donde corre Claude Code. Solo lee ficheros locales y no descarga nada más que la lista de precios.