Skip to main content

​
Model Providers

This page covers model providers, not chat channels like Telegram, Discord, or WhatsApp. For model selection rules, see /concepts/models.

​
One authenticated catalog

Normal setup uses one Gateway-owned catalog. Onboarding, CLI, Agent > Models, Chat, Tasks, and channel-routed Agents consume the same authenticated payload:
  • same provider order
  • same provider names
  • same auth methods
  • same route-compatible model lists
  • same capability metadata
That payload keeps three lists separate:
  • Available is everything the authenticated credential or local endpoint reports as usable.
  • Recommended is Fased’s ranked subset of the available list.
  • Assigned is the exact model record saved for an Agent role.
Recommendations never act as an entitlement filter. A saved assignment keeps the public provider, credential route, transport, model ID, and capability record together so Chat and scheduled Tasks cannot silently reconstruct a different route from a model-name string. The sources have separate jobs:
  1. The provider’s authenticated model endpoint determines API-key route availability. OAuth/device routes use the authenticated runtime catalog so Fased does not offer a reviewed model that the signed-in account rejects.
  2. Official provider documentation supplies reviewed capability metadata when the provider response does not include it.
  3. Fased’s curated registry ranks recommendations and task roles. It does not make an unavailable model available.
  4. Explicit custom models remain local configuration and are labeled as such.
Provider brands can have more than one credential route. OpenAI, for example, appears once while ChatGPT sign-in and OpenAI API-key access remain independent underneath it. Fased-managed optional transports are installed during the relevant sign-in flow and reconciled to the target release by fased update; the application never selects an arbitrary executable from the system PATH. Each model payload records its availability source, capability source, retrieval date, auth route, and confidence. If authenticated discovery is temporarily unavailable, Fased does not claim the reviewed catalog is executable. Retry the provider connection or catalog refresh. Old upstream/runtime providers are compatibility inputs only. They should not appear as normal first-run choices unless they are added to the Fased provider registry below.

​
Current Provider Order

Signed-in providers can float to the top of Agent > Models provider controls, but the default ordering is: Qwen portal sign-in is not a normal setup method. Use Coding Plan or DashScope API keys.

​
Normal setup path

Use this path after onboarding:
  1. Agent > Models: add a provider credential, sign in, paste an API key/token, or configure a local/manual endpoint.
  2. In the same Agent > Models tab, choose that Agent’s primary, fallback, and task model refs.
  3. /chat: talk to the selected Agent. The model picker can override the model for the current chat session when the selected provider route is usable.
  4. Agent > Channels: connect apps such as Telegram or Discord and route each account/topic/guild to the selected Agent.
The Agent owns model defaults, skills, services, saved context, chat app routes, tasks, and wallet controls. Browser chat and connected chat apps both talk to an Agent; they are different delivery surfaces for the same setup.

​
Model Metadata And Provenance

Each recommended model should have capability metadata. The UI uses this data to decide what to show in Chat:
  • context window
  • max output tokens
  • input modes such as text or image
  • output modes such as text, audio, speech, or video when known
  • tool support
  • JSON support
  • thinking/reasoning mode
  • supported thinking levels
  • default thinking level
  • private-network or manual setup requirements
  • auth mode hints
  • availability and capability source
  • catalog retrieval/review time
  • recommendation rank
Some providers expose this cleanly from their model catalogs. Others do not. For local/manual providers, metadata can be curated or user-supplied. Unknown metadata must stay explicit; the UI should not pretend a model supports thinking, tools, images, speech, or video when the registry does not know. Local providers are always discovered from the configured Ollama, LM Studio, vLLM-compatible, or LiteLLM server. Fased does not invent a local model named local or default. Start the server and load a model there first, then refresh the Agent model page.

​
Provider Registry Refresh

Fased owns the normal setup provider manifest instead of blindly showing every model returned by an upstream runtime catalog:
The refresh is review-first. It reports new models, source-missing routes, and capability changes. It must not silently delete curated models or break existing Agent configs. Apply only after review:
Manual model edits are separate from live refresh:
providers models add/remove edits configured provider entries for the current installation. providers refresh updates the shared curated registry only after review or explicit apply. The Dashboard, Chat, Agent defaults, Tasks, and models.list requests use the same authenticated catalog. The all flag can include every model available through the Agent’s configured provider routes, but it does not bypass account availability or restore historical SDK entries. Dynamic local providers and explicitly configured custom models remain selectable because their catalog belongs to the operator’s own endpoint.

​
Local Models

Use one of the registry-supported local/manual routes:
  • Ollama: local, tailnet, or Ollama Cloud setup with the native /api/chat path.
  • LM Studio: local model discovery from LM Studio, usually on localhost:1234.
  • vLLM: a vLLM server exposed as a first-class local provider.
  • LiteLLM: multiple models routed through a LiteLLM gateway.
  • Cloudflare AI: Cloudflare AI Gateway routing.
  • Custom Provider: another OpenAI-compatible or Anthropic-compatible endpoint, including SGLang.
Ollama is native in Fased. Use http://127.0.0.1:11434, not /v1. LM Studio is OpenAI-compatible and normally uses http://127.0.0.1:1234/v1. SGLang stays under Custom Provider or vLLM-compatible setup unless Fased adds a dedicated provider card later.

​
Credential rotation

For normal use, add multiple credentials as auth profiles in Agent > Models or with the models auth CLI. Fased orders those profiles, skips profiles in cooldown, and rotates only for failover-worthy provider errors. See /concepts/model-failover. Single environment variables such as OPENAI_API_KEY, ANTHROPIC_API_KEY, and provider-specific API key variables can still back a credential or compatibility provider config. They are not the preferred way to manage multiple user-facing profiles.

​
Advanced Compatibility

Raw config may still contain legacy runtime providers or provider adapters for existing installations. That compatibility layer is not the normal setup path. For normal users, use Agent > Models, Chat, and Agent > Channels with the current provider registry above.