A tool-using model fails in three tedious ways: it calls something when nothing applies, it skips a tool it needed, or it fills the arguments wrong. The first two are already written into the model's internal state at the last token of the prompt — before it generates a single character — and reading them takes as few as one or two feed-forward neurons at 0.90–1.00 detection quality, matching dense probes that read 23–627× more features. Nudge the model along those same neurons, but only on requests the probe flags, and needless calls fall 80% while correctly invoking a required tool rises 14.2 points. Nudge every request instead and you just trade one failure for the other.
If you ship tool integrations you already know the shape of these. The user asks something conversational and the model reaches for a function anyway. The user asks something that genuinely needs a lookup and the model answers from memory. Or it calls the right function and gets an argument wrong. The third you can catch with a schema check. The first two only show up as a bad response, a wasted round trip, or a support ticket. Step through them, and note where in the generation each one becomes detectable.
The distinction that matters operationally: the two decision failures — whether to call at all — are legible at the end of the prompt, so you can act on them before paying for generation. Argument correctness is only legible from the generated call itself, and only at 0.86–0.90, so it stays a post-generation check. That is the same place a schema validator already sits.
The usual way to read something out of a model is to fit a classifier over the entire residual stream — thousands of dimensions per layer. This paper instead scores each feed-forward neuron by how much it actually writes into the residual stream, keeps the top few percent for a specific failure mode, and fits a sparsity-encouraging classifier that then discards nearly all of those too. What survives is tiny. Slide the feature budget and watch what it costs you.
Read the neuron counts across the six models. Skipping a required call is carried by 10 to 110 neurons depending on the model, needless calling by 21 to 107, argument validity by 255 to 742 — an order of magnitude more, and detected less well. Decisions are concentrated; correctness is smeared across depth. That difference is the paper's most interesting structural claim.
Here is where it becomes an intervention rather than a monitor. For a given failure mode, take the average of what those neurons write when the model gets it right, subtract the average of what they write when it gets it wrong, and you have a direction. Add a small multiple of that direction during the forward pass and the model's tendency moves. The obvious thing to do is apply it always. The paper's actual contribution is that you must not — you apply it only when the probe says this request is at risk.
The direction is doing real work rather than acting as generic noise. Randomising which neurons get pushed, while keeping the same count and the same per-layer distribution, is largely ineffective: the real direction removes 79–100% of needless calls where the matched-random version removes almost none.
This is the comparison worth remembering. Take one model, suppress its tendency to call tools unnecessarily, and measure two things: how often it still makes a needless call, and how often it correctly invokes a tool that was genuinely required. Apply the correction to every request and the first number falls beautifully while the second falls with it — you have not fixed the model, you have made it shy. Apply the same correction only where the probe fires and both move the right way at once.
The macro numbers: needless calling 13.1% down to 2.6%, and correct invocation of a required tool 68.9% up to 83.1%. The per-model spread is wide — one model's needless calls go to exactly zero, another recovers 43 points of capability from a very low base — but the direction is the same in all six.
If your model is behind someone else's endpoint, none of the mechanism above is available to you. The transferable part is not the probe, it is the architecture around it: score the request for risk first, then spend an expensive correction only where the score is high. Substitute whatever cheap signal you can actually get — a small classifier over the request and the tool list, a logprob check, a fast model asked one question. The economics below are what change when you gate rather than always-on.
And the reason to bother is not the cost. It is that in this paper the unconditional version cost 4.5 points of capability to buy its suppression, while the gated version gained 15.5. A correction you apply everywhere is a correction applied to the requests that were already fine.