Skip to main content

​
Models and Provider Configuration

Redbit uses a model registry rather than scattering provider choices across individual components. Settings chooses the active model family and variant for each media type; the registry defines what that model supports; payload builders create provider-specific requests. Model routing diagram showing Settings, model registry, payload builders, direct provider routes, relay routes, and Agent profiles. Configuration boundary diagram showing Settings, browser storage, direct providers, relay providers, optional Local Core, MCP, and external automation boundaries.

​
Who Should Read This

Read this before configuring real provider access, debugging a missing model, or explaining where API keys, relay routes, Agent profiles, and Local Core boundaries sit.

​
Before You Read

Redbit is BYOK by default. Settings can store credentials and route requests, but the provider account controls quota, billing, access region, safety policy, retention policy, and model uptime.

​
Configuration Layers

​
Current Catalog Snapshot

Exact availability in the UI can change when relay mode or custom relay model lists are enabled, because Settings filters visible models by provider capability. Different models should not be expected to produce identical results from the same prompt. They may differ in prompt interpretation, reference strength, aspect-ratio support, safety filters, latency, output format, and whether they support image, video, audio, or structured inputs.

​
Direct Provider vs Relay

​
Credential Handling

Settings persists configuration in browser storage. Sensitive fields such as API keys, access keys, secret keys, and tokens are encrypted before persistence when available. If encryption or persistence fails, Redbit stores a redacted emergency snapshot rather than writing raw secrets. Practical guidance:
  • store credentials only in Settings;
  • avoid pasting keys into cards, Workshop scripts, or Agent chat;
  • use the smallest provider scope needed for the current workflow;
  • rotate keys in the provider console if a key was exposed outside Settings;
  • check provider terms before uploading confidential media.

​
Agent Runtime Profiles

The Agent model is configured separately from generation models. Settings supports:
  • auto: resolve a compatible assistant runtime from existing settings;
  • relay: use a chat-capable relay route when available;
  • custom: configure provider preset, protocol, base URL, API key, model ID, and optional role overrides.
Discovery reads available model IDs where the provider exposes a models endpoint. The capability test makes a real call and saves a local profile for tool calling, structured output, system prompt, and vision support. A failed required probe should not become the saved default profile.

​
Next Step

Continue to Security and Credentials before sending sensitive material through a provider route, or Agent Workflows to understand how the selected Agent runtime profile affects tool execution.