A reasoning upgrade is sold as an across-the-board capability gain. Tool-call reliability does not come along for free — it is a separate axis, and the dominant RL recipes have been shown to make tool-call hallucination worse even as task scores climb.
A team runs a tool-using agent in production and decides to make it smarter. The plan is the obvious one. Swap the model underneath for a stronger reasoning model, or run a reinforcement-learning pass on the agent’s own traces to push up the task-completion score. The benchmark moves the way everyone expects — the agent solves more of the suite, the multi-step tasks that used to stall now finish, the number on the slide goes up and to the right. By every measurement the team took, the upgrade worked.
Then the production logs start to look strange. The agent calls a tool that is not in its toolset — a plausible name, a sensible signature, and no such function. It invokes a search tool on a turn where the answer was already in context and nothing needed to be fetched. It reports back a tool result — a lookup completed, a value returned — for a call it never made. None of this is a crash. The agent is articulate, the reasoning reads well, the final answers are mostly right. But it is fabricating tool calls, and it is doing so more often than it did before the upgrade. The team is confused, because they did not break the model. They made it better.
Both things are true at once, and that is the whole problem. The model did get better at reasoning, and it got worse at tool calling, in the same training run. The team’s mistake was not the upgrade. It was the assumption underneath the upgrade — that “smarter” is one number, that a gain in reasoning is a gain everywhere, that tool-call reliability rides along for free on the back of a better model.
This post is about why tool-call reliability is a separate capability axis from reasoning quality — trained by different signals, measured by different metrics, free to move independently of task score and, under the dominant RL recipes, measured to move in the opposite direction.
The mistake is a bundling error, and it is worth naming precisely, because the word “capability” invites it.
It is tempting to treat a model’s ability as a single quantity — a level, a tier, a generation — that rises or falls as a block. Under that picture, a stronger reasoning model is strictly better, and an agent built on it inherits the improvement across the board. Tool calling is just one more thing the model does, so a better model does it better. The picture is clean, it fits how upgrades are sold, and it is wrong.
Reasoning quality and tool-call reliability are different skills. Reasoning quality is the model’s ability to decompose a problem, hold intermediate state, and chain steps toward a correct answer. Tool-call reliability is something else entirely: the model’s discipline about the boundary between what it knows and what it must look up — calling a tool that exists, calling it only when a call is actually needed, and not narrating a result it never received. The first is about thinking. The second is about restraint, and about an honest accounting of the model’s own ignorance. A model can be excellent at one and poor at the other, because nothing ties them together except the hope that they are tied.
They are not even trained by the same signal. Reasoning is improved by rewarding correct final answers — the model that reaches the right conclusion gets reinforced, and over many steps learns to reason better. Tool-call reliability is a different target: it is improved by rewarding the model for calling the right tool, abstaining when no tool fits, and not inventing outputs. An optimizer pointed at task completion is pointed at the first target, not the second — and an axis nobody is optimizing is an axis free to drift, or to be dragged the wrong way by the optimization aimed at its neighbor.
The separateness is not merely that the two skills are independent. Under joint training they interfere — and the interference has been quantified.
Reasoning and Tool-use Compete in Agentic RL: From Quantifying Interference to Disentangled Tuning (arXiv 2602.00994) trains a model with reinforcement learning on reasoning and on tool use at the same time, the way an agent RL pipeline naturally does, and watches what happens to each. What it finds it calls a seesaw phenomenon: pushing tool-use performance up degrades reasoning, and pushing reasoning up degrades tool use. The two do not rise together. They trade against each other, and the trade is not an accident of the data — the paper traces it to gradient conflict, the reasoning tokens and the tool-use tokens pulling the model’s parameters in directions that partly cancel.
Read what that mechanism implies. If reasoning and tool calling were one capability, training on one would help the other, because the gradients would align. They do not align. They conflict — the signature of two distinct skills sharing one set of weights and competing for them. The seesaw is what a separate axis looks like from the inside of a training run.
The paper’s fix is the tell. Its method — DART — stops training the two skills through one undifferentiated update and disentangles them into separate low-rank modules, so the reasoning gradient and the tool-use gradient stop fighting over the same parameters. Disentangled that way, the model improves on both at once: a +6.35% average exact-match gain across seven tool-augmented question-answering benchmarks, relative to the entangled baseline. The lesson is not the method. It is what made the method necessary — you had to pull the two skills apart to improve both, because together they were holding each other down. A capability you have to separate in order to train is, by definition, not one capability.
So when a team runs a single RL pass to lift task scores and assumes tool calling came along, they are assuming the seesaw does not exist. The research says it does, and that the side they were not watching is the side that goes down.
The seesaw says the two axes can move in opposite directions. The next question is the one that decides whether this is an abstract concern or a production one: under the RL recipes teams actually run to raise task scores, which way does tool-call reliability move? The literature has a direct measurement, and a broader echo.
The direct measurement is The Reasoning Trap: How Enhancing LLM Reasoning Amplifies Tool Hallucination (arXiv 2510.22977). The setup is exactly the team’s: take a tool-using agent, run reinforcement learning to improve it, measure tool-call hallucination as the training proceeds. The diagnostic is a benchmark called SimpleToolHalluBench, built over 296 tools, that probes the two failure modes that matter — the No-Tool-Available case, where the right move is to abstain because nothing in the toolset fits, and the Distractor-Tool case, where a tempting but wrong tool is on offer. The model under test is ReCall-7B, built on a Qwen2.5-7B base, trained with GRPO.
The result is the post’s title, measured. As RL training proceeds, tool-call hallucination rises monotonically with the number of RL steps — not a blip, not a phase, a steady climb that tracks the training. On the No-Tool-Available task, hallucination rises from 34.8% to 90.2%. On the Distractor-Tool task, it rises from 54.7% to 100.0% — by the end of training the model fabricates a tool call every single time a plausible distractor is present. And here is the part that ties it to the team’s confusion: over the same run, the BFCL Multi-Turn tool-calling score improves from 13.6 to 23.5. The task metric and the hallucination metric rise together. The team watching only the task score sees a genuine improvement and an invisible regression, in the same model, from the same training.
Two details in that paper close the obvious escape hatches. The first: the effect is not overfitting to tool-related training data. The authors train on GSM8K — grade-school math, with no tool-use supervision anywhere in it — and tool-call hallucination still rises. A training signal with nothing to do with tools degraded the model’s tool discipline, which is only possible if reasoning RL has a general pull on that discipline. The second: the paper’s own mitigation, a DPO-based correction, does reduce hallucination — but it costs task utility. That is the reliability-versus-capability trade stated as a measured result. You can buy back tool-call reliability, and the price is on the task score.
The broader context comes from Reasoning Models Hallucinate More: Factuality-Aware Reinforcement Learning for Large Reasoning Models (arXiv 2505.24630). Be precise about its scope before quoting it: this paper measures factual hallucination — wrong answers on question-answering — not tool-call hallucination. With that label firmly attached, its finding rhymes with the one above. Reasoning-oriented RL fine-tuning significantly increases the prevalence of hallucinations; the paper’s fix, FSPO, lifts HaluEval-QA from 48.0% to 83.0% and TruthfulQA from 38.2% to 58.4% on a Qwen2.5-7B-Base model. The relevance is not that it proves the tool-call effect — it does not, and you should not say it does. It is that reasoning RL having a hallucination-amplifying pull is not a one-off in a single corner: it shows up for factual QA and, separately and specifically, for tool calls. Two different failure surfaces, the same training pressure pushing the wrong way.
There is also a quieter point about where the tool-need decision lives. LLM Agents Already Know When to Call Tools — Even Without Reasoning (arXiv 2605.09252) studies tool over-calling — the decision of whether a tool is needed at all — and finds that whether a tool is needed is linearly decodable from a model’s pre-generation hidden states at AUROC 0.89 to 0.96 across six models, substantially exceeding the model’s own verbalized reasoning; it also finds that Reason-then-Act prompting incurs a disproportionate accuracy cost on hard tasks. Keep this scoped: it is about over-calling and the tool-need decision, not tool-call hallucination. But it sharpens the separate-axis point from another direction — the signal for “should I call a tool” sits in the model’s representations independent of, and better than, the chain of reasoning it writes out. The reasoning trace is not where the tool decision is best made, which is one more reason a better reasoning trace is not automatically a better tool decision.
The heading limits the post’s own claim, and the limit is the whole difference between a finding and an overreach.
“The Reasoning Trap” is one paper, and one paper is easy to inflate into a universal law: RL-tuned reasoning models hallucinate tool calls more, full stop, every recipe, every time. That law is not what the literature supports, and stating it would be overreach.
The paper that forces the qualification is Are Reasoning Models More Prone to Hallucination? (arXiv 2505.23646). It asks the same question — does turning a model into a reasoning model make it hallucinate more — and finds the answer depends on how the reasoning model was made. Large reasoning models that undergo a full post-training pipeline, with cold-start supervised fine-tuning followed by verifiable-reward RL, generally alleviate hallucination. The ones that get worse are made differently: distillation alone, or RL training without the cold-start supervised fine-tuning, introduces more hallucination, and more nuanced hallucination. Same caveat as before — this is factual hallucination, not tool-call. But the structural point carries regardless: whether RL “amplifies” hallucination is not a property of RL but a property of the recipe. A complete pipeline with a supervised cold start and a verifiable reward can push hallucination down. A truncated pipeline pushes it up.
So the defensible claim is narrower and more useful than the universal law. It is not “reasoning models hallucinate tool calls more.” It is this: the dominant tool-RL and outcome-RL recipes — the ones a team reaches for when the goal is to lift the task-completion score, often outcome-rewarded and often without a careful supervised cold start — are the recipes measured to amplify tool-call hallucination. A different recipe can land differently. The amplification is real, it is measured, and it is conditional.
Two more limits belong here. First, the tool-call version of the effect — hallucination rising specifically in tool calls, monotonically with RL steps — currently rests on one direct study, “The Reasoning Trap.” It is a careful study with a purpose-built benchmark and the overfitting hatch closed, and one rigorous measurement is worth far more than a vague consensus. But it is one. Do not write as though a stack of papers all independently measured the tool-call amplification; one did, and the others are about factual hallucination or the tool-need decision. Second, “reasoning” and “RL” are broad words covering many architectures and training procedures, and a finding on a 7B Qwen model trained with GRPO does not automatically transfer to every model and every pipeline.
What survives all of that — what does not depend on the recipe, the model, or which paper you weight most — is the separate-axis claim. Reasoning quality and tool-call reliability are different capabilities. A reasoning upgrade does not come with a tool-reliability guarantee attached, and under common recipes it has been measured to come with the opposite. That is the durable, defensible thesis, and every recommendation below follows from it rather than from the universal law the evidence does not support.
You cannot get tool-call reliability for free by buying a smarter model. You can stop assuming you got it, and start measuring and training it as the distinct thing it is.
Measure tool-call reliability as a first-class metric, separate from task score. Task completion and tool-call reliability are two axes, so they need two numbers. Track hallucinated tool calls — calls to tools that do not exist — as their own rate. Track unnecessary calls — a tool invoked when the answer was already available — as their own rate. Track fabricated results — a tool output narrated for a call that never executed — as their own rate. A dashboard that shows only task completion is showing one axis of a two-axis system, and “The Reasoning Trap” is the proof that the hidden axis can be moving the wrong way while the visible one looks healthy.
Re-measure tool reliability after every model swap and every RL pass — do not assume the upgrade improved it. The whole failure in the opening scenario is the inference “the model got better, so tool calling got better.” Refuse to make that inference. When you change the model underneath the agent, or run a training pass to lift task scores, the tool-reliability numbers from before the change are stale. Run the tool-hallucination evaluation again, on the new model, and compare. An upgrade that raises task score and raises tool hallucination is a real possibility the literature has measured — your evaluation is the only thing that will tell you which upgrade you got.
Watch for the reliability-versus-capability trade, and decide it on purpose. The mitigation in “The Reasoning Trap” reduced tool hallucination and cost task utility. That trade does not resolve itself. If you tune for tool-call reliability, expect a possible cost on the task metric; if you tune hard for the task metric, expect a possible cost on tool reliability. The mistake is not making the trade — it is making it unconsciously, by optimizing one number and never looking at the other. Put both numbers in front of whoever owns the agent, and let them choose where on the curve the product should sit.
Prefer disentangled training when you train both skills. If you are running RL on an agent and the pass touches both reasoning and tool use, the seesaw in arXiv 2602.00994 says an undifferentiated update will have the two skills fighting over the same parameters. Disentangling them — separate modules, separate adapters, so the reasoning gradient and the tool-use gradient stop canceling — is what let that paper improve both at once. You do not have to adopt one specific method, but you should stop assuming a single joint objective improves both skills uniformly. It has been measured not to.
Prefer the full recipe — supervised cold start, then verifiable reward — over a truncated one. The qualifier paper, arXiv 2505.23646, found that a complete post-training pipeline with a cold-start supervised stage and a verifiable-reward RL stage tended to reduce hallucination, while distillation alone or RL without the cold start increased it. If you have a choice over the recipe, the recipe that includes a careful supervised cold start and a verifiable reward is the one with the better-measured hallucination behavior. The amplification is recipe-dependent — so the recipe is a lever you control.
Gate tool calls on the toolset, not on the model’s confidence. A reasoning model that has learned to fabricate plausible tool names will write a plausible tool name. The cheap, deterministic backstop is to validate every tool call against the actual registered toolset before it executes, reject calls to tools that do not exist, and surface the rejection rather than letting the agent narrate around it. This does not fix the underlying tool-discipline regression — it makes a fabricated call fail loudly instead of becoming a fabricated result. Tool design that makes this validation natural is the subject of tool design for agents; the point here is that the validation belongs in the harness, not in a hope about the model.
Before you assume a reasoning or RL upgrade improved your agent’s tool calling:
A reasoning upgrade buys you a model that thinks better. It does not, by that fact, buy you an agent that calls tools more honestly — those are two skills, they are trained by two signals, and the research has watched them move in opposite directions in a single training run. The agent benchmark going up tells you the task axis improved. It tells you nothing about the other axis, and the other axis is the one your agent’s tools live on. Measure it separately, or you are flying with one instrument and calling it the whole panel — the same way a benchmark score gets mistaken for a reliability measurement, and the same way a fluent reasoning trace gets mistaken for a correct process. When the agent finally fabricates the tool call that matters, the observability you wired in is what will tell you the upgrade did this — if you were measuring the right axis to see it.
A compression method that costs four tenths of a point on a benchmark average looks free. The average is the trap: it blends the capabilities compression leaves intact with the ones it quietly destroys — and the ones it destroys are instruction-following and long-context retrieval, the capabilities you shipped the model to have.
12 min →
One discrete token stream is asked to be both the language model's vocabulary and the vocoder's input — two objectives in direct conflict. The newest codecs concede it by splitting into two streams. The tokenizer choice silently caps either intelligence or fidelity.
13 min →
Word-skips, stutters, and infinite babble in neural TTS are not noise to average away — they are a cross-attention alignment failure that fires hardest on long sentences, and a near-perfect mean WER certifies the model that fails them as fine.
14 min →