DSH Fixed 30-Second Turns: Tool-Call Scheduling

A distinctive DeepSeek Harness delay has been reproduced in the community. The model usually produces its answer within three to five seconds, yet a requested tool does not start until roughly 30 seconds after the turn began. A text-only turn can also hold turn/end until the same boundary. The delay affects the first action of each turn while subsequent tools may run immediately.

This pattern is more specific than a slow model. A stable duration, consistent reproduction, and concentration on the first action point toward synchronization between stream completion, usage settlement, and a scheduler fallback timer.

What the event timeline reveals

One reported tool turn follows this sequence:

• about 6.04 seconds: assistant/message and tool/call arrive;
• about 30.05 seconds: job/registered appears;
• about 30.59 seconds: tool/result arrives.

In a text-only turn, the message and step/end complete at about 1.76 seconds, while turn/end waits until about 30.03 seconds. The model output has therefore arrived. The wait sits at the boundary that decides when a turn can advance or close.

An IM polling delay, slow tool process, or ordinary model latency does not explain both timelines. A slow tool would not delay a text-only turn/end, and a slow model would not deliver the assistant message more than twenty seconds earlier.

Why a fixed 30 seconds points to a fallback path

Queueing and network congestion usually vary. A duration that repeatedly lands near 30 seconds resembles a timeout. Candidate paths include:

1. the provider sends text or a tool call but not the final event expected by DSH;
2. usage or response-tail processing remains pending, so the scheduler does not commit the first tool job;
3. an adapter couples “tool call received” with “response stream safely closed”;
4. a 30-second fallback synthesizes completion and advances the state machine.

These are diagnostic hypotheses derived from the event order, not a confirmed root cause. The decisive trace must place raw provider-stream events and internal DSH events on the same clock.

A reproducible investigation

Build three minimal cases: a text-only answer, one simple tool call, and two consecutive tool calls. Record the timestamps for request dispatch, first token, tool-call block, provider stop reason and usage, step/end, turn/end, job/registered, and tool/result.

Then compare Web UI with IM, providers, plugins on and off, and reasoning output on and off. Change one variable at a time. A first-action delay across every entry point implicates a shared provider adapter or turn scheduler. A provider-specific result focuses the investigation on end-event mapping.

The community case already challenged several intuitive explanations: IM polling, Session-log upload, a memory plugin, a simple Anthropic SDK drain, and common streamIdleTimeout settings did not account for the complete behavior. Preserve those negative results instead of restarting the investigation from network speed.

User-experience and cost impact

The wait does not inherently add output tokens, but it multiplies wall-clock time. Short tasks that alternate between confirmation, file reads, and search can grow from seconds to minutes. An outer automation timeout may then retry the job and create additional calls.

Until the event path is corrected, reduce avoidable turns: provide the goal, input files, and acceptance criteria together; batch independent reads; give automations a realistic total duration while limiting retries. Increasing every timeout indefinitely only hides the state-machine defect.

Compare this timeline with redacted_thinking failures in multi-step tool calls. One delays completion; the other rejects a response block. Both can look like a stalled Agent, but their event traces differ.

References

• Community reproduction and timeline for the fixed 30-second delay
• DeepSeek Harness v0.2.1-rc.3 release

FAQ

Why does the tool wait when model text is already visible?

Visible text does not prove that the adapter accepted the stream as complete. Inspect the stop reason, usage event, turn/end, and job/registered order.

Will a larger tool timeout fix it?

Usually not. In the reported timeline, the delay happens before the tool job is registered.

Why can the second tool call be fast?

The reproduction concentrates the delay on the first action in each turn, making the initial scheduling gate or response-finalization path more suspicious than the tool runner.