Providers, Models, and Credentials

WRM organises AI model access through three core concepts — models, providers, and availabilities — connected by the model availability relationship. This page explains how the concepts relate, how credentials are managed, and how worker definitions select which models to use.

Models, providers, and availabilities

Models

A model is a provider-independent definition of an AI model. Each model record includes:

• Name — the model's display name (e.g. "Claude Opus 4")
• Model family — a grouping for related models (e.g. Claude, GPT)

Models exist independently of any provider. Claude Opus 4 is one model regardless of whether it is accessed through Anthropic's direct API, Amazon Bedrock, or both. This separation is important — it means a model is not tied to a single provider, and the same model can be made available through multiple providers.

Providers

A provider is an inference vendor or gateway that serves AI models. Examples include Anthropic, OpenAI, and Amazon Bedrock. Each provider record includes:

• Name — the provider's display name
• Provider type — a lookup value identifying the provider category
• Merchant link — a reference to the provider's merchant record in XRM, where credentials are stored

Raytio ships with a starter set of providers (Anthropic, OpenAI, Amazon Bedrock) included in each tenant.

Availabilities

An availability is the relationship that makes a model available through a specific provider. It connects a model to a provider and supplies the provider-specific details needed to call that model through that provider.

Each availability record includes:

• Model link — which model this availability is for
• Provider link — which provider serves this model
• Model identifier — the provider-specific API identifier (e.g. claude-opus-4-20250514 for Anthropic, or an ARN for Bedrock)
• Region — the deployment region (e.g. us-east-1)
• Endpoint URL — the API endpoint to call
• Pricing information — input and output token costs

A single model can have multiple availabilities across different providers and regions. A single provider can serve multiple models. The availability is the many-to-many relationship between them, and it is the level at which worker definitions express model preferences.

Availabilities give you fine-grained control over where and how models are accessed, which matters for latency, cost, data residency, and execution harness compatibility.

Model parameters

Each model availability can have associated model parameters that define default configuration values for that model — settings like temperature, max tokens, top-p, and other provider-specific options.

When a worker definition adds a model preference, it can optionally override these defaults for its specific use case. For example, a creative writing worker might use a higher temperature than the default, while a code review worker might use a lower one.

Managing provider credentials

Provider API keys and authentication details are held apart from worker configuration. Whichever path a given credential takes, the same guarantees hold:

• API keys are encrypted, and worker configuration and starter data reference the credential rather than its value
• Each tenant manages its own provider credentials independently
• Rotating a key is a credential operation, leaving every worker and definition unchanged

Provider records link to the provider's merchant record, and credentials are managed through the same interface used for all merchant authentication in Raytio. Platform-side operations that call a provider directly — for example, indexing content for semantic search — resolve their key from the platform's managed secret store rather than from per-provider configuration.

important

Starter provider data covers configuration only. After the starter providers are created in your tenant, configure credentials for each provider to make it available to workers.

note

These are the credentials the platform uses to reach AI providers. A secret that an individual agent needs for its own task — an access token for a third-party service, say — follows a different path: the agent requests it from a named person and receives it encrypted, with an expiry. See Agent Credentials.

How worker definitions select models

Worker definitions specify model preferences — an ordered list that controls which models a worker should use:

Field	Purpose
Availability	Which specific model availability to use
Priority	Ordering — lower numbers are tried first
Parameter overrides	Optional overrides for default model parameters (temperature, etc.)

The priority ordering enables fallback behaviour: if the first-choice availability is unreachable or rate-limited, the system falls back to the next preference in the list. Because each availability identifies both a model and a provider, failover can cross providers and even model families.

Selecting a model preference also determines the execution harness — the agent CLI or runtime used to run the worker. The platform resolves a compatible harness automatically from the chosen availability; you do not need to set a harness on the worker definition. See Execution Harnesses for details on how this resolution works, including cross-harness failover.

Example configuration

A worker definition for code review might specify:

1. Priority 1 — Claude Opus 4 via Anthropic direct API (us-east-1) → resolved harness: Claude Code
2. Priority 2 — Claude Opus 4 via Bedrock (us-east-1) → resolved harness: Claude Code
3. Priority 3 — GPT-4o via OpenAI (default endpoint) → resolved harness: Codex

If the Anthropic API is down, the worker falls back to Bedrock (still using Claude Code). If Bedrock is also unavailable, it falls back to GPT-4o using Codex — the harness changes automatically because the model requires a different runtime.