mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-24 21:21:14 +00:00
938855082a
* fix(models): don't advise models.providers[] registration for runtime-bound models When an agent's configured model is bound to an agent runtime (e.g. the "codex" runtime, whose catalog comes from the OpenAI ChatGPT-account app-server), and that model id is no longer offered by the runtime, model resolution fails with "Unknown model: <provider>/<model>". The appended hint told users to register the model in models.providers[].models[]. For runtime-owned models that advice is misleading: adding the registration makes resolution "succeed" only for the request to be rejected later by the provider — e.g. OpenAI returns 400 "model is not supported when using Codex with a ChatGPT account" once a model id such as gpt-5.3-codex is deprecated. Detect the agentRuntime binding on the configured agents.defaults.models entry and instead point the user at the runtime's live catalog (openclaw models list --provider <id>) and at switching the configured default to an available model. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(reply): show a clear "model unavailable" reply instead of generic failure When a configured model is retired/renamed by the provider, model resolution fails (run.ts throws a typed FailoverError with reason "model_not_found") and the agent runner falls back to the generic "Something went wrong … use /new" reply. That copy is actively misleading for this failure: retrying or starting a new session can never help, because the model id itself must be changed in config. Users on a deprecated model (e.g. gpt-5.3-codex on a Codex ChatGPT account) just see the generic message on every message and on /new. Classify this failure into a dedicated user-facing reply that explains the model is unavailable and points at the config. Detection is structural — it keys off the typed FailoverError reason, not provider error text — so it stays robust as provider wording changes; free-text rejections without a typed reason remain the responsibility of the failover layer that owns error classification. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>