Explorar notas
Costes de API
Los proveedores suelen publicar precios por millón de tokens. El coste real de una tarea depende del input procesado, del output generado y de cuántas llamadas realiza la aplicación.
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_output
En una aplicación conversacional, el input puede incluir instrucciones, historial, definiciones de tools y resultados anteriores. El último mensaje del usuario es solo una parte del material procesado.
En modelos con reasoning, el output facturable puede incluir trabajo que no aparece como texto visible o que la API detalla por separado. Para calcular el coste hay que utilizar las categorías de usage que define el proveedor.
Cached input
Cuando muchas requests comparten un prefijo grande, el proveedor puede reconocerlo como cached input y aplicar otra tarifa. Un caso típico son instrucciones y definiciones de tools estables que se repiten en cada turno.
Los tokens cacheados pueden tener tarifa de lectura, condiciones de elegibilidad y, según el proveedor, coste de escritura. El ahorro depende de que el contenido se reutilice y produzca cache hits.
La cuenta puede expresarse así:
coste =
input_no_cacheado × tarifa_input
+ input_cacheado × tarifa_cached_input
+ output × tarifa_output
Para medir una aplicación real conviene trabajar con el usage devuelto por la API.
Crecimiento del contexto
En una API que reenvía la conversación, los turnos posteriores procesan de nuevo parte del contexto anterior.
En el ejemplo, las cuatro llamadas procesan 5K + 8K + 12K + 16K = 41K tokens de input. Los 16K del último turno describen el tamaño final, no todo el trabajo acumulado.
Compactación, selección de contexto y caching pueden cambiar esa curva. Para calcular el coste interesa el usage de cada llamada.
Agentes y subagentes
Una sola petición del usuario puede producir muchas inferencias:
- 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.
Cada llamada suma input y output. Un subagente añade además su propio contexto y loop. El paralelismo puede reducir el tiempo transcurrido y aumentar el consumo total al mismo tiempo.
Reasoning effort también puede modificar los tokens utilizados y el número de pasos. Por eso el coste de un agente se mide sobre sus runs, no sobre el número de mensajes visibles 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:
| Operación (tokens × tarifa / 1M) | Coste |
|---|---|
| Input: 20M × $4 | $80 |
| Output: 2M × $20 | $40 |
| Total | $120 |
Si 15K de los 20K tokens de cada request se facturasen como cached input:
| Operación (tokens × tarifa / 1M) | Coste |
|---|---|
| Input no cacheado: 5M × $4,00 | $20 |
| Cached input: 15M × $0,40 | $6 |
| Output: 2M × $20 | $40 |
| Total | $66 |
Es un ejemplo de cálculo, no una previsión. La página del modelo también aplicaba precios superiores a requests con más de 272K input tokens y cobraba la escritura de cache por separado. Antes de presupuestar hay que comprobar el tarifario y las condiciones actuales.
Qué registrar
Para comparar configuraciones registra el modelo, el usage de cada llamada, los cache hits y cualquier tarifa adicional de tools. Después cruza ese coste con la latencia, la tasa de éxito y la calidad del resultado en la tarea que importa.