Chenpan Li, Thies Brockmoeller, Stefanie Jegelka, Sharut Gupta, Nikolaos Karalias
9 min
Abstract
Modern language models are increasingly asked to handle several tasks within a single prompt. Doing so requires solving each task correctly while integrating the resulting answers into a coherent response. In this paper, we identify a fundamental limitation in this process, where models make substantially more errors when tasks are composed, even when they can solve every constituent task reliably in isolation. This degradation cannot be fully explained by the accumulation of independent errors. Across both open-weight models and the frontier model Claude Opus 5, our findings instead point to an implicit thinking budget underlying this effect. In particular, under composition, models use substantially fewer tokens per task than in isolation, even when the full sequence remains well within the context window. Tasks that require longer solution traces in isolation are consequently more $\textit{fragile}$ under composition, i.e., models make more errors on prompts containing these tasks. In isolation, non-fragile tasks receive more reasoning than they need and waste compute. However, by grouping tasks according to their fragility, the implicit budgeting can be manipulated to reduce token usage by $43$\% across a range of math and linguistic tasks while also preserving accuracy.
Alex: Perhaps the combined answers simply ran out of room. Longer requests also mean longer responses.
Sam: Most responses remained well inside the context window, the space available for prompt and response together. The authors also checked failures to extract answers from the requested format. Neither explains the overall pattern, although formatting failures matter in particular cases.
Alex: So the model usually has room left, but performs worse anyway. What points toward a reasoning budget rather than some other distraction?
Sam: Here is the key measurement. The researchers label each question and ask the model to name that label when reasoning about it. Those labels let them assign parts of the generated thinking trace to individual tasks.
Alex: By thinking trace, you mean the written reasoning the model generates, rather than a direct measurement of its internal computation?
Sam: Yes. They count reasoning tokens, the units of text in that trace. As more tasks share a prompt, almost every task receives fewer of those tokens. That happens without an explicit per-task limit.
Alex: Does the model cut the longest solutions most aggressively? That would explain why difficult problems suffer.
Sam: Not systematically as a proportion. Across the tested settings, tasks tend to lose roughly the same fraction of their isolated reasoning. The reduction follows an approximate power law: adding more tasks progressively shrinks the reasoning allowance for each.
Alex: Then equal proportional cuts need not produce equal damage. Some solutions may have room to shrink, while others cannot afford it.
Sam: That is the authors’ interpretation. Tasks with long isolated traces generally lose more accuracy under composition, meaning several tasks sharing one prompt. Shorter traces appear to contain more expendable reasoning, while longer traces seem closer to what successful solutions require.
Alex: That is still an association between trace length and errors. Did they try changing the reasoning allowance directly?
Sam: They did. They took the token allowance a task received in composition and imposed it when that task was solved alone. Abruptly stopping the reasoning caused stronger degradation, but reproduced the broad pattern: longer-reasoning tasks were more vulnerable.
Alex: That supports budgeting as an explanation, without making the two situations identical.
Sam: And it leaves a central question unanswered. The authors do not know what drives the shortening. An implicit thinking budget describes the observed allocation pattern; it is not an identified internal mechanism.
Alex: How does that become a useful batching strategy? You would need to know which questions can tolerate the cuts.
Sam: The authors call that vulnerability fragility. Within a given model, the same tasks tend to fail across different groupings and composition sizes. But different models often disagree about which tasks are fragile, so this is not a universal ranking of question difficulty.
Alex: Then a robust question can share a larger batch, while a fragile one needs a smaller batch or its own prompt.
Sam: That is fragility-aware batching. Using measured fragility, it saved about forty-three percent of output tokens on average compared with solving tasks separately, while preserving average accuracy. That headline excludes the competition-mathematics dataset AIME, where almost every task stayed alone.
Alex: Measuring each question’s failures requires repeated answers beforehand. That is useful evidence of potential savings, but what happens with unseen questions?
Sam: They trained a simple predictor from task descriptions, separately for each model. On held-out tasks, predictor-guided batching saved about thirty-one percent of tokens on average. Its success varied by dataset, and those aggregate results are not guarantees for every model.
Alex: Did that prediction strategy also work for the proprietary model, where the researchers had less access?
Sam: Not well in that test. On GPQA-Diamond, batching by measured fragility saved about twenty-four percent of Claude Opus Five’s output tokens, with a small accuracy loss. But its predictor saved almost nothing and lost more accuracy; it was trained using fewer trials.
Alex: So the evidence is stronger for the opportunity than for a ready-made solution across models. And these were independent questions from the same dataset, not the dependent steps of a research agent.
Sam: That is the main boundary. Detailed reasoning-length analysis also covered only open-weight models. The authors suggest keeping agent contexts lean and moving demanding steps into fresh contexts, but these experiments do not establish that intervention’s effectiveness in agent workflows.
Alex: Who should read the full document, then, and where should they start?
Sam: Researchers evaluating reasoning reliability or designing batching systems should read it. Start with Section Three’s per-task reasoning analysis, then Section Four’s comparison of measured and predicted fragility. Pay attention to the exceptions and model-level results, not just the average savings.
Alex: And what should everyone else remember before combining their next set of questions?
Sam: A model’s ability to solve tasks alone is not a promise it can solve them together.
Alex: Keep that distinction in your next evaluation.