Una colección de situaciones B2B representativas que muestra cómo una conversación comercial se convierte en una señal candidata para revisión humana.
«Su ruta es inestable»: separe el fallo del proveedor de su configuración y de los reintentos del cliente
Un mensaje que dice «en horas punta falla siempre» no aclara en qué capa falló. Aquí se propone un orden de diagnóstico que solo usa campos verificables, para separar un fallo del proveedor, un error de enrutado y la amplificación por reintentos en el lado del cliente.
Este escenario explica la lógica de evaluación del producto. No es un caso real de cliente, un testimonio, un contrato ni una afirmación de ingresos o conversión.
01Situación
02Evaluación de la señal
03Confianza y prioridad
04Siguiente paso humano
Indicios considerados
- El cliente indica una ventana temporal y una proporción de fallos, en lugar de decir solo «va mal».
- Los fallos incluyen códigos de estado HTTP o códigos de error legibles que permiten separar capas.
- El estado del proveedor, su propia configuración de enrutado y los registros de reintentos del cliente aún no están alineados.
«En horas punta falla siempre. ¿Le pasa algo a su ruta?»
Ese mensaje aparece en el grupo de clientes de un revendedor de AI API. Las reacciones suelen ser dos. Una es disculparse y pasar la noche reajustando los pesos del enrutado. La otra es preguntar primero, hasta que el cliente concluye que está usted esquivando el problema.
Ambas comparten un supuesto: que ya sabe a qué se refiere la palabra «inestable». En el escenario compuesto de abajo, el problema es justamente ese supuesto.
En resumen: una queja por «inestabilidad» hay que dividirla en tres cosas y documentar cada una por separado: qué estado devolvió el proveedor, cómo están configurados su enrutado y sus claves, y si el cliente reintenta sin esperas. El orden importa, porque la categoría que más se confunde con un fallo del proveedor nace en el lado del cliente.
NOTICE: los clientes, grupos, mensajes y cifras de uso de este texto son ilustraciones compuestas que sirven para mostrar un orden de evaluación. No representan clientes, incidentes, contratos ni operaciones cerradas reales.
«Inestable» no dice en qué capa falló
Vuelva a leer el mensaje. Solo se extraen dos hechos: una ventana temporal, las horas punta, y un síntoma, los fallos. En qué capa falló, con qué proporción y con qué aspecto tenía el error no aparecen por ningún lado.
No es vaguedad del cliente. «Estable» es una palabra que nace de la experiencia de uso. Describe un resultado, no una causa. Debajo hay al menos tres posibilidades.
El proveedor realmente está degradado o sobrecargado. Su enrutado, sus pesos o la reutilización de claves tienen un problema de configuración. O la lógica de reintentos del cliente convirtió un límite corriente en una avalancha. Las tres pueden coexistir, pero en un incidente concreto una de ellas es la causa principal. Encontrarla es lo que el sector suele llamar atribución, y determina qué cambia usted después y, más importante, si debería cambiarlo usted.
Conviértalo en campos con los que pueda contrastar
El primer paso de la atribución no es investigar, sino convertir: sustituir una afirmación que no se puede verificar por campos que sí. Estos cuatro suelen estar disponibles en una hora y apenas requieren colaboración del cliente:
- La ventana temporal en la que se produjeron los fallos, con precisión de minuto
- La distribución de códigos de estado HTTP en las peticiones fallidas, por ejemplo cuánto corresponde a 429 y cuánto a 503
- El código de error y la cadena de tipo de error en el cuerpo de la respuesta
- La curva de volumen total de peticiones que registró su lado en esa misma ventana
El tercer punto es el que más se omite. Muchos equipos miran solo el código de estado: 429 significa límite, 503 significa que el proveedor está caído. Esa lectura acierta la mayoría de las veces, pero se le escapa un caso importante, y ese caso es rutinario en este negocio.
429 y 503 apuntan en direcciones opuestas
En la documentación del proveedor los dos errores se tratan por separado.
429 con el tipo rate_limit_error indica que se tocó un límite de frecuencia. 503 con el tipo service_unavailable_error indica que el modelo solicitado está temporalmente sobrecargado. El primero es un problema de cuota; el segundo, de capacidad. Para el primero usted ajusta su propio ritmo de peticiones; para el segundo poco se puede hacer más allá de respetar Retry-After y reintentar después, o cambiar de ruta.
La consecuencia para la atribución es esta: 503 junto con sobrecarga del modelo es una de las pocas señales que sitúan la responsabilidad directamente en el proveedor. Si en la ventana de fallos domina el 503 y no el 429, entonces «la ruta es inestable» apunta en la dirección correcta, y la conversación pasa a rutas de respaldo y políticas de degradación.
Si la ventana es casi toda 429, la dirección se invierte. Porque el 429 tiene una subdivisión que casi nadie lee con atención.
slow_down: la velocidad de crecimiento del cliente, no una caída del proveedor
En esa misma documentación hay un párrafo que conviene leer palabra por palabra:
A slow_down error can occur even when your traffic is within its requests-per-minute and tokens-per-minute limits. It reflects how quickly traffic increased, not whether you exhausted those limits.
La regla práctica publicada: cuando el tráfico alcanza un millón de tokens de entrada por minuto, no debería crecer más de un 50 por ciento cada 15 minutos. Por encima de esa pendiente empieza a aparecer slow_down.
Esa frase reescribe la lectura habitual del 429. Es muy posible que los 429 de las horas punta no aparezcan porque alguien agotara una cuota, sino porque la velocidad de crecimiento superó la pendiente de rampa que el proveedor permite. Y ese ritmo lo fija quien envía las peticiones: su cliente, o el código de reintentos que el cliente escribió.
En este punto el objeto de la atribución se desplaza de «¿es estable el proveedor?» a «¿quién envía peticiones y con qué pendiente?».
El amplificador de reintentos: por qué «enviar otra vez» empeora las cosas
El siguiente punto fija la responsabilidad en el lado del cliente.
La documentación de cuotas incluye una advertencia: Unsuccessful requests still count toward your per-minute rate limit. Continuously resending a request without backing off makes throttling worse.
Detrás de esa frase hay un defecto de implementación frecuente. Un cliente recibe un 429, reintenta de inmediato, vuelve a fallar, reintenta de inmediato otra vez. Si además ejecuta concurrencia, cada fallo se multiplica por el factor de concurrencia y se convierte en una oleada de peticiones que se amplifica sola. Usted ve un salto brusco en la tasa de fallos. El proveedor ve una clave cuyo volumen se multiplicó en segundos. La causa real está en el bucle de reintentos del cliente sin esperas.
No hace falta adivinar. Mire su propia curva de volumen: si las peticiones fallidas y el total crecen de forma pronunciada en la misma ventana, y el volumen total sube muy por encima de la variación normal del negocio, la amplificación por reintentos está casi con seguridad presente. El agotamiento corriente de cuota es una línea que sube despacio. La amplificación por reintentos es una aguja vertical.
Un cambio que conviene recomendar al cliente de inmediato: la mayoría de los SDK oficiales ya reintentan con retroceso exponencial y jitter, normalmente unas dos tentativas por defecto. Si el cliente envolvió eso con su propia lógica de «reintentar de inmediato al fallar», está anulando la protección del SDK.
La capa que se omite: configuración de enrutado y claves compartidas
Una vez descartados la sobrecarga del proveedor y la amplificación por reintentos, lo que queda suele estar de su lado y concentrado en un punto: varios clientes o líneas de negocio comparten la misma clave del proveedor.
Los límites de frecuencia van ligados a la clave, no al cliente. En cuanto el tráfico de dos clientes pasa por una misma clave, ha atado sus cuotas, sus reintentos fallidos y sus picos. El cliente A lanza un trabajo por lotes en horas punta mientras el cliente B mantiene conversaciones en vivo, y lo que el cliente B percibe es «una ruta inestable».
La prueba en esta capa también es directa: agrupe las peticiones de la ventana de fallos por clave del proveedor y mire las curvas. Si el volumen de una clave equivale a la suma de varias líneas de negocio, esta capa es la causa principal. Lo que hay que cambiar entonces no es el peso del enrutado, sino la granularidad del aislamiento de claves.
Cambie una variable cada vez
A estas alturas tiene pruebas suficientes para formular una hipótesis. El paso siguiente tiene una restricción dura: cambie una variable cada vez.
Ajustar pesos de enrutado, escalar y pedir al cliente que arregle su lógica de reintentos al mismo tiempo es el mal hábito más caro de este negocio. Si las métricas mejoran, no sabrá qué lo consiguió. Si empeoran, no sabrá qué revertir, y la paciencia del cliente se consume por horas.
Un orden más firme: primero el cliente deja de reintentar sin esperas y usted observa una ventana; después aborda el aislamiento de claves; solo entonces toca las rutas del proveedor. El coste de este orden es la velocidad. La ventaja es que cada acción se puede verificar, y solo las acciones verificadas son reutilizables.
Cuándo no sirve este diagnóstico
Todo lo anterior se apoya en una premisa: tiene acceso a pruebas por capas. En los casos siguientes el método falla y hace falta otro enfoque.
Primero, el cliente solo ofrece «no funciona», sin ventana temporal ni muestra del fallo. No hay campos que dividir, así que haga primero una reproducción mínima y no prometa nada por instinto.
Segundo, el proveedor reduce los códigos de error a un 500 genérico o a un cuerpo propio, y los códigos de estado dejan de tener un significado claro. El paso de «separar por código de estado» queda anulado, y solo quedan las curvas de peticiones contrastadas con la página pública de estado del proveedor.
Tercero, la ventana de fallo es demasiado corta. Unos minutos de fluctuación suelen quedar por debajo de la granularidad de agregación, no hay curva y solo quedan muestras dispersas en los registros. Sacar conclusiones aquí es arriesgado; anotarlo como «en observación» suele ser más honesto que forzar una atribución.
Conviene señalar un límite: este texto trata solo la cuestión de qué capa es responsable. No cubre cómo diseñar una arquitectura de alta disponibilidad ni si conviene cambiar de proveedor. Lo primero se trata aparte en este sitio, y lo segundo es una decisión comercial que no debería derivarse de la atribución de un solo incidente.
Para seguir leyendo
- Un 429 es solo un síntoma: cómo se forma de verdad la demanda empresarial de AI API en Telegram
- Un incidente de seguridad en la cadena de modelos: ¿quienes preguntan «cambiamos de ruta» piensan hacerlo de verdad?
- Alguien en el grupo dice «200 dólares al día, 20 personas, lanzamos el miércoles». ¿Se toma ese pedido?
Cómo se descubre una Signal que merece atención
La metodología muestra cómo Top Prospect encuentra y organiza Signals que conviene revisar, conserva el contexto original de Telegram, elimina duplicados y ayuda a decidir qué mirar primero. Tú decides si hacer seguimiento y qué hacer después.