Mejores modelos para tool calling en 2026: qué dice el BFCL y cómo elegir sin adivinar

Si tu agente falla, lo más probable es que no falle "el modelo": falla una tool call. Un argumento mal formado, una función inventada, un parámetro con el tipo equivocado. El tool calling es la capa donde el razonamiento se convierte en acción, y es la métrica que mejor predice si un agente aguanta producción. Esta guía usa el Berkeley Function Calling Leaderboard v4 (BFCL, consultado el 3 de septiembre de 2026) para responder una sola pregunta: qué modelo pones detrás de tus herramientas.

Esto no es una comparativa general de modelos —para eso está ChatGPT vs Claude vs Gemini para construir agentes— ni una introducción al function calling —para eso está function calling y tools confiables—. Aquí el foco es estrecho: precisión de llamadas a herramientas, con datos.

Qué mide el BFCL v4 (y qué no)

El BFCL es el benchmark de referencia para function calling porque no mide una sola cosa. La versión 4 puntúa cinco bloques: agentic (búsqueda web y memoria, 40% del score), multi-turn (conversaciones donde el usuario cambia de idea, 30%), live y non-live AST (funciones reales y estáticas, 10% cada una) y medición de alucinación (si el modelo inventa funciones o las llama cuando no toca, 10%). Aparte reporta sensibilidad de formato: qué pasa si cambias el orden de los parámetros o el idioma de las descripciones.

Lo que no mide: tu prompt, tu schema, tus reintentos ni tu lógica de errores. Un modelo cinco puntos arriba en el leaderboard puede rendir peor en tu sistema si tu harness está mal armado. Tómate la tabla como filtro de candidatos, no como veredicto.

La tabla: top del BFCL v4 a septiembre de 2026

Datos del leaderboard oficial, entrada FC (function calling nativo) salvo indicación. La columna de costo es lo que cuesta correr la suite completa del benchmark con ese modelo —un proxy relativo de lo caro que es operarlo, no el precio de tu caso—.

#	Modelo	Score global	Costo de la suite
1	Claude Opus 4.5 (FC)	77.47	~$87
2	Claude Sonnet 4.5 (FC)	73.24	~$44
3	Gemini 3 Pro Preview (prompt)	72.51	~$298
4	GLM-4.6 (FC thinking)	72.38	~$5
5	Grok 4.1 Fast Reasoning (FC)	69.57	~$17
6	Claude Haiku 4.5 (FC)	68.70	~$14
7	Gemini 3 Pro Preview (FC)	68.14	~$225
8	o3 (prompt)	63.05	~$235
11	Kimi K2 Instruct (FC)	59.06	~$6
16	GPT-5.2 (FC)	55.87	~$86

Tres lecturas rápidas. Primera: Anthropic domina el modo nativo — los dos primeros puestos son Claude con FC, y Haiku 4.5 (68.70) ronda a modelos mucho más caros. Segunda: el open weights ya compite — GLM-4.6 con licencia MIT empata prácticamente con Gemini 3 Pro a una fracción del costo de la suite, y Kimi K2 hace lo propio once puestos más abajo con costo de un dígito. Tercera: el score global esconde matices — mira las columnas parciales antes de decidir: un modelo puede ganar en single-turn y caer en multi-turn, que es donde viven los agentes reales.

FC nativo vs modo prompt: el mismo modelo, otro resultado

El leaderboard evalúa cada modelo en dos modos: FC, usando la API nativa de function calling del proveedor, y prompt, donde el modelo recibe las funciones descritas en el prompt y responde con JSON. La diferencia no es cosmética: Claude Sonnet 4.5 pasa de 73.24 en FC a 24.90 en prompt; DeepSeek V3.2 hace el camino casi inverso (53.96 FC vs 56.73 prompt con thinking); Qwen3-235B también rinde mejor con prompt que con su FC nativo (52.15 vs 47.99).

La lección operativa: el par modelo-modo es lo que eliges, no el modelo solo. Si tu stack usa el function calling nativo del proveedor (lo normal con los SDK oficiales), la columna FC es tu tabla. Si tu framework serializa herramientas como texto —varios orquestadores open source lo hacen— estás en el mundo prompt, y el ranking cambia. Antes de migrar de modelo, verifica en qué modo está trabajando tu agente: a veces la mejora más barata es cambiar de modo, no de proveedor.

