Activating Live Chat

Out of the box, StretchGPT is in a safe, non-live state: it accepts messages and saves conversations but doesn't call a model until an operator activates it. This short guide is the checklist to get from "blocked" to real, live answers.

Understand what "activated" means

Live chat requires three things to be true at once:

1. A model provider is connected — a backend that can run a model.
2. A model is configured — the provider has a default model ID to use.
3. Live execution is enabled — the runtime is switched on for chat.

Until all three hold, StretchGPT's execution gate keeps chat in dry-run/blocked mode and every reply explains what's missing. This is the safety envelope working as designed.

The activation checklist

1. Confirm encryption is configured for the control plane so provider keys are stored encrypted. If it isn't, set it up first.
2. Connect a model provider. Complete the step-up authorization, paste the provider's API key, and set a default model and a fallback order. See Connecting a Model Provider for the full walkthrough.
3. Set the provider as primary for the chat role so the chain resolves it.
4. Enable live execution for the runtime.
5. Send a test message. A blocked reply lists the remaining prerequisites; a live reply confirms you're activated.

Reading the activation status

When chat is blocked, the response includes activation requirements and blocked reasons that map directly to the checklist above — for example, provider not connected, model id not configured, or chat execution disabled. Work down the list until every requirement is satisfied and the blocked reasons clear.

A realistic example

You open StretchGPT for the first time and send "hello." The reply is blocked with reasons provider_not_connected and chat_execution_disabled. You:

1. Connect a teacher model as a provider (step-up authorized), set its default model, fallback order 100.
2. Mark it primary for chat.
3. Enable live execution.
4. Send "hello" again — this time you get a real greeting back, and the status shows the runtime as live with the provider connected.

Later, when your proprietary model is production-ready, you add it as a higher-priority provider so it answers first, with the teacher as fallback — no re-activation needed.

Tips

• Do it in order. Provider → default model → primary → enable execution → test. Skipping a step just moves the blocked reason down the list.
• Keep a fallback provider. If your primary can't answer, the chain keeps chat alive.
• Use a dry-run test first to confirm wiring before enabling live execution, especially in a fresh environment.
• Watch the blocked_reasons after each step — they're the fastest way to see what's left.

Troubleshooting

Still blocked after connecting a provider. Check that the provider is enabled, has a default model, and is set primary for chat — and that live execution is enabled. Any one missing keeps chat blocked.

It worked, then stopped. A provider may have been disabled, revoked, or had its key rotated incorrectly. Re-check the provider chain and the key.

I don't have permission to activate. Connecting providers and enabling execution are gated admin actions. You need step-up authorization with the appropriate scope, or an admin to perform the steps.