Lo más barato es el trabajo que nunca llega al modelo

Tenemos dos agregadores que cada día leen texto de terceros y emiten un juicio sobre él. Uno sigue las noticias de IA e infraestructura cripto; el otro, lo que discuten los emprendedores indie. Al 2 de septiembre de 2026, sus bases de datos almacenan 62,2 millones de caracteres de material en bruto: 33,2 millones en el primero y 29 millones en el segundo.

Ese es justo el volumen al que uno suele descubrir que la factura del modelo se ha triplicado. La nuestra no subió, y no porque hayamos hecho nada especialmente ingenioso con los prompts. Abajo están las decisiones que de verdad contienen el gasto, y un punto en el que nuestro propio control de costos nos miente.

Antes del modelo hay un filtro que no cuesta nada

El agregador de discusiones tiene ahora 19 264 hilos. Solo 2558 llegaron al análisis del modelo: un 13 %. El resto lo descartaron reglas deterministas que no consultan al modelo en ningún momento:

Lo importante aquí no es el porcentaje: parte de las reglas se aplica a la URL, antes de descargar la página. El spam SEO tiene que llevar su palabra clave en la URL o el esquema entero deja de funcionar, y eso permite identificarlo sin coste alguno, antes de hacer una sola petición de red.

Lo segundo que conviene copiar: el motivo del descarte se guarda en la base de datos como una cadena de texto. No un simple indicador de «descartado», sino iptv-spam o spam-author. Cuando alguien pregunta un mes después si estamos descartando de más, la respuesta es una consulta, no volver a rastrearlo todo.

El corte por fecha va antes de la clasificación, no después

En el agregador de noticias, lo publicado hace más de tres días no llega al modelo. El corte no puede ir antes: la fecha real de publicación solo se conoce cuando ya has bajado la página, así que queda entre la descarga y el modelo. Algunos sitios declaran un lastmod reciente en su sitemap para páginas antiguas; así fue como una vez se nos colaron artículos de 2023. Sin el corte habríamos pagado por leerlos, y de todos modos se habrían descartado en el paso siguiente.

Un paso que sacamos de la API de pago

En las seis semanas hasta el 2 de septiembre, la base del agregador de noticias acumuló 3550 veredictos. 240 se emitieron por la API de pago, casi todos antes del 30 de julio: desde esa fecha el paso de clasificación está fuera de la ejecución diaria, y en su lugar una sesión de trabajo con el modelo lee lo no evaluado y devuelve veredictos que se importan a la misma base. En el agregador de discusiones es así desde el principio: las 1607 notas las escribió una sesión y ninguna pasó por la API. (Hay menos notas que hilos aprobados por el filtro: 951 siguen en cola.)

No es un consejo universal y tiene su precio: el paso deja de ser autónomo. La ejecución programada recoge y limpia; el juicio se emite cuando te sientas a trabajar. Para un boletín semanal encaja; para un producto que responde a un usuario en tiempo real, no.

Dónde nos miente nuestro propio control de costos

Limitar la longitud de la entrada es lo primero que se hace para ahorrar. Nosotros tenemos dos límites y se comportan de forma distinta.

El primero está en la vía de la API de pago: el texto se trunca a 40 000 caracteres, en una sola línea de código. Conviene ser preciso con lo que eso significa. En la base los textos se guardan enteros, los 33,2 millones de caracteres; el recorte ocurre camino del modelo. Si pasáramos hoy todo el corpus por ese límite, no llegarían 9,45 millones de caracteres: el 28,5 % del total, y todos ellos son las colas de los 115 textos más largos, un 2,7 % de las entradas. El límite recorta justo el material más extenso, que suele ser también el más sustancioso. Y en ninguna parte, ni en el log ni en la ficha de la entrada, quedaba constancia de que un texto se hubiera cortado.

El segundo está en la vía de la sesión: a la exportación solo van los primeros cuatrocientos caracteres. Pero justo al lado, en la cabecera de la entrada, está la longitud real del texto, y el corte va marcado con puntos suspensivos.

Esa marca no vino del esmero, sino de una factura. El 9 de agosto de 2026 la nota más alta del lote, 85 sobre 100, se la llevó un fragmento de 265 caracteres de un artículo de CoinDesk: la web entregó el titular con la entradilla y escondió el artículo detrás de un muro de JavaScript. En la exportación, el comienzo de un artículo largo y un fragmento corto entero se veían igual, cuatrocientos caracteres visibles en ambos. Evaluamos la promesa del titular tomándola por el material.

La diferencia entre los dos límites no es el tamaño, sino que uno se declara y el otro no. Es el mismo tipo de defecto que ya nos encontramos en nuestro escáner de DFK Chain: un ahorro que no se ve deja de ser una decisión y se convierte en una distorsión. No quitamos los topes, que están ahí por una razón; llevamos el primero al segundo: desde hoy cada truncado escribe una línea en el log de la ejecución con cuántos caracteres se cortaron y de cuántos.

Los reintentos se definen con tus fallos, no con los del proveedor

Los reintentos del SDK cubren los errores HTTP (429, 500). Lo que vimos era otro: un HTTP 200 con el cuerpo vacío, que hace fallar el parseo de la respuesta. Para el cliente esa es una respuesta correcta, así que el reintento integrado no se dispara. Hubo que poner uno propio: tres reintentos con espera creciente; repetir la misma petición bastaba.

La moraleja general para cualquier integración: lo que tu proveedor considera un fallo y lo que lo es para ti son dos listas distintas. Si coinciden o no, es algo que se comprueba en tus propios logs, no en la documentación.

Lo que no medimos y no vamos a afirmar

Aquí es donde tocaría decir «el ahorro fue de un N por ciento». No tenemos esas cifras y no las vamos a inventar.

• Nunca hemos medido el gasto en dólares. En los agregadores no hay ningún contador de costo: ni en el log ni en un informe. Todo lo anterior se mide en entradas y caracteres.
• No podemos comparar un modelo barato con uno caro sobre nuestros datos. Exactamente 2 de los 3550 veredictos salieron de dos modelos distintos. Con un solapamiento de dos no podemos concluir en qué casos habría bastado el modelo barato.
• Sobre la caché de prompts no tenemos nada que decir. No hemos hecho ni una sola medición.

Las reglas

El trabajo más barato es el que no llega a hacerse. Antes de buscar un modelo más barato y recortar el prompt, conviene mirar qué parte de la entrada necesita un modelo. En nuestro caso resultó ser el 13 %, y lo que lo extrajo no fue la IA, sino un par de docenas de reglas deterministas que la tabla de arriba resume en seis motivos.

Y una segunda regla del mismo peso: todo ahorro tiene que quedar visible en los resultados que consultas. Un texto truncado, una entrada omitida, material descartado por antigüedad: todo eso debe dejar rastro, o el ahorro acabará pasando factura no en dinero, sino en una conclusión equivocada. Esa factura ya nos la hemos pasado nosotros mismos: el 28,5 % del corpus del que el informe no dice nada.

Si estás montando un flujo así y no tienes claro adónde se va el dinero, ese es exactamente el trabajo que hacemos.