Generate better session names by summarizing user prompts with a cheap model

[lowlorenz]

Summary

Session names in the history list are currently just the truncated first user message. We could produce much better names/summaries by feeding the session's user prompts through a very cheap model to generate a short, descriptive title.

Current behavior

chronos-vscode/src/panel/sessions.ts:81 derives the display name as:

name ?? firstUserMessage?.slice(0, 80) ?? "(empty session)"

So unless the user manually set a name (via /name, stored in the session_info entry), the session is labeled with the first 80 characters of the first user message (sessions.ts:61-64). This is often a poor label — it might be a greeting, a vague opener ("can you help me with this page?"), or get cut off mid-sentence, and it ignores everything the session actually accomplished.

Proposal

Auto-generate a concise title (and optionally a one-line summary) by sending the session's user prompts — or the first N turns — through a very cheap, fast model. Something like a 3–8 word title that captures the task ("Extract baptism records from parish register, 1801–1815").

This name would fill the same slot as the manual name — i.e. it becomes the fallback when the user hasn't set one explicitly, replacing the raw firstUserMessage truncation.

Notes / things to consider

• Model choice: use the cheapest available model (this aligns with the provider-agnostic, no-hardcoded-model direction — let it be configurable / documented rather than pinned in code). The historian's vision/extraction model is overkill for this.
• When to generate: lazily on first listing, after the first turn, or on session end — and cache the result (e.g. write it back into the session's session_info so it isn't recomputed on every history refresh).
• Cost/offline safety: must degrade gracefully — fall back to the current first-message truncation if no cheap model is configured, the call fails, or the user is offline. Naming should never block the history list from rendering.
• Privacy: this sends prompt text to a model provider; should respect whatever auth/provider the user has configured and not silently call a new one.
• Feeding user prompts only (not full transcripts) keeps the input tiny and cheap while still being descriptive.