DSH session titles: fallback, provider and user rename

A DeepSeek Harness session title is not a label the UI writes on the fly; it is a persistent session/title event that records the text, the user messages used, and whether the source was fallback, provider, or user. That event decides whether the title will keep changing. Understanding the three sources explains both “the model stopped renaming after I edited it” and “the title is stuck on the first sentence”.

DeepSeek Harness: The three sources

A title has exactly three sources, with different priority and behavior. Compare:(source)

The session/title event also stores messageSeqs: which user messages derived the title. A user rename has an empty list because the title did not come from messages.

The title projection keeps only a string or null, so old cache rows remain readable and clients do not need the full event structure.

DeepSeek Harness: Generation cadence

A provider declares first-prompt or all-prompts at registration; the service calls it on that cadence. Two modes:(source)

1. first-prompt — generate once after the first human message. Expected: stable titles, but later long conversations may drift away from the topic.
2. all-prompts — generate a revision on later human messages. Expected: titles follow the topic, but more auxiliary requests and more cancellation handling.

Before each provider call, the service ensures the fallback and latest accepted title snapshot, passing it as currentTitle. The provider decides whether to use it.

Provider-returned messageSeqs must come from the current request; the service validates order and rejects fabricated seqs.

DeepSeek Harness: Rename and refresh

A rename is not “overwrite a display field”; it writes a title with source user and pins automatic generation. Behavior:(source)

1. rename(session, title) — normalize and append session/title. Expected: the title changes immediately and later messages do not schedule generation.
2. In-flight generation is superseded — a late provider result cannot overwrite the user rename. Expected: no “edited, then the model changed it back”.
3. refresh(session) — retry the provider, or materialize the fallback when no provider exists. Expected: the deliberate unpin and retry.

If rename normalizes to an empty title, it throws SessionTitleInvalidError; it also fails when the session is not live or the service is disposed.

DeepSeek Harness: Auxiliary request records and byte caps

Title generation is a real auxiliary model request, and the service records the model-visible input. The record includes:(source)

• titleProvider — which provider owns the request.
• messageSeqs — user messages included in the request.
• route — provider and model.
• system and messages — what the model actually saw.
• maxTokens — the output cap.
• reasoningEffort — resolved reasoning strength, absent on older requests.

The record is written before dispatch, so a later failure is still reproducible. Before storing, the service normalizes the title and enforces a byte cap; an over-limit title is not stored as returned.

DeepSeek Harness: Three strategies

Fallback-only, a registered provider, and user rename solve different problems. Three:(source)

1. Fallback only — no provider; the title comes from the first message or built-in rules. Expected: zero cost, but less precise.
2. Register a provider — a model generates a readable title on first-prompt or all-prompts. Expected: better titles, with auxiliary requests and failure handling.
3. User rename — pin a stable title manually. Expected: good for important sessions; no automatic changes afterward.

If a title stays on the truncated first message, check whether a provider is registered and whether the output budget is consumed by reasoning; that is a separate layer from the three sources.

DeepSeek Harness: Inspecting title state

Do not rely on the UI string; inspect the event and snapshot to learn the source and whether it will change. Steps:(source)

1. Read the session/title event — confirm source fallback, provider, or user. Expected: know whether automatic generation will continue.
2. Read messageSeqs — see which user messages derived it. Expected: explain why it stopped at a particular sentence.
3. Read eventSeq and updatedAt — locate the latest update. Expected: tell whether it has been stale.
4. Read the auxiliary request record — confirm whether the provider was called and with what output cap. Expected: distinguish “not called” from “called and failed”.

The UI shows only a string or null; debugging happens at the event layer.

Provider request and result fields

The provider contract is narrow: read a snapshot, return a title and attribution. Compare:

The service validates order, normalizes the title, enforces the byte cap, and writes session/title. A provider must not write the event itself.

DeepSeek Harness FAQ

If I remove a provider, does the title return to fallback? An existing title is a persistent event and is not automatically rewritten. New generation uses whatever is currently available.

Can different sessions use different providers? The service allows one optional provider per context; different profiles or homes can use different implementations.

Does title generation consume model quota? Yes. It is an auxiliary model request with its own maxTokens and route record; do not treat it as a local string operation.

The short version: what matters is not how pretty the title is, but which source wrote the persistent event; the source decides whether it will change.