Skip to content
PRESHaiPRESHaiPRESHos Platform

Model selector

Open in product: preshos.com/agent-ops/model-selector

The model selector names which model a session reasons with, and how hard it reasons: model plus reasoning effort apply to the run. It changes how the agent thinks through the work — not what the agent is allowed to touch. Environment policy, tool grants, and approval gates apply the same regardless of the model picked.

What the choice changes

Section titled “What the choice changes”
  • Reasoning style and strength for the task at hand: harder judgment work earns the stronger model, routine reads do not need it.
  • Cost and latency posture of the session. Stronger models cost more per step; long sessions multiply the difference.
  • Nothing about scope. A different model in the same environment sees the same systems under the same policy.
Model selector: available models with capability and status per row

What the choice never overrides

Section titled “What the choice never overrides”
  • The environment tool list. If a system is not listed there, no model reaches it.
  • Approval gates. Risky actions pause for a human decision under every model.
  • The recorded outcome. Model, runs, and tokens stay on the record either way.

An honest limitation

Section titled “An honest limitation”

A speed control is transmitted with the run but currently has no effect on it. Judge speed by the session in front of you, not the setting — and treat the product UI as the source of truth if its behavior changes.

Choosing well

Section titled “Choosing well”
  • Default to the agent’s configured model. It was picked for that workload; overrides need a reason.
  • Change the model for the work, not the mood. A stuck session usually needs rescoping, not a stronger model.
  • When no model looks right or the picker is empty, ask the tenant admin. Available models come from the model registry.

Favorites and governed selection

Section titled “Favorites and governed selection”
  • Personal favorites. Star the models you reach for and they surface first in the picker. Favorites are yours — they change your picker’s order, nothing about what the session may use.
  • Governed selection. Agents carry a model_selection policy — allow, deny, or recommend — enforced on session start and dispatch. An allow list bounds the picker to named models; a deny list removes named models from it; a recommend list orders the picker without bounding it. The agent’s config is the source of the policy; the picker shows its result. See Agent config.
  • Chat pickers show chat models. Non-chat image and embedding models stay out of the Agent Ops chat pickers even when the tenant carries them — they are callable by agents behind the scenes, not selectable as the session’s reasoning model. Judge the picker by what the session needs to think with.
  • Treat the product UI as the source of truth for the exact favorite, catalog, and policy affordances.

What next

Section titled “What next”