anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Feature Request: Retain current model and agent selection when switching sessions #3220

New Issue
Open
opened 2026-02-16 17:39:11 -05:00 by yindo · 20 comments
yindo commented 2026-02-16 17:39:11 -05:00
Owner
Copy Link
Copy Source

Originally created by @JosXa on GitHub (Nov 30, 2025).

Feature Request: Retain current model and agent selection when switching sessions

Problem Description

When switching between sessions using Ctrl+X l, the session loads with whatever model and agent we were currently using. This forces users to manually reselect their preferred model and agent every time they switch sessions, which disrupts workflow continuity.

Current Behavior

  • User has Session A open with Model X and Agent Y
  • User switches to Session B using Ctrl+X l
  • Session B loads with whatever model and agent it was last using (e.g., Model Z and Agent W)
  • User must manually change model and agent back to their preferred selection

Desired Behavior

  • User has Session A open with Model X and Agent Y
  • User switches to Session B using Ctrl+X l
  • Session B loads but retains the session's last model and agent selection (Model X and Agent Y)
  • User can continue working without manual reconfiguration

Rationale

Users choose the best model and agent for a specific task. Each session serves a specific task, so the current model and agent selection should follow the user as they switch between sessions, rather than being locked to whatever a session was previously configured with.

Implementation Suggestion

Add a setting or default behavior where the current model and agent selection persists across session switches, rather than being tied to the global opencode CLI.

Additional Context

This is different from issue #4344 (model selection not sticking between agent alternation) - this is specifically about session switching via Ctrl+X l retaining the current user's model and agent preferences.

Originally created by @JosXa on GitHub (Nov 30, 2025). ## Feature Request: Retain current model and agent selection when switching sessions ### Problem Description When switching between sessions using `Ctrl+X l`, the session loads with whatever model and agent we were currently using. This forces users to manually reselect their preferred model and agent every time they switch sessions, which disrupts workflow continuity. ### Current Behavior - User has Session A open with Model X and Agent Y - User switches to Session B using `Ctrl+X l` - Session B loads with whatever model and agent it was last using (e.g., Model Z and Agent W) - User must manually change model and agent back to their preferred selection ### Desired Behavior - User has Session A open with Model X and Agent Y - User switches to Session B using `Ctrl+X l` - Session B loads but retains the session's last model and agent selection (Model X and Agent Y) - User can continue working without manual reconfiguration ### Rationale Users choose the best model and agent for a specific task. Each session serves a specific task, so the current model and agent selection should follow the user as they switch between sessions, rather than being locked to whatever a session was previously configured with. ### Implementation Suggestion Add a setting or default behavior where the current model and agent selection persists across session switches, rather than being tied to the global opencode CLI. ### Additional Context This is different from issue #4344 (model selection not sticking between agent alternation) - this is specifically about session switching via `Ctrl+X l` retaining the current user's model and agent preferences.
yindo added the help-wantedgood first issue labels 2026-02-16 17:39:11 -05:00
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 30, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #4344: Selected model for agent in TUI doesn't stick between Agent Alternation (related model persistence issue)
  • #4742: In Home screen, models stick across agents switching (related inconsistency with model selection persistence)
  • #2390: Switching to a child session doesn't send subsequent messages to that session but to the parent one (related session switching behavior issue)

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 30, 2025): This issue might be a duplicate of existing issues. Please check: - #4344: Selected model for agent in TUI doesn't stick between Agent Alternation (related model persistence issue) - #4742: In Home screen, models stick across agents switching (related inconsistency with model selection persistence) - #2390: Switching to a child session doesn't send subsequent messages to that session but to the parent one (related session switching behavior issue) Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 2, 2025):

Yeah that makes sense

@rekram1-node commented on GitHub (Dec 2, 2025): Yeah that makes sense
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@ph8n commented on GitHub (Dec 3, 2025):

I’d like to take this. Sessions in opencode don’t currently persist model/agent;
they’re tracked as global TUI state.

I see two approaches:

  • A: Derive model/agent from the session’s last user message (good for existing data, but undefined for empty/new sessions).
  • B: Add defaultModel / defaultAgent to Session.Info and have the TUI (and other clients) respect those as the per-session defaults.

What approach is best? I'm leaning toward B, it fits the "sessions serve specific tasks" rationale better.
Would love to contribute once there is a clear direction!

@ph8n commented on GitHub (Dec 3, 2025): I’d like to take this. Sessions in opencode don’t currently persist model/agent; they’re tracked as global TUI state. I see two approaches: - A: Derive model/agent from the session’s last user message (good for existing data, but undefined for empty/new sessions). - B: Add defaultModel / defaultAgent to Session.Info and have the TUI (and other clients) respect those as the per-session defaults. What approach is best? I'm leaning toward B, it fits the "sessions serve specific tasks" rationale better. Would love to contribute once there is a clear direction!
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@JosXa commented on GitHub (Dec 3, 2025):

Thanks @ph8n! 😊

