Best Model for Tool Calling: Reliability Beats Intelligence

Model selection for agents gets argued on reasoning benchmarks, and that is the wrong frame. In a tool-calling loop the failures that hurt are rarely bad reasoning. They are malformed calls, invented parameters, ignored schemas and repeated identical actions.

A model that reasons brilliantly and emits invalid JSON one time in twenty will produce a worse agent than a model that reasons adequately and never does — because in a twenty-step loop, one failure in twenty means most runs break.

The arithmetic that makes reliability dominant

Per-step reliability compounds. A 99 percent per-call success rate across twenty calls gives roughly 82 percent of runs completing without intervention. At 95 percent per call, it is about 36 percent. At 90 percent, under 12 percent.

That is the entire argument. A few percentage points of per-call reliability swamp any plausible difference in reasoning quality, because reasoning helps linearly and reliability compounds exponentially.

It also explains why models that look similar on single-turn benchmarks diverge wildly as agents, and why long-horizon benchmarks like Terminal-Bench 2.1 separate models that SWE-bench Verified ranks as near-equals. Evaluating agent reliability covers measuring this properly.

What actually goes wrong

Test for these specifically, because aggregate scores hide all of them.

• Malformed structure. Invalid JSON, unescaped strings, trailing commas. Rarer than it was, not gone.
• Schema drift. Valid JSON with the wrong shape — a string where an array belongs, a missing required field, an invented optional one.
• Hallucinated tools. Calling a function that does not exist, often a plausible-sounding neighbour of one that does.
• Parameter invention. Filling a required field with a guess rather than asking or searching. This is the most dangerous because it looks like success.
• Loop repetition. Making the same failing call repeatedly instead of changing approach. Agent error recovery patterns covers detecting this.
• Premature completion. Declaring the task done without running the verification step it was told to run.

How to test before committing

Build a small harness with five tools of varying complexity — one trivial, one with nested parameters, one with an enum, one with optional fields, one that returns errors.

Run two hundred calls per model. Log every call, valid or not. Then measure: schema-valid rate, correct-tool rate, parameter-accuracy rate, and recovery rate after a deliberately injected error.

That last one is the most revealing and the most often skipped. Return an error from a tool and watch what the model does. Good models read the error and adjust. Poor models retry identically, or give up, or invent a workaround that ignores the failure. This behaviour predicts real-world agent performance better than any published benchmark.

What helps regardless of model

Tooling improvements usually beat model upgrades here, and they help whichever model you run.

Fewer, simpler tools. Twenty overlapping tools produce more wrong-tool errors than six clear ones. If two tools could plausibly serve the same request, merge them.

Descriptions written for the model. Say when to use the tool and when not to, not just what it does. The negative case prevents more errors than the positive one.

Validate and return errors the model can act on. "Invalid input" teaches nothing. "Field limit must be an integer between 1 and 100, received 'ten'" gets corrected on the next turn. Tool calling explained covers schema design.

Make retries safe. Idempotent tools mean a repeated call is harmless rather than a duplicate write.

Model guidance

• Long unattended loops — Kimi K3 or GLM-5.2. Both are built for extended agentic work and their long-horizon benchmark results reflect per-step reliability, not just intelligence.
• Short bounded loops, cost-sensitive — DeepSeek V4 Pro. Enough depth for a handful of steps at a much lower price.
• Avoid for agents — the cheapest tier of any family, as the primary loop model. Reliability is exactly what gets cut to reach that price. Use them for single-shot work inside a loop driven by something stronger.

Whatever you pick, instrument every tool call in production. Schema-valid rate and recovery rate are the two metrics that tell you when a model change or a prompt change has quietly broken something.

Reliability is a property of the pairing, not the model

A model does not have a single tool-calling reliability figure. It has one per toolset, and the variation between toolsets is often larger than the variation between models.

The same model that handles six clean tools almost flawlessly will degrade sharply against twenty overlapping ones with vague descriptions. That means a benchmark result measured on somebody else's tools tells you relatively little about how the model will behave against yours.

The consequence for evaluation is that you cannot shortlist from published figures alone. You must run your own tools. The good news is that this is cheap — a few hundred calls against your real schemas costs very little and gives you a number that actually predicts production behaviour.

It also means the first response to poor reliability should be to look at the toolset rather than the model. Merging two ambiguous tools into one, or rewriting a description to say when not to use something, frequently produces a larger improvement than moving up a model tier, at no additional running cost.

Watch for silent regressions

Tool-calling reliability degrades quietly. Nothing errors loudly; runs just start needing more intervention, and the change is gradual enough that nobody attributes it to anything.

Three things cause it. A provider updates the model behind a stable alias. Someone adds a tool, pushing the toolset past the point where descriptions stay distinct. Or the system prompt grows until the tool instructions are buried in the middle of a long preamble, where attention is weakest.

Guard against all three by tracking schema-valid rate and recovery rate as production metrics with alerting, not as one-off evaluation numbers. A change in either is the earliest signal that something moved underneath you.