Imagine you're a surgeon scrubbing in for a complex multi-stage operation, but between each stage someone wipes the whiteboard where you've been tracking your surgical plan. Some surgeons barely notice — they reconstruct the plan from context clues. Others fall apart completely. The question this paper asks is: when reasoning models lose their chain-of-thought history between turns in a multi-step tool-calling session, how much does performance degrade? The answer is not 'it depends on the task' — it depends on the model, full stop. The committed claim: deletion sensitivity — the performance delta when a reasoning model's prior-turn traces are stripped away — is a stable, measurable property of the model itself, not of the deployment, the task distribution, or the seed. Across seven open-weight reasoning models, three rendering conditions, three seeds, and 794 tasks on BFCL v3's official checker, the same deletion operation produces anywhere from a 4.4-point improvement to a 51.3-point collapse, with both extremes statistically excluding zero. The key finding is that this number is intrinsic: re-dose one model from 0% to 100% deletion and the reading wobbles by at most 1.5 points. This matters because of how multi-turn AI tool-calling actually works in production. When you chain models across providers — say, a routing layer from one vendor calls a reasoning model from another — the upstream provider typically binds each reasoning trace to its issuer. Cross-provider forwarding strips the history. The paper notes that 73% of user interactions in the 94k-conversation ShareGPT dataset span multiple turns, so this isn't an edge case. It's the default operating condition for a large fraction of real traffic, and until now nobody had measured the cost. The experimental design is clean: three rendering conditions (full history retained, history deleted, and a control), seven models, three random seeds per condition, all evaluated against BFCL v3's official checker. The 794 tasks are drawn from Berkeley's Function Calling Leaderboard, a community benchmark with published ground truth. The three-seed design with blind evaluation across conditions is solid methodology for this kind of measurement. The authors don't cherry-pick the flattering models — the full range from slight improvement to catastrophic collapse is reported. The architectural insight is that this is fundamentally a measurement paper, not a methods paper. It doesn't propose a fix. It proposes a diagnostic: a two-cell screen (one retention run, one deletion run) that any team can execute to get the deletion-sensitivity reading for any model. The reading is cheap to obtain and stable across deployments. When a model gets retrained or re-released, it's a new model that needs re-screening — but only two runs. The practical implication is that deletion sensitivity should become a first-class routing parameter. If you're building an agentic system that chains reasoning models across providers, you need to know each model's deletion sensitivity number the way you know its context window or latency. A model with +51.3 points of deletion sensitivity is catastrophically unsuitable for cross-provider multi-turn pipelines. A model at -4.4 actually benefits from deletion — it was confused by its own prior traces. This is actionable information that most production routing systems currently ignore. The limitation is scope: seven models, one benchmark (BFCL v3), one task family (tool calling). The authors don't test whether the finding generalizes to other multi-turn task types — coding, planning, retrieval-augmented generation. That's the obvious next experiment, and the honest read is that they scoped tightly to make the measurement clean rather than broad. The finding that deletion sensitivity is model-intrinsic is strong within the tested domain; whether it holds for arbitrary multi-turn reasoning is an open question worth tracking.
The analogy
Imagine a surgeon whose whiteboard notes are erased between each stage of a multi-stage operation. Some surgeons barely notice and reconstruct from context; others lose the thread entirely. The paper measures which surgeons are which — and finds that the sensitivity to erased notes is a stable trait of the individual surgeon, not the hospital or the operation.
Surgeon notes
Whiteboard erased between surgical stages — some surgeons reconstruct, others lose the plan
Trace deletion
Reasoning history stripped between turns — some models reconstruct, others collapse by 51 points
Honest assessment
A clean, well-designed measurement paper that discovers a genuinely useful finding: the cost of stripping reasoning history is a stable model property, not a deployment variable. The scope is narrow — one benchmark, one task family — but the factorial design within that scope is honest and the result is immediately actionable for anyone building multi-provider agentic pipelines. The paper's real contribution is less a result and more a protocol: a cheap two-run screen that should become standard. Whether the model-intrinsic property holds beyond tool-calling is the load-bearing open question.
What Is CLAIMS?
67
/ 100
BedrockNews applies a structured analytical framework called CLAIMS to academic papers and technical research releases.
How CLAIMS worksClaim
4/5
Ladder
2/5
Architecture
3/5
Integrity
4/5
Milestone
3/5
Successor
4/5
What is this paper actually committing to?
Genuine first measurement. Nobody had quantified the cost of cross-provider reasoning-trace deletion before. The model-intrinsic finding is the real claim, not just the measurement itself.
The field fight
Should multi-turn reasoning history be treated as essential context or expendable noise in agentic pipelines?
Side A
History is context — always preserve it for best performance
Held by: Default assumption in most agentic frameworks, prompt engineering guides
Side B
Deletion cost is model-specific and must be measured, not assumed — some models actually benefit from deletion
Held by: This paper
Milestone tracker
Unlocks: Deletion sensitivity as a standard model card metric for production routing
Current
794
tool-calling tasks across 7 models
this paper
Next
3-5
task families (coding, planning, RAG, tool-calling)
generality threshold
~1-2 papers if another group picks up the protocol
Verified Facts (6)
Across 94k ShareGPT conversations, 73 percent of user interactions span multiple turns
The same deletion spans -4.4 to +51.3 points with both ends excluding zero
For the one model re-dosed from 0 to 100 percent deletion, the reading varies by at most 1.5 points
Seven open-weight reasoning models, three seeds, 794 tasks, and the official checker
Three rendering conditions tested
10 pages, 5 figures, 8 tables
Practical Implications (5)
Teams building multi-provider agentic pipelines should screen every model's deletion sensitivity before deployment — a two-run test costing two evaluation passes
Routing layers should incorporate deletion sensitivity as a first-class parameter alongside latency and context window
Some models actually perform better with deleted history — blind preservation of reasoning traces is not always optimal
Model providers should publish deletion sensitivity on their model cards, especially for models marketed for multi-turn tool use
Cross-provider API designs that strip reasoning traces are imposing a hidden, model-specific tax that ranges from negligible to catastrophic
More latest news
Read all