New chats do not reuse recent models or follow Desktop model-selection precedence

Abierto
  • ¿Algo no está bien?
#104 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, kotlin
Área
ai, mobile

Línea de trabajo

Start with SessionsViewModel.startNewSession/create, RemoteSessionRepository.create, and AgentInfo.toDomain in ResourceMapping.kt; compare their behavior with the Desktop selection precedence linked in the issue. Trace how agent and global defaults, recent models, and server fallback are resolved, then add coverage for the listed precedence and session-isolation cases. Done means new chats follow the stated precedence while existing chats retain their selections.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happened?

When switching between chats and starting a new session without manually selecting a model, the model used feels unpredictable: it does not follow the last-used model as expected.

In the reported example, a new Plan chat used GPT-6.1 Terra · GitHub Copilot. Sending Test failed with Provider request failed with HTTP 401. The 401 is an observed provider-authentication error, not proof that model selection itself caused the authentication failure.

Steps to reproduce
  1. Use a model in an existing chat.
  2. Switch chats and start a new session without explicitly choosing a model.
  3. Send a prompt and inspect which model is used.
Expected behavior

Use predictable selection consistent with OpenCode Desktop, with as little mobile-owned configuration as possible:

  1. Explicit selection for the new chat.
  2. Server-configured model for the selected agent (e.g. Plan/Build).
  3. Explicit global server model configuration.
  4. Last-used model that is still available.
  5. Server-owned fallback. If no configuration or history exists, prefer an available free OpenCode model where supported by the server policy, without hard-coding model IDs in mobile.

Existing chats should retain their own selections; opening a chat should not silently replace its model with another chat's recent model.

Source investigation
  • SessionsViewModel.startNewSession/create leaves the new model null unless manually selected. Recent models populate the picker but are not used to initialize the selection.
  • RemoteSessionRepository.create forwards that optional model to the server. No random selection was found in this mobile path: an unspecified model delegates resolution to the server.
  • The pinned API contract and generated ModelApi already expose GET /api/model/default, but mobile does not consume it.
  • AgentInfo.toDomain in ResourceMapping.kt does not retain the agent's model configuration.
  • Current Desktop new-chat selection explicitly resolves draft selection → agent model → configured global model → valid recent model → connected-provider fallback, then sends the resolved model when creating the session:

This is a source-based explanation of the behavior gap, not a live trace proving why that specific Copilot model was resolved. Upstream links refer to the inspected current commit, not a verified checkout of server 2.1.4.

Suggested approach / alternatives

Prefer existing server APIs and agent configuration; keep only minimal recent-selection state on mobile, scoped to the server. Do not add a second mobile model-configuration system.

Continuing to omit the model delegates everything to the server but does not reproduce Desktop's recent-model behavior. Conversely, always taking /api/model/default before recents is not necessarily equivalent either: it can return an implicit fallback, not just an explicitly configured global default. Distinguish explicit configuration from fallback when applying Desktop's precedence.

Verification

Cover agent-specific and global defaults, recent-model fallback, removed/unavailable recent models, no-history fallback, Plan/Build switching, reopening existing sessions, and isolation between servers.

Environment
  • App: 0.9.0 (latest published release, as requested by reporter)
  • OpenCode server: 2.1.4 (reported)
  • Device: Samsung Galaxy S23+
  • Android: 16, One UI 8.5
Screenshot

Screenshot_20261028_162136_OpenCode Mobile.jpg

Lenguaje dominante
Kotlin
Estrellas
1
Forks
0
Merge medio
11 h 35 min
PR fusionados (30 d)
48

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de beppe2880/opencode-mobile

Todos los issues de beppe2880/opencode-mobile

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.