All Things OpenClawAll Things OpenClaw
CONFIG • OpenClaw quick fix
Featured: @JasonFairhurst2

Model moved after 2026.6.10? Prove the provider route.

OpenClaw 2026.6.10 says provider routing, session identity, and fallback visibility got more reliable, but a migration can still look broken when the model string changed and the provider route did not. The trap is checking only `openai/gpt-5.5` while the effective provider, auth profile, or sticky fallback state is still sending work somewhere else. Treat the fix as a route receipt: confirm the model prefix, inspect the provider config/auth source, restart through the real supervisor, run one tiny task, and record the observed provider/model before unattended agents resume.

In simple words: Make a safe copy if the step could change your setup, try the smallest check, then confirm OpenClaw is back to normal before doing more. The source link and commands stay below for people who want the technical detail.

Checklist
Write down the exact symptom first: wrong backend, auth prompt, API-key error, fallback notice, or agent quality/latency that changed after the 2026.6.10 migration.
Check the selected model route and provider prefix; `openai/gpt-5.5` is not the same thing as proving which auth profile or backend the Gateway will actually use.
Inspect the provider definition and credential source for the route you expect: `models.providers.<id>.baseUrl`, `api`, API-key/OAuth auth profile, and any env/SecretRef used by the Gateway process.
Config shape to inspect, not paste blindly
{
  "agents": {
    "defaults": {
      "model": { "primary": "openai/gpt-5.5" }
    }
  },
  "models": {
    "providers": {
      "openai": {
        "api": "openai-responses",
        "baseUrl": "https://api.openai.com/v1",
        "apiKey": "${OPENAI_API_KEY}"
      }
    }
  }
}
Restart or reload through the normal supervisor, then run one small task and capture the observed provider/model from status, logs, or the channel reply instead of trusting config validation alone.
Provider-route receipt
- OpenClaw version:
- Symptom after migration:
- Intended model route:
- Intended provider id/backend:
- Credential source checked (auth profile/env/SecretRef):
- Gateway restarted/reloaded how:
- Tiny task used for proof:
- Observed provider/model after run:
- Fallback notice or override present?
- Rollback model route if proof fails:
If the run is on a fallback model, reset or start a fresh session after fixing auth/routing so a sticky fallback override is not mistaken for the new default.
Keep the old working model route written down until the tiny task passes and the expected provider/model is visible in the receipt.
Success looks like
• The selected model prefix, provider definition, and credential source all point at the backend the operator actually intends to use.
• A tiny real run shows the expected provider/model after restart or reload, not only a passing config file.
• Any fallback state is cleared with a fresh/reset session before recurring agents rely on the new route.

Source: OpenClaw v2026.6.10 release + provider/failover docs · link