Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Costes de API
Los proveedores suelen publicar precios por millón de tokens. Lo que termina costando una tarea depende de cuánto input procesas, cuánto genera el modelo y cuántas veces vuelves a llamarlo.
Input y output
El cálculo básico separa input y output porque normalmente tienen tarifas distintas:
coste =
input_tokens × tarifa_input
+ output_tokens × tarifa_outputEn una aplicación conversacional, el input puede incluir instrucciones, historial, definiciones de tools y resultados anteriores. No basta con contar el último mensaje del usuario.
El output facturable tampoco tiene que coincidir solo con el texto visible. En modelos con reasoning, la API puede incluir trabajo adicional dentro del usage de output o detallarlo por separado. La definición del proveedor es la que se utiliza para facturar.
Cached input
Cuando muchas requests comparten un prefijo grande, el proveedor puede reconocerlo como cached input y aplicar otra tarifa. Un ejemplo sería un conjunto estable de instrucciones y definiciones de tools que se repite en cada turno.
La cache no significa que esos tokens sean gratis. Puede haber una tarifa de lectura y, según el proveedor, condiciones o coste de escritura. El ahorro real depende de que el contenido se reutilice y produzca cache hits.
La cuenta puede escribirse así:
coste =
input_no_cacheado × tarifa_input
+ input_cacheado × tarifa_cached_input
+ output × tarifa_outputPara medir una aplicación real conviene utilizar el usage devuelto por la API, no intentar reconstruirlo solo a partir del texto visible.
Crecimiento del contexto
En una API que reenvía la conversación, los turnos posteriores procesan también parte del contexto anterior.
En el ejemplo, las cuatro llamadas procesan 5K + 8K + 12K + 16K = 41K tokens de input. Mirar solo los 16K del último turno infravalora el trabajo acumulado.
Compactación, selección de contexto y caching pueden cambiar esa curva. Lo importante es medir cada llamada, porque el tamaño final de la conversación no representa por sí solo todo el input facturado.
Agentes y subagentes
Una tarea agéntica puede realizar muchas inferencias por una sola petición del usuario:
- El modelo decide ejecutar una tool.
- El resultado vuelve como nuevo input.
- El modelo decide otra acción.
- Tests, reintentos o validaciones añaden más iteraciones.
El coste se acumula en cada llamada. Si además se delega a subagentes, cada uno recibe contexto y ejecuta su propio loop. El paralelismo puede reducir el tiempo transcurrido, pero aumenta el uso total si añade inferencias.
Reasoning effort también puede cambiar el consumo y el número de pasos. Por eso el coste de un agente se calcula sobre sus runs reales, no sobre el número de mensajes del usuario.
Ejemplo fechado
Las tarifas de GPT-5.6 Sol comprobadas el 28-08-2026 para texto estándar eran:
- Input: $4,00 / 1M tokens.
- Cached input: $0,40 / 1M tokens.
- Output: $20,00 / 1M tokens.
Para 1.000 requests con 20K tokens de input no cacheado y 2K de output cada una:
input = 1.000 × 20.000 = 20M tokens → 20 × $4 = $80
output = 1.000 × 2.000 = 2M tokens → 2 × $20 = $40
-----
$120Si 15K de los 20K tokens de cada request se facturasen como cached input:
input no cacheado = 5M × $4,00 = $20
cached input = 15M × $0,40 = $6
output = 2M × $20 = $40
---
$66Es un ejemplo de cálculo, no una previsión. La página del modelo también aplica precios superiores a requests con más de 272K input tokens y cobra la escritura de cache por separado. Antes de presupuestar hay que comprobar el tarifario y las condiciones actuales.
Qué medir
Para entender el coste de una tarea basta con registrar el modelo, el usage de cada llamada, los cache hits y las tarifas adicionales de tools si existen. Después se puede comparar el coste con el resultado, la latencia y la tasa de éxito.
Optimizar no significa utilizar siempre el modelo más barato. Significa encontrar la configuración de menor coste que siga resolviendo la tarea al nivel necesario.