Skip to content

article

Connecting a Model Provider

Register, configure, and manage the model backends that generate StretchGPT's answers — with encrypted keys and a governed fallback chain.

StretchGPT's answers come from model providers — the backends that actually run the models. Administrators connect providers, choose a primary, order a fallback chain, and rotate or revoke keys over time. This article walks through the full lifecycle. Every change here is a sensitive operation and requires step-up admin authorization.

How the provider chain works

StretchGPT resolves a provider chain for chat rather than a single provider. For a normal chat turn it tries providers in order — your proprietary, self-hosted model first (when it's promoted and serving), then a teacher fallback (a strong third-party model). This is what lets StretchGPT prefer your own model while never leaving a user without an answer. Each answer is tagged with which provider produced it and whether it was your proprietary model.

Before you start

  • You need admin rights and the ability to complete a step-up authorization (an admin action token) — connecting and changing providers requires the stretchgpt:providers:manage scope.
  • Have the provider's API key ready.
  • Confirm encryption is configured for the control plane. Provider keys are encrypted at rest; if encryption isn't set up, connect it first so keys are never stored in the clear.

Registering a provider

1. Open the Providers area of the StretchGPT console.
2. Click Connect provider and complete the step-up authorization prompt.
3. Fill in the details:
- Provider — which backend this is.
- Label — a human-friendly name so you can tell providers apart.
- Purpose — what this provider is for.
- Model roles — the roles this provider can serve (for example, primary chat).
- Default model — the model ID to use by default.
- API key — pasted once; it's encrypted immediately and never returned by the API afterward.
- Fallback order — a number that positions this provider in the chain (lower runs earlier).
4. Save. The provider is created and appears in your list. The key material is stored encrypted and is never shown again.

Managing providers

All of the following require the same step-up authorization:

  • Set primary — mark a provider as the primary for its role.
  • Enable / disable — turn a provider on or off without deleting it.
  • Set default model — change which model ID the provider uses by default.
  • Rotate key — replace the stored API key with a new one (the old key is superseded).
  • Revoke — retire a provider so it's no longer used.

When you list providers, the API returns each provider's configuration and confirms that keys are encrypted at rest and that no key material is ever returned — you'll never see the secret again after you enter it.

A realistic example

You're standing up StretchGPT for the first time. You connect a strong teacher model as your provider with fallback order 100 so chat works immediately. Weeks later, your proprietary StretchAI model reaches production and starts serving. You connect it as a provider with fallback order 10 and set it primary for primary_chat. Now every chat tries your own model first and only falls back to the teacher if your model can't answer. When the teacher key needs rotating for security, you use Rotate key — no downtime, no re-connecting.

Tips

  • Order the chain deliberately. Lower fallback numbers run first; put your preferred/proprietary model earliest.
  • Disable instead of revoke when pausing. Disabling is reversible; revoking retires the provider.
  • Rotate keys on a schedule. Rotation swaps the secret without disrupting the chain.
  • Keep a fallback connected. A single provider means a single point of failure; a teacher fallback keeps chat alive.

Troubleshooting

Chat says no provider is connected. No enabled provider is resolving for the chat role. Connect one (or enable an existing one) and confirm it's set for the primary chat role.

My change was rejected as unauthorized. Provider changes need step-up admin authorization with the providers-manage scope. Re-authorize and try again.

I need to see the stored API key. You can't — keys are encrypted at rest and never returned. If you've lost the key, rotate it with a fresh one.

Encryption isn't configured. Configure control-plane encryption before connecting providers so keys are never stored in plaintext.

Was this helpful?

Help us improve this article

Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.