Both aporoaches would be functionally equivalent.
B feels cleaner to me, but I'm not very familiar with the codebase. Both of them could serve a getSessionAgent and getSessionProvider API to expose these things also for other use cases.

Arguably, a "default" for a session is kinda meaningless, right? Like, it's always what you last used - so the term "current" may just aswell be used to not confuse it with global defaults?

@JosXa commented on GitHub (Dec 3, 2025): Thanks @ph8n! 😊 Both aporoaches would be functionally equivalent. B _feels_ cleaner to me, but I'm not very familiar with the codebase. Both of them could serve a `getSessionAgent` and `getSessionProvider` API to expose these things also for other use cases. Arguably, a "default" for a session is kinda meaningless, right? Like, it's always what you last used - so the term "current" may just aswell be used to not confuse it with global defaults?
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@ph8n commented on GitHub (Dec 3, 2025):

@JosXa Good point, "currentModel"/"currentAgent" is much clearer than "default" since it's always what you last used.

@rekram1-node Noticed you labeled this as a good first issue. If the Option B approach sounds good, I'll proceed with extending Session.Info, updating on changes, exposing getters, and reading on switch.

Does this plan cover everything, or am I missing something?

@ph8n commented on GitHub (Dec 3, 2025): @JosXa Good point, "currentModel"/"currentAgent" is much clearer than "default" since it's always what you last used. @rekram1-node Noticed you labeled this as a good first issue. If the Option B approach sounds good, I'll proceed with extending Session.Info, updating on changes, exposing getters, and reading on switch. Does this plan cover everything, or am I missing something?
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 3, 2025):

Hm I think I'm realizing i may have misunderstood op

So is the expectation that whenever you switch sessions it switches to whatever model was last used in that session?

Hmmm

@rekram1-node commented on GitHub (Dec 3, 2025): Hm I think I'm realizing i may have misunderstood op So is the expectation that whenever you switch sessions it switches to whatever model was last used in that session? Hmmm
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@ph8n commented on GitHub (Dec 4, 2025):

@JosXa can you clarify the wanted behavior?

@ph8n commented on GitHub (Dec 4, 2025): @JosXa can you clarify the wanted behavior?
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@JosXa commented on GitHub (Dec 4, 2025):

Hm I think I'm realizing i may have misunderstood op

So is the expectation that whenever you switch sessions it switches to whatever model was last used in that session?

Hmmm

Yes, exactly.

I wanna be able to work on sessions in parallel, not have to reconfigure models and the agent every.single.time I switch between them.

Not a fan?

@JosXa commented on GitHub (Dec 4, 2025): > Hm I think I'm realizing i may have misunderstood op > > So is the expectation that whenever you switch sessions it switches to whatever model was last used in that session? > > Hmmm Yes, exactly. I wanna be able to work on sessions in parallel, not have to reconfigure models and the agent every.single.time I switch between them. Not a fan?
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 4, 2025):

The more i think about it I actually do think i like it? initially i didnt but lemme ask

@rekram1-node commented on GitHub (Dec 4, 2025): The more i think about it I actually do think i like it? initially i didnt but lemme ask
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@ry2009 commented on GitHub (Dec 9, 2025):

@JosXa check out this PR and lmk what you think it should be solved lmk if any errors pop up or any additional requests: https://github.com/sst/opencode/pull/5264

@ry2009 commented on GitHub (Dec 9, 2025): @JosXa check out this PR and lmk what you think it should be solved lmk if any errors pop up or any additional requests: https://github.com/sst/opencode/pull/5264
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@jdanbrown commented on GitHub (Dec 9, 2025):

+1 I found this issue because I was just surprised when resuming a past session didn't restore the agent I was using in that session.

I agree with the rationale at top that sessions represent a user's task, and the user already made a meaningful choice of model and agent for that task. Currently, it's jarring when I run opencode -s <session> and see my old task with the wrong agent and/or model — usually what happens is I send my first message, and only then notice that the agent/model aren't what I expected, and then I have to undo and switch agent/model and then submit it again.

Making agent/model sticky to the session seems like the least surprising UX to me.

@jdanbrown commented on GitHub (Dec 9, 2025): +1 I found this issue because I was just surprised when resuming a past session didn't restore the agent I was using in that session. I agree with the rationale at top that sessions represent a user's task, and the user already made a meaningful choice of model and agent for that task. Currently, it's jarring when I run `opencode -s <session>` and see my old task with the wrong agent and/or model — usually what happens is I send my first message, and only then notice that the agent/model aren't what I expected, and then I have to `undo` and switch agent/model and then submit it again. Making agent/model sticky to the session seems like the least surprising UX to me.
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@jdanbrown commented on GitHub (Dec 11, 2025):

Another motivating example: I was just exploring the same question against two differernt models in parallel, but then something went wonky with my vscode so I had to restart it, and then when I went to resume my two sessions with opencode -s I couldn't remember which model I used for which session. 🙃

@jdanbrown commented on GitHub (Dec 11, 2025): Another motivating example: I was just exploring the same question against two differernt models in parallel, but then something went wonky with my vscode so I had to restart it, and then when I went to resume my two sessions with `opencode -s` I couldn't remember which model I used for which session. 🙃
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@Nickcom4 commented on GitHub (Dec 12, 2025):

