Beacon: your tool-using AI model is making easy questions harder

Ask a multimodal model a question it can already answer, and the decent thing to do is answer it. Too many agentic reasoning models, argues a new paper from KlingTeam, would rather call a tool first. The cost is measurable: extra compute on problems that never needed help, and more chances to introduce errors where the model was already right. The same pattern shows up in coding agents: Cursor's swarm rebuilt SQLite with the same scores and wildly different bills.

Posted to arXiv on July 30, 2026, the paper, "Beacon: Knowing When and How to Perform Agentic Visual Reasoning," rethinks how multimodal large language models (MLLMs) should use tools in visual reasoning. Its central claim is that the goal is a better success rate on complex tasks, not a fancier reasoning pipeline. Building an agent that chains tool calls on every question misses the point when a direct answer would have done.

The two dimensions of tool use

The authors propose two properties for evaluating agentic visual reasoning. Mode Adaptiveness measures whether a model can recognize when tools are genuinely necessary and invoke them accordingly, which avoids unnecessary computational overhead while improving performance on challenging problems. Tool Effect measures the actual impact of tool use: tools should extend the model's capabilities on problems that text-only reasoning cannot solve, while avoiding additional errors on problems the model can already handle without them.

Their analysis of existing agentic visual reasoning models finds both properties lacking. The models show limited Mode Adaptiveness, and the gains from tool use on hard examples are largely offset by the harm introduced on easy examples the models could already solve. That pattern echoes SceneActBench, which found even the best VLMs fail at 3D action tasks. In other words, the industry's instinct to bolt tools onto everything is not just wasteful. It can actively degrade accuracy on the simplest cases, which usually make up the bulk of real traffic.

Why Beacon behaves differently

Beacon is built from those two observations rather than from a bigger toolbox. Its training uses reinforcement learning with two mechanisms at the core: a Necessity-Aware Adaptive Reward and a Hint-Guided Capability Expansion. The first encourages adaptive tool invocation based on task necessity. The second strengthens the model's tool-use capability on the most challenging problems.

The design reads as an incentive problem as much as a model architecture problem. If a model is rewarded purely for correct answers, it never internalizes the cost of an unnecessary tool call, so it keeps making them. Beacon's reward structure makes restraint part of the training signal, and reserves tool training for the cases that genuinely need it. That is the same intuition behind giving AI models a coach rather than just a score.

Across diverse benchmarks, the authors report that Beacon improves overall performance and both Mode Adaptiveness and Tool Effect. The gains come from the tools themselves, not from tool calls that merely change how a correct answer is reached. That distinction matters because a diagnostic benchmark found over half of AI reasoning is froth.

The practical takeaway

The paper's most useful contribution may be the evaluation lens. Anyone building agents on top of an MLLM is familiar with logs full of tool calls for questions a human would answer in one line. Beacon's framework turns that annoyance into two measurable numbers, which lets a team tell whether its agent is using tools as leverage or as a crutch. When the tool-effect number is close to zero, the tool layer is decoration. That kind of diagnostic is especially timely as the industry retires saturated benchmarks like MMLU and GSM8K.

None of this argues against tools. Some problems cannot be solved through text-only reasoning, and the paper is explicit that tools should extend the model's reach on exactly those. The point is calibration: the best agent is not the one that can do the most, but the one that knows the difference between what it can do and what it must fetch.