¿Cuánto me cuesta de verdad mi agente de programación, y dónde se va el dinero?
🟠 Intermedio · Práctico · 8 min de lectura
Miro la factura del mes y no me cuadra con lo que he hecho. No he pedido nada
enorme: unos cuantos arreglos, un par de refactores, sesiones de media hora.
¿En qué se ha ido?
El problema
Casi nadie sabe dónde se le va el dinero con un agente, porque el precio que
miras y el precio que pagas no son el mismo número.
El que miras es el de la tarifa. Claude Code acaba de añadir Sonnet 5.5 como
modelo por defecto de Sonnet en la API de Anthropic, con un millón de tokens
de contexto, a 2 dólares por millón de tokens de entrada y 10 por millón de
salida. Ese es el número que se compara entre modelos y el que aparece en
todas las tablas.
El que pagas depende de otra cosa. Y la pista está en la tercera cifra de ese
mismo anuncio, que casi nadie mira: las lecturas de caché cuestan 0,20
dólares por millón. Diez veces menos que la entrada normal.
Esa proporción es el artículo entero. En una sesión de agente, la salida es
poca (el modelo escribe un parche, no una novela) y la entrada es enorme,
porque cada turno vuelve a mandar toda la conversación anterior más los
ficheros que ha leído. Tu factura no la decide lo listo que sea el modelo.
La decide cuántas veces relees lo mismo y a qué precio se te cobra releerlo.
MIT Technology Review describe bien la conversación típica: empieza en el
precio del token y acaba en querer acceso al modelo más capaz de la nube, sin
que nadie se haya parado a preguntar si hace falta ese nivel de capacidad.
Casi nunca hace falta, y casi nunca es ahí donde está el dinero.
Cómo se resuelve hoy
Tres palancas, por orden de cuánto mueven la aguja.
La caché. Es la que más importa y la que menos se toca. El coste de un
turno es, aproximadamente, todo el contexto acumulado multiplicado por el
precio de entrada. Si ese contexto llega en caliente desde la caché, se
multiplica por 0,20 en vez de por 2. Para que eso ocurra, lo que va al
principio del contexto tiene que ser estable entre turnos: las
instrucciones del proyecto, los ficheros de referencia, lo que no cambia.
Cualquier cosa que metas al principio y que varíe en cada turno (una marca de
tiempo, un identificador de sesión, el resultado de un comando) invalida la
caché de todo lo que viene detrás.
El tamaño del contexto. Un millón de tokens de contexto no es una
invitación a llenarlo. Es entrada, y la entrada se paga en cada turno. Una
sesión que arrastra treinta ficheros irrelevantes paga por esos treinta
ficheros una y otra vez hasta que la cierras. Las sesiones cortas y centradas
no son una preferencia estética, son una decisión de coste.
El modelo. Es la palanca que todo el mundo toca primero y la que menos
rinde si las otras dos están mal. Un modelo barato releyendo basura en frío
sale más caro que uno capaz leyendo poco y en caliente.
Y hay una cuarta cosa que no es una palanca sino un requisito previo:
ver el gasto. Claude Code 2.1.284 añade los importes en dólares al límite
de gasto en /usage y en la línea de estado, con la forma «$271.40 / $500.00
spent this month». Parece un detalle de interfaz y no lo es: hasta que el
número está delante de los ojos mientras trabajas, nadie cambia de hábitos.
Ejemplo
La cuenta, con los precios publicados de Sonnet 5.5. Supón una sesión de
veinte turnos en la que el contexto se estabiliza en unos 100.000 tokens y en
cada turno el modelo escribe unos 2.000 de salida.
Sin caché, cada turno paga la entrada completa a precio normal:
entrada: 20 turnos x 100.000 tokens x $2 / 1.000.000 = $4,00
salida: 20 turnos x 2.000 tokens x $10 / 1.000.000 = $0,40
total = $4,40
Con caché, el primer turno escribe la caché y los 19 siguientes la leen:
turno 1: 100.000 x $2 / 1.000.000 = $0,20
turnos 2-20: 19 x 100.000 x $0,20 / 1.000.000 = $0,38
salida: 20 x 2.000 x $10 / 1.000.000 = $0,40
total = $0,98
La misma sesión, el mismo modelo, el mismo trabajo: 4,40 contra 0,98. La
diferencia no está en lo que pides, está en si el contexto llega frío o
caliente. (La escritura de caché suele cobrarse algo más cara que la entrada
normal, así que la cifra real queda un poco por encima de 0,98; el orden de
magnitud es el que importa.)
Ahora la parte que puedes aplicar. Un CLAUDE.md o AGENTS.md que ayuda a
la caché en vez de romperla:
# Proyecto X
## Lo estable, arriba del todo
- Stack: Python 3.13, FastAPI, PostgreSQL.
- Los tests se ejecutan con `pytest -q` desde la raíz.
- La lógica vive en `src/dominio/`. `src/api/` solo enruta.
## Lo que NO debe ir en este fichero
- Nada con fecha de hoy ni número de versión que cambie cada día.
- Nada de "la tarea actual es...". Eso va en el mensaje, no aquí.
- Nada generado por un script en cada arranque.
Y la higiene de sesión, que es gratis:
# Una tarea, una sesión. Al terminar, cerrarla.
# Si el agente ya ha leído 30 ficheros para una tarea que toca 2,
# no sigas: cierra y vuelve a empezar nombrando los 2.
claude -p "Arregla la validacion de email en src/dominio/usuarios.py"
Mide antes y después. Si tu herramienta enseña el gasto, apúntalo al empezar
la semana y al acabarla. Sin un número antes, cualquier mejora es una
sensación.
Errores habituales
Comparar modelos por el precio de entrada y salida. Son dos de las cuatro
cifras. Faltan la lectura y la escritura de caché, y en una carga de trabajo
de agente la lectura de caché puede ser la que más veces se aplica. Un modelo
con entrada más cara y caché más barata puede salirte mejor.
Meter cosas cambiantes al principio del contexto. Es el error más caro y
el más silencioso, porque no falla nada: simplemente pagas diez veces más y
no te enteras. Si tu plantilla de sistema incluye la fecha y la hora, acabas
de invalidar la caché de todo lo que va detrás, en cada turno.
Sesiones eternas. Dejar abierta la misma sesión toda la tarde se siente
cómodo y productivo. Lo que hace es arrastrar en cada turno todo lo que ya no
hace falta. Cerrar y reabrir cuesta diez segundos de contexto que tú vuelves a
dar en dos frases.
Dejar que una herramienta se coma el contexto sin enterarte. Una salida
enorme de una herramienta entra en el contexto y se paga en todos los turnos
siguientes. Cline acaba de arreglar un caso de esto: cuando una herramienta
MCP devuelve más de lo que cabe, antes se perdía lo que pasaba del corte;
ahora el agente recibe una vista previa y un enlace que puede ir paginando
con read_files. Mira qué hace la tuya, porque las hay que te meten el
volcado entero.
Qué vigilar
🟢 La caché de prompt y los importes en pantalla ya existen y son de hoy.
Ordenar lo estable arriba y cerrar sesiones es trabajo de media hora que
rinde desde la primera factura.
🟡 Las herramientas están empezando a enseñar el dinero mientras trabajas, no
después. Cuanto más normal sea eso, menos falta hará este artículo.
🟡 La gestión del contexto que no cabe. El arreglo de Cline apunta a algo
general: dar una vista previa paginable en vez de volcarlo todo o truncarlo.
Si tu agente aún hace lo segundo, estás pagando por ello.
🔴 Que el contexto largo deje de costar proporcionalmente. Hoy un millón de
tokens de contexto es un millón de tokens que se pagan. Si alguien consigue
que mantener contexto grande sea barato de verdad, la mitad de este artículo
se cae. No hay señales de que esté cerca.