I'm in agreement here. I'd like for sessions to continue running in background when I create new ones.

@Nickcom4 commented on GitHub (Dec 12, 2025): I'm in agreement here. I'd like for sessions to continue running in background when I create new ones.
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@ShpetimA commented on GitHub (Dec 25, 2025):

@rekram1-node Created pr for this feel free to check it out I went with the logic of on session change set model to last model used in user message otherwise default to old logic

@ShpetimA commented on GitHub (Dec 25, 2025): @rekram1-node Created pr for this feel free to check it out I went with the logic of on session change set model to last model used in user message otherwise default to old logic
yindo commented 2026-02-16 17:39:12 -05:00
Author
Owner
Copy Link
Copy Source

@snaselj commented on GitHub (Dec 29, 2025):

Additional reproduction case via API (tested on PR #6160):

  • Run opencode serve to start the server
  • Create a session via API request, specifying the Plan agent
  • Run opencode attach to connect to the session
  • The TUI shows Build agent (default) instead of the Plan agent that was specified during session creation

This suggests the agent specified during session creation via API is not being persisted/respected when attaching to the session.

@snaselj commented on GitHub (Dec 29, 2025): **Additional reproduction case via API (tested on PR #6160):** - Run `opencode serve` to start the server - Create a session via API request, specifying the `Plan` agent - Run `opencode attach` to connect to the session - The TUI shows `Build` agent (default) instead of the `Plan` agent that was specified during session creation This suggests the agent specified during session creation via API is not being persisted/respected when attaching to the session.
yindo commented 2026-02-16 17:39:13 -05:00
Author
Owner
Copy Link
Copy Source

@ShpetimA commented on GitHub (Dec 29, 2025):

@snaselj A session creation doesn't have an agent attached only when you send a message for that session will the tui change the default selection to the latest message created with model/agent.
Though i saw your pr in regards to server side sending with /session/:sessionID/message and not specifiying agent I agree it should set to the last agent aswell so I will add that to the pr

@ShpetimA commented on GitHub (Dec 29, 2025): @snaselj A session creation doesn't have an agent attached only when you send a message for that session will the tui change the default selection to the latest message created with model/agent. Though i saw your pr in regards to server side sending with /session/:sessionID/message and not specifiying agent I agree it should set to the last agent aswell so I will add that to the pr
yindo commented 2026-02-16 17:39:13 -05:00
Author
Owner
Copy Link
Copy Source

@snaselj commented on GitHub (Dec 29, 2025):

@ShpetimA Right, I created the session and then sent the API request prompt specifying agent, sorry for confusion. I was unable to fix it in the PR, so I rather closed it.

@snaselj commented on GitHub (Dec 29, 2025): @ShpetimA Right, I created the session and then sent the API request prompt specifying agent, sorry for confusion. I was unable to fix it in the PR, so I rather closed it.
yindo commented 2026-02-16 17:39:13 -05:00
Author
Owner
Copy Link
Copy Source

@jamiehicks154 commented on GitHub (Jan 15, 2026):

Hi! I'd like to take a crack at this. My approach: add an effect in local.tsx that watches for session route changes and restores the model/agent from the last user message. This follows Option A discussed above - no schema changes needed since user messages already store model and agent. Let me know if this sounds good before I open a PR.

@jamiehicks154 commented on GitHub (Jan 15, 2026): Hi! I'd like to take a crack at this. My approach: add an effect in local.tsx that watches for session route changes and restores the model/agent from the last user message. This follows Option A discussed above - no schema changes needed since user messages already store model and agent. Let me know if this sounds good before I open a PR.
yindo commented 2026-02-16 17:39:13 -05:00
Author
Owner
Copy Link
Copy Source

@JosXa commented on GitHub (Jan 16, 2026):

Hi! I'd like to take a crack at this. My approach: add an effect in local.tsx that watches for session route changes and restores the model/agent from the last user message. This follows Option A discussed above - no schema changes needed since user messages already store model and agent. Let me know if this sounds good before I open a PR.

@ShpetimA already had a PR open, check if you can review and improve upon it first please :)

@JosXa commented on GitHub (Jan 16, 2026): > Hi! I'd like to take a crack at this. My approach: add an effect in local.tsx that watches for session route changes and restores the model/agent from the last user message. This follows Option A discussed above - no schema changes needed since user messages already store model and agent. Let me know if this sounds good before I open a PR. @ShpetimA already had a PR open, check if you can review and improve upon it first please :)
yindo commented 2026-02-16 17:39:13 -05:00
Author
Owner
Copy Link
Copy Source

@jamiehicks154 commented on GitHub (Jan 16, 2026):

@JosXa sorry that was my bad and missed that a PR was already open

@jamiehicks154 commented on GitHub (Jan 16, 2026): @JosXa sorry that was my bad and missed that a PR was already open
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label good first issue help-wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3220
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?