
Sé perfectamente el dÃa en que entendà por qué mi cuenta de API se disparaba. Corrà un agente con una tarea de unas veinte lÃneas y al revisar el usage vi la wea: 800 tokens de respuesta, 40.000 de razonamiento. El modelo no estaba respondiendo; estaba pensando en voz alta y yo pagando cada pensamiento.
El costo escondido de los modelos que piensan
Los modelos de razonamiento gastan la mayorÃa de sus tokens —a veces más del 90%— en pensamiento interno, no en la respuesta. En una llamada suelta es molesto. En un flujo agéntico es una estafa matemática: cada vuelta le reenvÃas todo el razonamiento previo al modelo, asà que el contexto crece casi cuadrático con la cantidad de pasos. El razonamiento largo del turno uno se relee y se refactura en cada llamada posterior. Traducción chilena: mientras más se enreda el agente, más caro se pone el enredo.
La respuesta obvia de la industria fue ponerle un tornillo: bajar el «reasoning effort» y listo. Cualquiera que lo haya intentado sabe cómo termina. Bajas el esfuerzo, el modelo deja de dudar y de reconsiderar, y la calidad se cae por la borda. No es lo mismo pensar rápido que pensar mal, pero los knobs de configuración te obligan a elegir entre las dos cosas.
La solución era entrenarlo, no configurarlo
Por eso me llamó la atención lo que hizo Fireworks con Ember-1: partieron de Kimi K3, un modelo de razonamiento, y en vez de pedirle que piense menos con parámetros, lo entrenaron para que piense menos. Más de 50 experimentos de entrenamiento para que el modelo aprenda a distinguir la reflexión que sirve —retomar una suposición, corregir en base a feedback— del loop inútil de «ya lo intenté y no funcionó, déjame intentarlo igual pero con otras palabras».
El resultado es incómodo para quien vendÃa tokens: misma calidad con un 40% menos de tokens. En benchmarks de código como SWE-bench Verified quedó casi clavado con el modelo base a máximo esfuerzo, y en pruebas A/B en producción real de clientes, un 35% de ahorro por tarea. El detalle que más me gustó: cuando corrÃan el modelo internamente con sus propios desarrolladores, nadie se dio cuenta del cambio. Cero noticias. Para un modelo cuya única promesa es «las mismas respuestas, menos tokens», que nadie note el cambio es la mejor validación posible.
Lo que esto significa para quien corre agentes
Yo tengo agentes corriendo en cron, haciendo pegas repetitivas mientras duermo. Cada uno consulta APIs de modelos que razonan, y el presupuesto mensual crece con cada tarea. He visto sesiones donde el modelo entra en un bucle de autocrÃtica que no aporta nada y donde el 80% de la factura es el modelo dudando de sà mismo. Con razonamiento a $15 por millón de tokens de salida, un loop mal cerrado cuesta más que el trabajo que estaba automatizando.
La lección que me llevo es simple y un poco incómoda: el ahorro ya no está en apagar el razonamiento, está en modelos especializados que aprendieron a razonar eficientemente. La forma más barata de correr un modelo grande dejó de ser «configurar menos esfuerzo» para pasar a ser «usar la versión que aprendió a pensar menos sin pensar peor». Es la diferencia entre pedirle a un becario que no piense tanto y contratar a alguien que ya sabe cuándo vale la pena pensar.
Si tu cuenta de IA se te está comiendo el presupuesto, hazme caso: mira cuánto de eso es razonamiento interno. Probablemente estás pagando caro por un modelo dudando en voz alta sobre cosas que ya resolvió hace tres turnos.
Fuente de inspiración: Introducing Ember-1 (Fireworks AI)