Qwen3.6-27B and Qwen3-4B Agents Blow Their Time Budgets Without Harness Hints

Tell an agent "you have 30 minutes," and it won't work for exactly 30 minutes. The authors of a recent arXiv preprint tested this on two small models: Qwen3.6-27B on five MLE-Bench Lite competitions and Qwen3-4B on the text game Zork I from the Jericho suite. The tasks were chosen deliberately: in both, extra time can genuinely improve the result. The conclusion is uncomfortable. Agents can neither meet a deadline nor make sensible use of spare time.

Why a prompt alone isn't enough

In the baseline setup, the budget is mentioned only in the task text. The harness, the wrapper that launches the agent and executes its commands, never reports how much time has passed. The agent is left without a clock. The authors name three reasons for the failure:

• no time feedback: the model can't see how many seconds it has already used;
• no estimate of how long actions take: the agent can't tell in advance that training a model or a long run won't fit in the remaining time;
• no learned link between budget and strategy: a short limit doesn't push it toward a simpler plan, and a long one doesn't encourage it to dig deeper.

The second reason matters most for MLE-Bench. There, a single wrong step, such as launching heavy training, eats the entire remaining limit. A planning error turns out to be a time-estimation error.

What helped and what didn't

The researchers tested two classes of intervention. The first works at the harness level: show the agent timings and forcibly cut off work at the deadline. The second trains the model itself with reinforcement learning, specifically GRPO with a reward that accounts for the budget.

The harness results are fairly straightforward. For Qwen3.6-27B, simply feeding it time information noticeably improved budget compliance, with no measurable drop in quality. Forced-termination hooks tightened discipline even more. It's a cheap fix: you don't need to touch the model, only change the wrapper.

RL gave a more mixed picture. On Zork I, GRPO brought budget compliance close to perfect and generalized to budgets that weren't in training. The model apparently did learn to recognize when to stop. But on MLE-Bench, training did not improve final metrics compared with an untrained agent in the same harness.

The main finding lies elsewhere. Even when the agent was forced to meet the limit, it did not use the extra time productively. Trained policies often fill the remaining minutes with repetitive actions. And when GRPO trains on several budgets at once, it tends to collapse to the strategy learned for the shortest limit. In other words, the model respects the deadline but doesn't turn a longer budget into a stronger solution.

Practical takeaways for agent developers

The most reliable conclusion from the work: don't rely on the prompt. If an agent has a budget, put a timer in its context and enforce a hard cutoff at the infrastructure level. This requires no fine-tuning and, judging by the results on the 27B model, doesn't degrade quality.

Second: don't mistake compliance with the limit for efficiency. A "finished on time" metric should sit next to a result metric measured across several budgets. If quality doesn't grow as the limit grows, the agent is simply burning time.

Third: when training with RL for different limits, watch for collapse to the short-budget regime. You need separate checks on long budgets and, possibly, rewards that encourage useful use of the spare time, not just compliance with the limit. The authors explicitly call this gap between discipline and productivity the central unsolved problem for budget-conditioned agents.

The limitations of the work are also obvious: two small models and two benchmarks. Conclusions shouldn't be carried over to large closed systems without testing. But as a diagnosis of typical time-management failures in agents, the preprint is useful.