Models

Models tell OpenVibely how to run AI work. Users configure them from the Models screen, then pick them as project defaults, task-specific choices, or agent defaults.

What Users Do In Models

Open Models from the System section of the sidebar and create a model config.

Supported Providers

A test provider exists in source code for tests and is not documented as a normal production provider.

OpenAI-Compatible Models

Choose an OpenAI-compatible preset when your provider or gateway already matches one of the supported setup patterns. OpenVibely ships presets for hosted gateways and providers such as OpenRouter, NVIDIA NIM, DeepInfra, Fireworks, Groq, Mistral, Cerebras, Together, Hugging Face Router, DeepSeek, Moonshot, DashScope/Qwen, Z.AI/GLM, StepFun, Tencent TokenHub, and several local runtimes including vLLM, LM Studio, SGLang, LiteLLM, Inferrs, and ds4. Presets fill in the expected endpoint details and, when the provider exposes a compatible model list, the Models screen can discover available models for you.

Use a custom OpenAI-compatible endpoint for local gateways, self-hosted inference, or providers that are not listed as presets. In that case, provide the base URL, auth header behavior if required, and either discover models from the endpoint or enter the model ID manually. Public endpoints should use HTTPS; plain HTTP is intended for localhost or private network hosts. The full preset list lives in Model Providers.

Reasoning And Model Settings

The Model dialog shows only settings supported by the selected provider and model. gpt-6-astra offers low, medium, high, xhigh, and max reasoning effort, uses medium when no effort is configured, and does not support none or configurable temperature. gpt-6-sol and gpt-6-luna add none to those effort choices and also default to medium. OpenVibely hides Temperature for Astra and ignores stale submitted temperature values.

Current Claude models can expose xhigh where the provider supports it. Claude Opus 5.5, Fable 5.1, and Mythos 5.1 are available in the Anthropic selector; consult Model Providers for their supported effort levels and provider-specific constraints.

Context Limits And Setup

The model editor groups settings into tabs and supports OAuth connection before saving a configuration. Compatible endpoints can supply model metadata through discovery; Ollama setup can discover installed models from its base URL.

In the Generation tab, Context window (tokens) sets the working context size and Compact conversation at (tokens) controls when history is compacted. The editor fills suggested positive values from the model's limits; verify the window against your server when discovery cannot report it.

OpenAI-compatible and Ollama configurations also expose Max output (tokens). Leave room for input; for context windows smaller than 32,768 tokens, the editor limits output to one quarter of the window. OpenAI and Anthropic adapters manage their output budgets without this control. Conversation composers offer searchable model selection, saved favorites, and supported reasoning-effort overrides.

Manage Model Configurations

Use the Models collection toolbar to search configurations, including connected OAuth account labels, filter by provider, default status, authentication, or kind, and sort the results. Select configurations to delete several at once only after checking that no project, agent, or Mixture of Models still depends on them.

OAuth credentials are stored as reusable provider connections. Multiple compatible model configurations can link to the same connection, so refreshed credentials and account identity stay consistent across those models. The model editor shows the selected provider account and lets you connect a new account or choose an existing compatible connection. Before disconnecting one, review the models listed as using it.

OpenVibely refreshes eligible OAuth credentials before expiry and persists refreshed state so restarts do not revert to stale tokens. If a provider rejects refresh or requires renewed consent, the affected connection is marked for reauthentication instead of silently borrowing another account. Usage and cooldown state remain attributed to the exact provider connection.

Mixture Of Models

Create a Mixture of Models after configuring the individual models it should call. Choose one or more references and one aggregator; references run concurrently as private advisory calls with tools disabled, then the aggregator receives their output and produces the visible response with its supported runtime capabilities.

Each turn calls every reference plus the aggregator, so the Models dialog shows the expected call count and cost warning. The dialog also controls reference timeout and separate reference/aggregator temperatures. Mixtures cannot recursively reference other mixtures, and a model config cannot be deleted while a mixture still depends on it.

See Mixture of Models for execution order, defaults, capacity, failure behavior, and tool policy.

Choosing Defaults

Set an app-level default model if most work should use the same provider. Set a project default when a repository should prefer a different model. Pick a task model only when the task needs a one-off override.

Related Pages