proposal: represent model and effort replacements as generations of one chat

Problem

Model and reasoning-effort changes currently create durable replacement sessions. /sessions consequently displays each replacement as an independent chat, although users perceive these operations as continuing one conversation.

This issue proposes a direction for discussion; it does not record an accepted architectural decision.

Proposed direction

Introduce a stable logical chat identity above immutable physical session generations:

• Each main chat has a stable ChatID.
• A model or effort replacement creates a new physical session that retains the source ChatID.
• The replacement records PredecessorSessionID = source.ID.
• Explicit user-created forks start independent chats with new ChatID values and no predecessor.
• Keep generation metadata separate from SessionRelationship, whose current kind-specific validation requires main sessions to carry no relationship.

The target's predecessor field would be authoritative. The source would not receive a corresponding SupersededBy update, avoiding a two-record consistency protocol.

Proposed lifecycle

1. Compare the requested effective model and effort with the source configuration.
2. If unchanged, keep the existing session and create no generation.
3. Otherwise, validate and construct a replacement under the existing source lock and lease.
4. Publish the target with the inherited ChatID and the source as its predecessor.
5. Treat target publication as the commit point.
6. Release source-local resources only after the target is usable.
7. Retain the source snapshot and event log as historical data.
8. Make retries discover and reuse an already-published valid successor.

Proposed inventory behavior

• /sessions shows only the latest generation of each chat by default.
• Replaced generations remain available through an optional historical view.
• Filtering occurs server-side before counting and pagination; client-side deduplication is insufficient.
• Reverse/head indexes are derived from authoritative predecessor metadata and can be rebuilt.
• Legacy sessions without a ChatID may behave as though ChatID == SessionID, avoiding an eager migration.

Potential contract changes

• Persist on main sessions:
  • ChatID
  • optional PredecessorSessionID
• Consider a dedicated ReplaceSessionConfiguration operation while leaving ForkSession semantics unchanged.
• Add an IncludeReplaced inventory option.
• Extend storage discovery metadata so pagers can identify heads before filtering, counting, and pagination.

Failure posture

• Failure before target publication leaves the source visible and unchanged.
• Failure after publication leaves the target as the recoverable head.
• No source-side durable update is needed for correctness.
• Missing, cyclic, or conflicting generation metadata fails visible: affected sessions remain listed rather than being hidden.
• Reconciliation repairs only derived indexes and never deletes historical generations.

Alternatives to evaluate

• Updating model and effort in place despite the provider-per-session invariant.
• Deleting the source after successful replacement, accepting loss of its independent snapshot and event log.
• Persisting bidirectional predecessor/successor fields with a transactional or reconciliation protocol.
• UI-only grouping, accepting pagination and cross-client inconsistencies.

Related bugs

• #1485 — selecting auto reasoning effort inherits the previous override.
• #1486 — failed effort-switch hydration unbinds the session and leaks its successor.

Start by tracing model and reasoning-effort replacement, SessionRelationship validation, and /sessions inventory behavior; the issue names no files or tests. First resolve the architectural alternatives and contract choices with maintainers. Done would mean an accepted design covering ChatID and predecessor persistence, head filtering, retries, and failure and reconciliation semantics.