session-titles-bundle: maxOutputTokens 64 is fully consumed by thinking tokens, so automatic title generation fails silently

[Tengxianlai]

Summary

With @deepseek-ai/dsh-experimental-session-titles-bundle (0.2.1-alpha.2) enabled on a reasoning route, most automatic title generations never produce a title. The session keeps its deterministic fallback title (the first prompt truncated to fallbackMaxBytes), so the sidebar and tab title look frozen. The failure is silent: it only calls ctx.logger.warn, and the host has no logger exporter that persists runtime warnings — the only exporter feeds the startup-failure log (~/.dsh/logs/startup-*.log), so nothing appears in any file or UI.

Root cause

The bundle's cordis.patch.yml configures the all-prompts title provider with maxOutputTokens: 64:

- insert:
    - id: optional-session-title-all-prompts
      name: '@deepseek-ai/dsh-session-title-all-prompts-llm'
      config:
        targetWords: 5
        targetCjkCharacters: 10
        maxInputBytes: 4096
        maxOutputTokens: 64
        timeoutMs: 60000

The provider selects the route's lowest reasoning effort
(selectReasoningEffort = (model) => model.reasoning?.efforts[0]?.id, packages/experimental/session-title-all-prompts-llm/src/index.ts). For a route whose compat.thinkingFormat is deepseek (e.g. opencode-go/deepseek-v4.1-flash), @earendil-works/pi-ai then sends thinking: { type: "enabled" } and reasoning tokens count against max_tokens. The 64-token budget is consumed by reasoning, the response terminates with finish_reason: "length" and empty content, and titleFromResponse() throws session-title-llm: title output reached maxOutputTokens. The service keeps the previous title by design ("automatic failures emit a warning and keep the latest title").

The bundled first-message provider uses maxOutputTokens: 4096. The comment on that value in dsh-base/cordis.patch.yml says the ceiling is "a ceiling against runaway output, not a length target: the prompt keeps titles short, while reasoning a model cannot switch off also counts as output". A cap of 64 contradicts that constraint for any reasoning route.

Reproduction

Same route, same system prompt as the provider, one message, thinking: { type: "enabled" }, varying only max_tokens:

sample	max_tokens	finish_reason	reasoning_tokens	content
1	64	length	64 / 64	(empty)
2	64	length	64 / 64	(empty)
3	64	stop	34	title returned
4	64	length	64 / 64	(empty)
control	4096	stop	120	title returned

Observed impact

Across local session logs, 40 session/title-llm-request events with titleProvider: session-title-all-prompts-llm produced only 9 accepted session/title events (source.kind === "provider") — roughly 22%. The remaining sessions keep the truncated first-prompt fallback indefinitely, which reads as "the plugin does nothing".

Suggested fix

Raise the cap for the auxiliary title call (4096, matching dsh-base) or stop enabling thinking for title calls. 64 tokens is below what a reasoning route needs for even a trivial title, so the call has no reliable path to a usable answer.

Environment

• dsh 0.2.1-alpha.2 installed from npm, macOS, web profile
• route opencode-go/deepseek-v4.1-flash (pi-ai catalog entry: reasoning: true, compat.thinkingFormat: "deepseek", compat.maxTokensField: "max_tokens")
• workaround used locally: an id-targeted override of optional-session-title-all-prompts in the profile patch layer (~/.dsh/profiles/web/cordis.patch.yml) raising maxOutputTokens to 4096; the override is shallow-replaced, so all five fields are restated

[elladeniya-dev]

This happens because @deepseek-ai/dsh-experimental-session-titles-bundle hardcodes maxOutputTokens: 64 for the title generation request, and when routed to a reasoning model (like deepseek-reasoner / R1), the model spends all 64 tokens inside the <think> block before emitting the final response text.

How to Fix / Workaround

1. Route Title Generation to a Non-Reasoning Fast Model (Recommended):
   Configure your harness routing so background utility tasks (like session-titles-bundle) use a standard chat completion model (e.g., deepseek-chat / V3) rather than a reasoning route, or disable thinking / reasoning_effort for utility requests.
2. Increase maxOutputTokens Locally:
   If you must use the reasoning route for title generation, patch the bundle's maxOutputTokens from 64 to at least 512–1024 (via patch-package or pnpm patch @deepseek-ai/dsh-experimental-session-titles-bundle) so the model has enough token budget to finish its <think> block and output the short title.

If this helps explain/resolve the issue, please click Mark as answer!

[hcconquer]

Confirmed on master today, and here is the commit history behind the 64, which explains why the bundle never picked up the fix.

The bundle's 64 and the base's 4096 are not "an old value that was forgotten". They were written on two divergent branches, and only one of them was then fixed:

merge-base bf1c4e01 (2026-10-06) — base cordis.patch.yml: maxOutputTokens: 64
├── 3562e14f (2026-10-06) fix: widen the shipped title output cap … → 4096
└── 3aa1cab4 (2026-10-06) feat(plugin): compose optional bundles … → new bundle, copies 64

git merge-base --is-ancestor 3562e14f 3aa1cab4 returns false: the fix landed on a parallel branch, so the bundle author never saw it. The bundle was created from a tree where 64 was still the base value.

Worth noting what the fix commit already said, because it is the identical diagnosis as this report:

on the HFAI gateway, GPT-6 Sol and GPT-6 Astra used up to 87 and 121 output tokens for five-word titles at reasoning low, so Sol still finished with max-tokens on most first prompts

So the problem was understood and fixed for session-title-llm, and the same value survived in the new bundle. origin/master still ships maxOutputTokens: 64 in packages/experimental/session-titles-bundle/cordis.patch.yml, with no later commit touching it (git log -- packages/experimental/session-titles-bundle/cordis.patch.yml shows only the two creation/layout commits).

Measured on 117 real local sessions (e2e bursts excluded)

final title source	count
model-generated	88
fallback (truncated first prompt)	29

Split by provider era, the bundle era shows failures that are not all the token cap:

era	model-generated	fallback
session-title-first-prompt-llm (base)	41	4
session-title-all-prompts-llm (bundle)	32	4

Only 3 of those bundle-era failures are cap=64. The other 5 have zero session/title-llm-request events at all, which points at a second, independent limit — I will post that separately so this thread stays on the output cap.