All tested LLMs fail to detect Toolcall_Redundancy because silent duplicate tool calls produce no error signal

Auto-published from arXiv:2609.12345 by the mine-arxiv pipeline. Reviewed by an LLM judge (Sonnet) against the archive bar — see CONTRIBUTING. Notes: cleared review (confidence 0.82, flags: [vague-model])

Category

tool-misuse

Model

GPT-4o, Claude Opus 4.6, Qwen3-32B, and 13 others (full list in paper)

Surface

agent harness (multi-turn parallel tool-use)

Setup

ParaRecover benchmark instances where the injected error type is Toolcall_Redundancy — an agent emits a superfluous duplicate tool call that executes successfully and returns a valid result, so no execution-level error fires. The benchmark's 14-type taxonomy was derived from real agent rollout traces. The paper states: 'Redundant calls are hardest to identify as they lack explicit execution failures.'

Reproduction anchor

code: https://github.com/gbw206/ParaRecover — filter dataset by error_type=Toolcall_Redundancy; benchmark spans LEVEL-1 and LEVEL-2

Observed behavior

Across all 16 tested LLMs, Toolcall_Redundancy instances produce the lowest diagnostic recovery rates. Because the redundant call returns a valid response, models receive no signal that triggers reflection, and all models fail to identify the call as erroneous.

Expected behavior

Agents should cross-check their call history against the task plan and detect that a tool was already called for the same subtask, then consolidate or skip the duplicate invocation.

Reproducibility

high

Threat model

In autonomous agent pipelines (e.g., cloud API orchestration, file-write agents), undetected redundant tool calls can waste compute/API quota and introduce double-write or duplicate-transaction side effects invisible to downstream monitoring or the model itself.

Novelty

Identifies a structurally implicit failure class — no error signal fires — that defeats standard error-driven reflection loops, showing that state-of-the-art agents are categorically blind to a whole class of self-inflicted execution errors.

Source

• arXiv: 2609.12345
• PDF: https://arxiv.org/pdf/2609.12345
• Categories: cs.LG, cs.SE
• Authors: Bowen Guan, Zhentao Yin, Yanming Shen

Triage notes (auto)

• paperType: benchmark
• estimatedCaseCount: 3
• triage reason: Benchmark of 14 error types across 10,626 instances, with documented failures in multi-turn error propagation, implicit tool-use failures, and replanning—distinct failure patterns worth archiving.

─────────────────────────────────────────────────────────────────────