El costo no es el precio del token

La columna de costo del BFCL es instructiva: correr la misma suite cuesta ~$5 con GLM-4.6 y ~$298 con Gemini 3 Pro en modo prompt. Sesenta veces de diferencia por cuatro puntos de score. En producción la cuenta se compone: precio por token × tokens por llamada (los schemas largos se pagan en cada turno) × reintentos por llamadas mal formadas. Un modelo barato que falla el 10% de las llamadas y reintenta dos veces puede salir más caro —y más lento— que uno caro que acierta a la primera.

Para tu propia cuenta: mide costo por tarea completada, no por llamada. Diez tareas reales de tu agente, cronometradas y con su consumo de tokens, valen más que cualquier tabla de precios.

Protocolo propio de 60 minutos

El BFCL filtra candidatos; tu eval decide. Este es el protocolo mínimo para comparar dos o tres modelos con tus herramientas:

1. Escribe 10-15 casos reales de tu dominio: la pregunta del usuario, las tools disponibles y la llamada correcta esperada (función, argumentos, tipos).
2. Incluye tres trampas: un caso sin tool aplicable (la respuesta correcta es no llamar nada), uno con parámetros ambiguos y uno que exige dos llamadas en paralelo.
3. Corre cada caso 3 veces por modelo con temperatura de producción y registra: llamada bien formada, función correcta, argumentos correctos, tokens consumidos, latencia.
4. Calcula la tasa compuesta: bien formada × función correcta × argumentos correctos. Es el número que predice tu experiencia de usuario; un 90% en cada factor es un 73% end-to-end.
5. Repite con tu schema real, no con uno de juguete: descripciones de parámetros en español, enums largos y tipos anidados exponen diferencias que los casos de laboratorio esconden.

Recomendaciones por caso

• Máxima precisión y el costo es secundario (agentes con dinero o datos sensibles en juego): Claude Opus 4.5 en modo FC. Es el número uno y la brecha con el segundo es real.
• Balance producción (la mayoría de agentes en operación): Claude Sonnet 4.5 FC o Claude Haiku 4.5 FC — casi el mismo score que el líder a mitad o un sexto del costo de suite.
• Presupuesto ajustado o volumen alto: GLM-4.6 (open weights, MIT) o Kimi K2. Self-hosteables, cinco veces más baratos en la suite, y a 4-14 puntos del líder — diferencia que tus reintentos pueden absorber.
• Ecosistema Google: Gemini 3 Pro en modo prompt rinde mejor que en FC según el leaderboard (72.51 vs 68.14); verifica cómo tu SDK invoca las herramientas antes de asumir el modo.
• Multi-turn pesado (agentes conversacionales largos): filtra la tabla por la columna multi-turn, no por el global — ahí el orden cambia.

Preguntas frecuentes

¿El BFCL reemplaza una eval propia? No. Es el mejor filtro público para shortlist, pero mide funciones genéricas. Tus schemas, tu idioma y tus trampas deciden. Corre el protocolo de 60 minutos antes de comprometer un proveedor.

¿Un modelo open weights sirve para tool calling serio? Sí, con matices. GLM-4.6 y Kimi K2 están en el top 15 global y aguantan producción; la brecha con los líderes se paga en tasa de error, no en imposibilidad. Si tu agente tiene reintentos y validación de schema, la diferencia práctica se achica.

¿Cada cuánto revisar la elección? El leaderboard se actualiza con cada generación de modelos; una revisión trimestral basta. Lo que sí conviene automatizar es tu eval propia: si corre en CI, detectas regresiones cuando tu proveedor actualiza el modelo sin avisar.

¿Qué pesa más: el modelo o el schema? El schema mal escrito tumba al mejor modelo: descripciones ambiguas, tipos opcionales sin necesidad, enums infinitos. Antes de cambiar de modelo, audita tus definiciones de herramientas — es gratis y suele recuperar varios puntos de precisión.

El siguiente paso

Elige dos candidatos de la tabla —uno premium, uno económico— y corre el protocolo con tus tools esta semana. Si estás construyendo tu primer agente, el curso gratuito de instalación te deja el entorno listo en una tarde; si ya tienes uno en producción, la guía de evals para agentes convierte este protocolo en un hábito de CI. Y para seguir comparando con criterio, el hub de comparativas y decisiones junta todas las piezas de selección de stack.