The Berkeley Function Calling Leaderboard is one of those benchmarks that quietly became infrastructure. When someone says a model is "good at tool use," they usually mean it ranks well on BFCL — the Gorilla team's benchmark for whether an LLM emits the right function, with the right arguments, of the right types, and doesn't hallucinate a function that was never on the menu. So it's worth noticing what BFCL did to itself in v4: it demoted the exact thing it was built to measure.

Read the weights, not the ranking#

Most people read a leaderboard top-to-bottom and stop. The more revealing document is the scoring formula. In BFCL v4, the overall number is:

The "classic" BFCL — single, multiple, and parallel function calls scored in isolation — is what Live and Non-Live cover. Together they are 20% of the score. The benchmark that made its name on single-shot function-calling accuracy now spends 70% of its weight on agentic and multi-turn behavior instead.

When a benchmark stops trusting its own headline metric, that's a finding.

The reason is unsentimental: single-turn accuracy saturated. Once the frontier models cluster in the high 0.9s on "given these tools, emit the right call," the metric stops discriminating — everyone passes, so it can't tell you who's better. The interesting variance moved to the parts of tool use that are still hard.

Where the difficulty actually lives now#

The Multi-Turn track (30%) runs roughly 800 examples across four conditions — Base, Missing Functions, Missing Parameters, and Long Context — and asks whether a model can keep using tools correctly across a conversation, not just in a single clean shot. "Missing Functions" and "Missing Parameters" are the sharp ones: they check whether the model notices that it can't complete the task with what it's been given, instead of confidently calling a tool that doesn't exist or guessing an argument.

The Agentic track (40%) goes further, scoring three capabilities that a JSON-emitter never had to have: web search (going out to retrieve information it doesn't hold), memory (managing persistent, user-specific state across a session), and format sensitivity (not falling apart when a tool schema or output format shifts under it). This is the part of "tool use" that looks like a working agent rather than a parser.

Crucially, BFCL keeps its trust anchor through all of this: it scores with AST matching and state-transition checks, not an LLM judge. It parses the proposed call into a syntax tree and verifies it structurally, and for multi-turn/agentic tasks it checks the resulting state. That's why BFCL numbers are deterministic and reproducible — and it's also the benchmark's honest limit. AST matching tells you a call was well-formed and correct against the expected answer; it was never designed to tell you the call was wise. The v4 state-transition and agentic checks are Berkeley's attempt to reach past syntax toward judgment.

The hardest 10% is doing nothing#

The most telling category is the smallest. Hallucination (10%) measures whether a model correctly declines to call any function when the user's request doesn't match the available tools. It's a test of abstention — the discipline of returning nothing.

That sounds trivial and is brutally hard, for a structural reason: the models topping this leaderboard were instruction-tuned and then tool-tuned specifically to produce calls. Refusing to act is out-of-distribution for them. A model that has been rewarded thousands of times for emitting a function will reach for one even when the right move is to say "I can't do that with these tools." Teaching a tool-happy model to keep its hands in its pockets is one of the genuinely open problems, which is why it earns its own slice.

What to actually do with a BFCL rank#

For anyone shopping for a model, the practical translation is: a high BFCL v4 score no longer means "emits clean JSON." It means multi-turn competence, agentic capability, and — if the model scores well on Hallucination — the judgment to abstain. That's a better proxy for a production agent than v1 ever was.

But keep the benchmark in its lane. BFCL scores curated tasks with deterministic checks; it is complementary to something like tau-bench, which simulates a whole policy-constrained conversation and grades the end state. BFCL asks was each call right; tau-bench asks did the interaction reach the right outcome. And neither measures whether the model does the right thing every single time on your stack — that's a pass^k reliability question you have to run yourself.

The through-line is that "function calling" was always two skills wearing one name: the syntax of a call, and the judgment of whether to make it. BFCL spent its first three versions perfecting the measurement of the first. v4 is the admission that the second is the one that was ever going to matter.