Agent turns silently truncated on max-tokens - no auto-continuation, turn marked as completed

[wutyi4330]

Bug Report: Agent turns silently truncated on finish_reason=length — no auto-continuation, turn marked as completed

Environment

• DSH runtime: runtime-dsh-0.1.2-rc.1
• Package: @deepseek-ai/dsh-agent-loop (lib/index.js)
• Observed: 2026-10-28, heavy multi-hour coding sessions (50+ turn conversations, long tool-use chains)

Summary

When a single model response hits the max-tokens limit (finish.kind === "max-tokens"),
the agent-loop ends the turn immediately via the normal completion path. No
auto-continuation is attempted, no compaction-and-retry is triggered, and the UI
reports the turn as successfully completed — even though the assistant's output
was cut off mid-sentence / mid-tool-call.

This makes long coding sessions silently lose work: the agent appears to "finish"
but its final message (or a tool call it was about to make) is truncated. The user
experience is "the assistant suddenly stopped and claimed it was done."

Evidence (from dsh-agent-loop/lib/index.js, 0.1.2-rc.1)

1. Step level — truncation short-circuits to a return:

   if (finish.kind === "max-tokens") return { kind: "max-tokens" };

2. Turn level — the truncation result ends the loop when no queued inbox messages exist:

   if (turnEnds === null || turnEnds.kind !== "max-tokens") turnEnds = stepEnd;
   ...
   if (turnEnds && this.inbox.nextStep.length === 0) break;   // ← ends turn

3. Because the turn ends via break (not the error/aborted paths), downstream
   lifecycle treats it as a normal completion → UI shows "done".

4. dsh-compaction exists but is a pre-emptive context-budget compaction
   ("providers decide when to compact"). It does not cover the
   single-response-truncated case, so nothing rescues a max-tokens cut.

Why it surfaced recently

• Long conversations (50+ turns) + long single outputs (large reports, tool-heavy
  coding loops) hit the per-response max-tokens ceiling far more often.
• A degenerate model output loop (repetitive text) burns the entire output budget,
  making truncation frequent.

Expected behavior

On finish.kind === "max-tokens", DSH should automatically recover, e.g. either:

• (a) Continuation: re-issue the request with the truncated assistant message
  preserved (append-only continuation, possibly with a "continue" user nudge),
  repeating until the model finishes naturally; or
• (b) Compact-and-retry: trigger compaction and re-emit the remainder;
• In both cases the turn should only be marked complete when the model stops on its
  own (finish.kind === "completed" / no pending tool calls).

Suggested fix sketch

In the turn loop, treat max-tokens like "more work pending":

// step(): keep returning { kind: "max-tokens" }
// turn loop:
if (turnEnds?.kind === "max-tokens") {
  // 1) mark last assistant message truncated (UI hint)
  // 2) push a synthetic continuation inbox item / re-enter step with
  //    an appended "continue" instruction (or compact first if over budget)
  // 3) reset turnEnds = null; continue;
}

Guard with a max-continuation counter to avoid pathological loops.

Impact

• Silent data loss in long agent sessions (truncated final answers shown as complete).
• User trust: "it suddenly stopped and said done" — very hard to diagnose from the UI.

Metadata

• Reporter: end user via DSH Web GUI session, 2026-10-28
• Repro: any long session where a single response exceeds max_tokens; deterministic
  once the output budget is exceeded.

[yamingmou]

@wutyi4330 — you already named the gap yourself: dsh-compaction exists, but it is a pre-emptive context-budget compaction, so it does not cover a single response being cut off mid-sentence and then reported as a completed turn.

I would put the general form wider than one limit: the constraint was declared as data, and nothing executes at the moment it is reached. max-tokens is one instance; a declared timeoutMs that is only substituted after the call settles is another (@XJPeng12's #11258, where the transport can swallow the abort and the deadline never runs anything).

That gives a check that does not wait for the next report: enumerate the constraints the runtime declares — budgets, caps, windows — and for each ask whether any code path executes where it is hit. A declared constraint with no execution point is data, not a rule, and from the caller's side the two are indistinguishable.

I wrote the general form up, with both instances, in our own thread here: discussioncomment-19400984.

Authorship note: drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out and I will re-verify and correct.

Reported by the OfferKuai Team (Offer快) — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/. Contact: contact@offerkuai.com

---

中文版

@wutyi4330 —— 这一格你自己已经点出来了：dsh-compaction 在，但它是预防性的上下文预算压缩，所以不覆盖"单次响应被截在句子中间、然后又被报成已完成回合"这种情况。

我想把一般化的形式说得比"某个上限"更宽：约束被声明成了数据，而在它被触及的那一刻，没有任何东西执行。 max-tokens 是一例；声明了 timeoutMs 却只在调用落定之后才替换结果，是另一例（@XJPeng12 的 #11258 —— 传输层可以把中断吞掉，那条死线从头到尾没有运行任何东西）。

由此得到一条不必等下一份报告的自查：把运行时声明出来的约束 —— 预算、上限、窗口 —— 列一遍，逐个问：它被触及的那一刻，有没有代码在那里执行？ 声明了却没有执行点的约束是数据，不是规矩；而在调用方看来，这两者不可分辨。

一般化形式连同两个实例，我写在自己那篇帖子里：discussioncomment-19400984。

声明：文稿撰写由 AI 协助完成；核验与发布由我本人负责。我非工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队 提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/。联系：contact@offerkuai.com