Inicio → Ayuda

La factura es más alta de lo que justifica el recuento de tokens

Multiplica por la tarifa correcta. La salida suele costar unas cinco veces la entrada. Las lecturas de caché son una pequeña fracción de la tarifa de entrada; las escrituras se cobran por encima de ella. Una carga que reescribe su contexto una y otra vez paga la tarifa de escritura repetidamente mientras produce muy poca salida visible.

Lo que ves

Por qué ocurre

Los precios de catálogo se dan por millón de tokens de entrada y de salida, lo que invita a pensar en una única media. Las facturas reales son la suma de cuatro tarifas distintas: entrada, salida, lectura de caché y escritura en caché. Cuando la mezcla cambia, la factura cambia aunque el total de tokens apenas se mueva.

Lo que sorprende es la dirección de la caché. Leer de la caché es barato: para eso existe. Escribir en ella cuesta más que enviar los tokens de nuevo. Así que un bucle que altera el principio de su contexto en cada turno invalida la caché y paga el recargo cada vez, mientras que uno que añade a un prefijo estable obtiene el descuento.

Los números de nuestra propia facturación muestran la escala: en una muestra de peticiones con caché, la entrada y la salida normales sumaban alrededor del 3% de todos los tokens procesados, y el resto eran escrituras y lecturas de caché. En una sesión de treinta peticiones, solo las escrituras en caché supusieron el 63% del cargo: tokens que no produjeron ninguna salida.

Comprueba si es esta la causa

Toma una petición real del registro de uso de tu proveedor y separa los cuatro contadores:

# Any provider that reports usage will expose these four fields.
# What to compare:
#   input_tokens           charged at the input rate
#   output_tokens          usually ~5x the input rate
#   cache_read_tokens      a fraction of the input rate
#   cache_creation_tokens  charged ABOVE the input rate
#
# If cache_creation dominates, the cost is context churn, not generation.

Calcula qué parte del cargo corresponde a cada contador. Si dominan las escrituras en caché, la palanca es la estabilidad del prompt, no un modelo más barato.

Cómo solucionarlo

  1. Estabiliza el principio del promptCualquier cosa que cambie en cada turno (una marca de tiempo, una lista de herramientas reordenada, un contador) invalida la caché desde ese punto. Mueve el contenido variable al final y el prefijo seguirá siendo cacheable.
  2. Mira la longitud de la salida antes de cambiar de modeloLa salida cuesta varias veces la entrada. Un cambio de prompt que acorta las respuestas en un tercio a menudo ahorra más que pasar a un nivel más barato, y no requiere volver a validar.
  3. Envía los pasos baratos a un modelo baratoClasificación, extracción y enrutamiento rara vez necesitan un modelo insignia. Enviar solo el paso final de razonamiento al modelo caro suele reducir el coste combinado en más de la mitad.
  4. Compara por millón de salida, no por millón de tokensUna cifra media por token oculta lo que de verdad mueve la factura. Dos modelos con medias parecidas pueden diferir mucho al aplicar la proporción entrada/salida de tu carga.
APICLAN desglosa los cuatro contadores en cada llamada, así que una factura sorprendente se puede rastrear hasta una petición concreta en lugar de estimarse. Las tarifas por modelo están en las páginas de precios.

Relacionado

Unexpected token '<' al llamar a una API compatible con OpenAI401 invalid API key: cuando la clave parece correcta pero sigue fallando

Revisado por última vez el 2026-10-01. Escrito a partir de problemas diagnosticados en una pasarela compatible con OpenAI en producción, no recopilado de otras webs.