Model connections and availability
Manage provider identities, connection instances, model catalogs, and task routing together. This page helps you change models, check connections, and diagnose failures. Use Models and services for connection fields and Model selection and routing for defaults and tiers.
Separate availability from defaults
Provider identity and credentials determine model access. A connection stores protocol, endpoint, and authentication. The catalog supplies model choices, while defaults and routing select configured models for work. Changing a default does not change provider permissions or quota.
| Observation | Established | Still to check |
|---|---|---|
| Connection test succeeds | That connection passed its test | Target model and workflow capabilities |
| Model appears in a list | A catalog entry exists | Latest refresh and current account access |
| Minimal text request succeeds | Text requests to that model work | Required image, tool, or other capabilities |
| Default is saved | The choice was recorded | Actual task connection and routing |
One provider can have multiple instances. Note instance name, purpose, account, model ID, and billing account so you do not confuse testing and everyday connections. Do not record secret values.
Introduce a model or replace a connection
- Confirm provider, protocol, endpoint, account access, and exact model ID.
- Create or edit the intended instance and verify application of the saved settings. Address failures before changing unrelated connections.
- Refresh the catalog, run a minimal text request, then verify capabilities required by the workflow.
- Change relevant defaults and routes, preserving previous choices and a replacement plan.
- Verify the actual connection and model in representative work, inspect outputs and usage, then expand.
Supply credentials through dedicated fields or controlled credential procedures, not chats, skills, or project notes. Diagnose the intended identity rather than concealing authentication failures with a more privileged account.
Scenario: a provider retires a model
Inventory defaults, routing tiers, and workflows that explicitly name the old model. Validate replacement capabilities and results on representative work, then update those references. Changing a global default does not address explicit selections.
Retain before/after model IDs, instances, and validation. Before removing the old connection, establish replacements for affected defaults, routes, and tasks. Revoke unused keys or cancel subscriptions separately with the provider.
A working connection with a failing task
Check the selected instance, model ID, quota, network, and required capabilities in that order. Connection tests and task requests have different scope. A previously loaded catalog is not current availability evidence after a failed refresh.
Your setup is ready when the intended connection works for your task and you know which account is charged. Permissions and approvals still govern tools, files, and external actions.