Los modelos que cuentan bien las filas que devuelve una herramienta son los que más tokens gastan

Un benchmark publicado en Kaggle pone a prueba un paso que casi todo agente ejecuta y casi nadie mide: contar lo que devuelve una herramienta. Diez modelos respondieron las mismas 68 preguntas de recuento contra dos versiones de una misma función. Con la que entrega el número ya calculado, todos menos uno aciertan. Con la que entrega la lista de ids, el rendimiento se parte en dos.

El montaje está en el repositorio del benchmark. La herramienta count_ids devuelve el conteo exacto junto al mínimo y el máximo; list_ids devuelve los ids que cumplen el filtro. En las dos primeras tareas los ids no aparecen en el prompt, así que la única diferencia es si la herramienta responde con un número o con una lista. Hay una tercera tarea con run_python y los ids ya definidos. Cada tarea lanza 68 preguntas: listas de 11, 110 y 330 ids, siete formas de enunciar el umbral ("10 o más", "no menos de", "menos de", "entre 5 y 9 inclusive"), tres semillas y los once ids originales repetidos cinco veces. Todos los umbrales son ids presentes en la lista, así que > y >= nunca dan lo mismo.

Con el número en la herramienta, todos aciertan

Todos menos uno respondieron bien las 21 preguntas sobre 330 ids, con un gasto de 35 a 451 tokens de salida por pregunta que apenas se movía entre 11 y 330 ids. Traducir "no menos de 244" a id >= 244 y devolver la cifra es algo que estos modelos hacen de forma fiable. La excepción fue gpt-oss-20b: falló 5 de las 68 preguntas de esta tarea con un número distinto al que le había dado la función, siempre 0, 1 o 2, y en una ocasión ni llegó a llamarla.

Con la lista, el gasto manda

Ocho de los diez contaron bien las 26 preguntas de 11 ids. A 330 ids, cinco de esos ocho acertaron 10 o menos de 21. Ninguno devolvió un error ni un matiz: cada respuesta era un número suelto y seguro.

El corte va por tokens, no por tamaño ni por precio. Los que aciertan gastan entre 2.700 y 8.200 tokens de salida por pregunta y clavan de 15 a 21 de las 21 listas. Los que responden con menos de 600 tokens aciertan entre 0 y 10. Gemma 4 26B, un modelo de pesos abiertos, gastó 8.153 tokens y contó 20; Claude Opus 5, el más caro de la comparativa, gastó 579 y contó 9. GPT-5.4 nano se quedó en 35 tokens por pregunta con listas de 11, 110 y 330 ids, margen escaso para contar nada.

El sobrecoste frente a la herramienta de conteo llega a 18,6 veces en Gemma 4 26B y 13,5 en Gemini 3.7 Flash. En el otro extremo, Claude Haiku 4.5 se queda en 1,5 veces y GPT-5.4 nano en 1,7.

Dos avisos de método. Las cifras de los Claude con la herramienta de filas vienen de una ejecución del 25 de septiembre, porque la del 28 se quedó sin cuota diaria. Y GPT-6 Astra no entró: el proxy le niega las function tools. Gemini 3.5 Flash-Lite y los dos Qwen 3 Next 80B devolvieron 429 o 503 en la mayoría de las llamadas.

Lo incómodo del resultado es que el fallo no se ve. El agente manda la consulta correcta y responde con un número firme, sin error ni duda, y ese número es falso. Para quien monta un agente sobre una base de datos o una API, la decisión de diseño está en si la herramienta devuelve el recuento ya hecho o la lista cruda, y en cuánto presupuesto de salida está dispuesto a pagar por la segunda. La ficha del benchmark tiene las ejecuciones completas.