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.

2026-09 model refresh

The catalog is verified against each relay’s own published catalog: AtlasCloud (GET https://api.atlascloud.ai/api/v1/models), WaveSpeed (https://wavespeed.ai/api/models), AceData (docs.acedata.cloud/openapi/*.json model enums) and Grsai (its API docs plus grsai.ai/dashboard/models). Run pnpm audit:models to re-check every slug; it also runs on model-registry pull requests and nightly. The current generation per family: Retired upstream and removed from the catalog: Suno chirp-v3.5/v4/v4.5/v5 (promoted to chirp-v6 on generation), Gemini 2.0-flash (falls back to the default describe model) and gemini-3-pro-preview (migrated to gemini-3.1-pro-preview). WaveSpeed no longer serves openai/gpt-image-1*, so those variants are promoted to openai/gpt-image-1.5 on that relay. 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. Once you save a credential it stays saved until you change, delete, or clear it: the full snapshot is written immediately, then upgraded to its encrypted form as soon as the local vault finishes (usually a few milliseconds). If encryption is unavailable — for example a non-secure http:// origin without crypto.subtle — the credential is kept unencrypted rather than discarded, so it is never lost. Signing out clears local credentials too. The account session ends and every credential this device stored on your behalf is removed: provider and relay API keys, access/secret keys, tokens, MCP secret references, and the local vault key itself. Base URLs, model choices and other non-secret preferences stay. This is what makes “sign out” safe on a shared machine — and it means you re-enter your keys the next time you sign in on that device. The button is labelled Sign out & clear local credentials for that reason. The credential-free snapshot is written before the vault key is destroyed, so no undecryptable leftover is left behind. Keys are encrypted with a non-exportable, device-bound key kept in IndexedDB. They stay on this device and are never uploaded to Redbit. That protects against offline copies, browser-profile backups, and storage-scanning infostealers; it does not protect against scripts running on the page itself. Redbit keeps no server-side copy, so clearing browser data removes the stored keys with it. 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.