DSH Subagent empty-completion analysis

DSH Subagent Empty Completion: Reasoning Budget Exhaustion

Author
DeepSeekAgent.io Editorial Team
Published
Updated

A Subagent state of completed does not necessarily prove that its deliverable exists. In a DSH reproduction published on October 20, 2026, a background Subagent ran for about twenty minutes and consumed its complete output budget without calling a tool, returning assistant text, or creating a file. The parent still received a completed settlement.

The important failure is not one unsuccessful task. The harness collapsed “the provider ended the response normally” into “the work completed successfully.” When the complete value of a task lives in disk artifacts, an empty result and a successful result sharing one state creates both reliability and cost failures.

What happened in the session

After decompressing and inspecting the Subagent session log, the reporter found:

  • one turn and one step across the complete run;
  • an assistant message containing only reasoning, with no text or tool_use;
  • 32,853 input tokens;
  • 32,000 output tokens, exactly the output cap;
  • 31,955 reasoning tokens;
  • a turn/end reason of completed.

The assignment was a mechanical rewrite of thirteen Markdown files with script-verified acceptance. The agent did not merely stop halfway through execution. It consumed the first response before producing its first observable action.

Why the harness reported completion

The reproduction used a continuable background Subagent in DSH 0.2.0-rc.2. The localized settlement path has two important properties:

  1. the activation observer starts with completed as its default stop reason;
  2. the settlement notice attaches a closing message only when assistant output is non-empty.

A provider can stop cleanly near a token ceiling without returning a truncation error that the harness recognizes. If the response contains only a reasoning block, no tool call, and no visible text, the observer can retain its default completed result. The parent receives no signal connecting an empty closing message, zero tool activity, and exhausted output budget.

What completed needs to mean

An agent runtime should distinguish at least three events:

  • response ended: the provider stopped generating tokens;
  • execution ended: the agent loop stopped advancing;
  • task completed: the acceptance conditions and artifacts are satisfied.

One completed label cannot safely represent all three. A response may end normally before work begins. An execution may stop because of budget exhaustion, denied permission, or tool failure. Task-level completion should be exposed upstream only after the harness validates output, tool behavior, or external artifacts.

How the failure wastes tokens

At a high reasoning setting, a mechanical assignment can spend its budget planning, checking, and replanning. Until a tool call occurs, none of that activity modifies the files and the harness sees no external progress.

The cost compounds when the parent treats an empty completion as success. It may summarize deliverables that do not exist or dispatch the same work again. This belongs to the same observability chain as Subagent billing blind spots and long Agentic Loops: the UI state does not fully express actual model calls and artifact state.

Constraints for mechanical work

1. Lower the reasoning setting

Bulk renames, formatting repairs, file moves, and deterministic code rewrites rarely need a high reasoning budget. Set a lower reasoning effort explicitly and reserve budget for tool execution and verification.

2. Require observable progress first

The task contract can require the first action to be a read-only inspection or tool call rather than a long plan. Listing target files, reading a representative sample, or creating a progress record makes it possible to tell whether the agent actually started.

3. Define verifiable completion

The parent should check more than a status string:

  1. the closing message is non-empty;
  2. the expected files, commit, or report exists;
  3. the acceptance command ran and returned the required state.

For multi-file work, the child can maintain a heartbeat or manifest that ends with a done marker. An interrupted session can then be classified as not started, active, or verified.

4. Bound reasoning without tools

The harness can set a separate limit for consecutive reasoning with no tool activity. Reaching it should return max-tokens, no-observable-progress, or another explicit result instead of inheriting completed.

Signals the runtime should expose

A parent settlement should include at least:

  • stop reason;
  • input, output, and reasoning tokens;
  • tool-call count;
  • whether non-empty assistant text exists;
  • artifact or acceptance-check status.

When output is near the cap while tool calls and visible text are both zero, the harness can classify the shape directly as reasoning-budget exhaustion. Even before changing the state machine, one diagnostic line in the parent notice would prevent an empty result from masquerading as success.

Implications for DeepSeek V4.1 Flash scheduling

V4.1 Flash supports long-context and complex agent workloads, but a larger context or reasoning budget should not be the default answer for every child task. Research, architecture, and ambiguous decisions can retain higher reasoning intensity. Deterministic rewrites, filesystem operations, and checks should act early, produce artifacts continuously, and run under explicit ceilings.

References

FAQ

How can the model hit the output cap without producing text?

Nearly the complete output budget can be consumed by reasoning blocks. With no remaining room for text or a tool call, the visible result can be empty.

Will lower reasoning effort reduce quality for every task?

It should not be applied globally. Lower reasoning fits deterministic mechanical work; research and architecture can retain higher settings. Route by task type.

How should a parent verify that a child really finished?

Check a non-empty settlement message, external artifacts, and the acceptance command together. A completed state alone is insufficient evidence.