Inicio → Ayuda

Cobrado dos veces por lo que parecía una sola petición

Tu cliente se rindió y reintentó mientras la primera petición seguía generándose. El proveedor terminó ambas, así que ambas se cobran: el timeout canceló tu espera, no el trabajo.

Lo que ves

Por qué ocurre

Un timeout HTTP es una decisión local. Salvo que la conexión se cierre realmente y el servidor decida abortar al desconectarse, la generación continúa hasta el final y se cobra.

Los reintentos automáticos de los SDK vienen activados por defecto y son invisibles en tus propios logs. Un código que parece hacer una llamada puede hacer tres.

Los modelos de razonamiento lo hacen mucho más probable, porque el tiempo hasta el primer token es lo bastante largo como para superar un timeout por defecto mientras todo funciona con normalidad.

Cómo solucionarlo

  1. Fija el timeout por encima de la respuesta más lenta que esperasMide el p99 de tu propio tráfico y dale margen. La mayoría de los cargos duplicados son un valor por defecto de 60 segundos frente a una respuesta de 70.
  2. Desactiva los reintentos automáticos en las llamadas carasPon max_retries a 0 en el cliente y reintenta de forma deliberada, donde puedas registrarlo y decidir si vale la pena repetir el trabajo.
  3. Usa streaming en las peticiones largasEl streaming te da un primer token enseguida, lo que evita que salten los timeouts por inactividad y te indica que la petición sigue viva.
Cada llamada en APICLAN se registra por separado con su propia marca de tiempo y su cargo, así que dos entradas con pocos segundos de diferencia, el mismo modelo y recuentos de tokens parecidos son la firma que debes buscar cuando una factura parece duplicada.

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.