Problem

When users have many sessions, it becomes difficult to identify which session was used for what purpose. Currently, the session list (both CLI and TUI) only shows:

• Session ID
• Title
• Last updated timestamp

This makes it hard to distinguish between sessions, especially when users work with multiple models for different types of tasks.

Proposed Solution

Add model information to the session list display. This would show which model the session was started with, helping users quickly identify sessions based on the model used.

Why the starting model?

• The starting model indicates the user's intent for that session (e.g., a fast model for quick questions vs. a capable model for complex refactoring)
• It provides consistent, predictable information that doesn't change as the session progresses
• Users can easily correlate sessions with their workflow patterns

Implementation Details

Data Source

Model information is currently stored at the message level, not the session level:

• User messages contain: model: { providerID, modelID }
• Assistant messages contain: modelID, providerID

To get the starting model, we need to query the first message of each session.

Changes Required

1. Session Table Schema (src/session/session.sql.ts)

   • Add model column to store { provider_id: string, model_id: string }

2. Session.Info Schema (src/session/index.ts)

   • Add optional model field: { providerID: string, modelID: string }

3. Session List Logic (src/session/index.ts)

   • Modify Session.list() and Session.listGlobal() to include model from session table

4. CLI Output (src/cli/cmd/session.ts)

   • Add Model column to table format
   • Add model field to JSON output

5. TUI Display (src/cli/cmd/tui/component/dialog-session-list.tsx)

   • Show model alongside session title or in the footer

6. REST API (src/server/routes/session.ts)

   • Include model info in session list responses

Performance Considerations

• Model info stored directly on session table avoids per-session message queries
• Backwards compatible: existing sessions will have null model field
• Model populated when session is initialized or first message is created

Acceptance Criteria

• CLI session list shows model column in table output
• CLI session list --format json includes model in JSON output
• TUI session list displays model information
• REST API session list endpoints include model info
• Sessions without model data (legacy) gracefully handled
• Performance impact is minimal for typical session counts (<100)

References

• Session schema: packages/opencode/src/session/session.sql.ts

• Session list CLI: packages/opencode/src/cli/cmd/session.ts

• TUI session list: packages/opencode/src/cli/cmd/tui/component/dialog-session-list.tsx

• Message types with model: packages/opencode/src/session/message-v2.ts

• I have verified this feature hasn't been suggested before