Switch-SWE: Do Coding Agents Hold Focus When Switching Between Unfinished Tasks?

This is an automated message from the Librarian Bot. I found the following papers similar to this paper.

The following papers were recommended by the Semantic Scholar API

• WideSWE: Can Coding Agents Coordinate Changes Across Repositories? (2026)
• StateHarness: Maintaining Evolving Project State for Long-Horizon Coding Agents (2026)
• Compact-Bench: Measuring What Context Compaction Costs Long-Horizon Coding Agents (2026)
• PAUSE: Search-Free Steering of Coding Agents Before Their First Source-Code Edit (2026)
• Design and Cross-Domain Evaluation of an Agent Execution Harness (2026)
• Coding-Agent Benchmarks Should Match Their Users'Task Flows (2026)
• FeatureArc: Benchmarking Coding Agents on Evolving Features (2026)

Please give a thumbs up to this comment if you found it helpful!

If you want recommendations for any Paper on Hugging Face checkout this Space

You can directly ask Librarian Bot for paper recommendations by tagging it in a comment: @librarian-bot recommend

Hello. I read your paper with great interest. You show that switching between unfinished tasks lowers focus-task resolution by 11.5 percentage points on average, although its requirements and verifier stay the same, and you connect this mainly with loss of task state and confusion between the requirements of different tasks.

It seems to me that a considerable part of this drop may be explained not by switching as such but by overload, that is, by the limited ability of a model to carry out instructions as their number and volume grow. With switching, the accumulated context holds more requirements of different tasks, and the model has to keep them apart correctly. Your Table 3 points to this. On DeepSeek-V4.1-Flash, history routing raises resolution from 31.5% to 42.5%, and adding state memory raises it to 47%, which practically closes the gap with the uninterrupted condition (46.5%). The switching itself stays the same: the same tasks, the same requests, the same returns. Only what the model receives in the request changes. This leaves the question of mechanism: how much of the improvement comes from less volume and fewer foreign instructions, and how much from more accurate recovery of task state or from the module telling compaction to preserve requirements. The difference between models also points to overload. On the same tasks the gap ranges from 6 to 15 points, and GLM-5.3 and Kimi K3, nearly equal without switching (49% and 48%), diverge to 43% and 34.5% with it. This is how a limit specific to each model should behave: while the load is small the models are close, and as it grows they diverge.

A study of the behavior and degradation of language models under controlled load (arXiv:2610.36095) measures the effects of the number of independent rules and of text volume separately and shows that, in the measured model, quality falls by about the same amount with each doubling of the number of rules. It would be interesting to compare these dependencies with your results, allowing for the difference between elementary instructions and programming tasks. You compare one task with five. If you added two, three, four and ten, would resolution fall in the same way with each doubling of the number of tasks, and how would the frequency of missed requirements and of instructions wrongly carried over between tasks grow with it? The total tokens in Table 2 cannot show this. Such a comparison would help establish what part of the decline is due to limits on executing instructions and what part to switching and state recovery themselves.