Beacon 8B ranks first on 11 of 13 vision-agent benchmarks

A new arxiv paper posted this week reframes something a lot of people building visual agents have privately suspected. When you take an open-source multimodal model and give it tools to crop, zoom and inspect an image, the gains on hard problems tend to be roughly cancelled out by the model reaching for tools on easy problems it could already solve. The Beacon paper puts a name to that failure mode and reports a training-time fix.

The authors split tool use into two axes they call Mode Adaptiveness and Tool Effect. Mode Adaptiveness asks whether the model knows when to reach for a tool at all. Tool Effect asks whether the tool call actually helped. Measured across existing open-source agentic vision models, they report that "Tool-Gain does not substantially exceed Tool-Harm," which is a polite way of saying the net effect of tool use in current systems is close to zero.

Their proposed fix is a reward-shaping recipe applied during reinforcement learning: a Necessity-Aware Adaptive Reward that only encourages tool calls when they are actually necessary, paired with a Hint-Guided Capability Expansion mechanism aimed at the hardest problems. Applied on top of Qwen3-VL-8B-Instruct, the resulting model, Beacon-RL-8B, is reported to rank first on 11 of the 13 benchmarks tested and to beat the base model by an average of 6.07 points across a suite that spans high-resolution visual search (V*, HRBench), spatial reasoning (RealWorldQA, BLINK) and chart and math reasoning (ChartQAPro, MathVista, MathVision). At inference, Beacon writes Python for image cropping, annotation, rotation, stitching and numerical work.

Why this matters if you are not training vision agents yourself: the pattern the paper diagnoses, tools invoked as reflex rather than as need, is exactly what makes hosted agent stacks slow and expensive. If reward shaping at RL time can make tool use net-positive for an 8B open model, the economics of running a decent visual agent on your own hardware get better in a real way.

The honest caveats are the usual ones. These are self-reported numbers on the authors' chosen benchmark set, and on the closed-source side the paper compares only against Gemini 3.1 Pro. What the write-up doesn't give you is any serving-cost or latency accounting for the extra Python invocations, or evidence that the recipe transfers to non-visual tool-using agents. But the direction, teaching a small model when not to reach for a tool, is the part worth watching.