Repository navigation
Image input is rejected after switching from a non-vision model within the same session #33199
Description
Description
When a session starts with a non-vision-capable model, switching to a vision-capable model in the same session does not enable image input. The system continues to report that the model does not support images. However, starting a new session with the vision-capable model works correctly.
Steps to Reproduce:
Start a new conversation and select a non-vision model (e.g., kimi-k2.6).
Send a message with an image attachment.
Observe the error: the model responds that it cannot process image input.
Switch the model in the same session to a vision-capable model (e.g., one that supports image input).
Send another message with an image attachment.
Bug: The system still responds that image input is not supported.
Start a brand new session with the same vision-capable model.
Send a message with an image attachment.
Expected: Image is processed correctly (and it does).
Expected Behavior: After switching to a vision-capable model within an existing session, subsequent requests should allow and process image inputs as if the session had started with that model.
Actual Behavior: The session retains the "no vision" capability flag from the initial model selection, causing image input to be blocked even after the model is changed to one that supports vision.
Workaround: Start a new session after switching to a vision-capable model.
Environment:
OpenCode version: [e.g., latest / specific version]
OS: Windows
Model used initially: kimi-k2.6 (non-vision)
Model switched to: [your vision model name]
Plugins
No response
OpenCode version
1.17.9
Steps to reproduce
1.Start a new conversation and select a non-vision model (e.g., kimi-k2.6).
2.Send a message with an image attachment.
3.Observe the error: the model responds that it cannot process image input.
4.Switch the model in the same session to a vision-capable model (e.g., one that supports image input).
5.Send another message with an image attachment.
6.Bug: The system still responds that image input is not supported.
7.Start a brand new session with the same vision-capable model.
8.Send a message with an image attachment.
9.Expected: Image is processed correctly (and it does).
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
Necmttn commentedon Jun 21, 2026
Model capabilities should be resolved per request after a model switch, not cached from the session's first model. Keep capability state keyed by provider id, model id, and provider metadata revision, then invalidate attachment validators when the active model changes.
A regression can start with a text-only model, reject image input, switch to a vision model, and assert the next image request uses the new model's capability set. Also test the reverse switch blocks images again.
Generated with ax.
lexlian commentedon Jun 23, 2026
@ldz1216 @jlongster , I fixed the issue with PR #33471.
When the user switched models in the UI, local.model.set() only updated the local persisted store. The server's SessionTable.model was only updated when a prompt arrived with a different model: field. The session runner resolved models using SessionTable.model, causing image/vision capability checks to fail with the wrong model between the UI switch and the next message.
The fix adds a POST /api/session/{sessionID}/model endpoint that publishes ModelSwitched immediately, keeping server state in sync with the UI.
github-actions commentedon Aug 23, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.