El análisis de comida por foto en TrainO se volvió casi 2x más lento sin que hubiéramos hecho ningún deploy. No cambió el código. Cambió el comportamiento del proveedor del modelo: empezó a devolver el JSON pretty-printed. En platos con varios ítems, la respuesta empezó a chocar contra el límite de 1024 tokens de salida, y cada respuesta truncada activaba un retry con el modelo más caro. Resultado: las escalaciones pasaron de 0% a 29% en pocos días.

El aprendizaje fue simple: un límite de tokens de salida no es necesariamente un mecanismo de ahorro. Si lo aprietas demasiado, no reduces costo: solo conviertes una respuesta incompleta en un segundo intento completo, más lento y más caro.

El fix fue menos glamoroso, pero más correcto: subimos el cap de salida, forzamos JSON minificado (entre 30% y 50% menos tokens de salida) y dejamos de descartar respuestas truncadas — ahora rescatamos los ítems completos antes de decidir si hace falta escalar. También agregamos trazabilidad por registro: timings, outcome, modelo usado, fallback aplicado y causa de truncación. La próxima vez, el diagnóstico no será intuición. Será un query SQL.