fix(providers): fall back to predefined model list when /models endpoint fails

[dongjiang1989]

Summary

• Fix provider configuration failure when the /models API endpoint returns non-404 errors (invalid JSON, auth errors, server errors, wrong base URL,
  etc.)
• Both OpenAiProvider and AnthropicProvider now fall back to their predefined static model list on any API error, not just 404
• A tracing::warn log is emitted so the failure is observable
• Adds regression tests for both providers

Fixes #10074

Root Cause

When configuring Zhipu AI (or any provider with dynamic_models: true and a non-standard base URL), the derived /models endpoint URL may be wrong. For
example, entering https://open.bigmodel.cn instead of https://open.bigmodel.cn/api/paas/v4 produces a models URL of
https://open.bigmodel.cn/v1/models, which does not exist.

The endpoint returns HTTP 200 with a non-JSON body (e.g. an HTML page), causing handle_response to fail with ProviderError::RequestFailed("Response body is not valid JSON: ..."). Previously, fetch_supported_models only fell back to the static list on EndpointNotFound (404), so this
RequestFailed error propagated up and blocked the provider configuration entirely.

Changes

crates/goose-providers/src/openai.rs

• OpenAiProvider::fetch_supported_models: replace the catch-all Err(e) => return Err(e) branch with a fallback to custom_models plus a warn log
• Add make_provider_with_custom_models test helper and two #[tokio::test] cases

crates/goose-providers/src/anthropic.rs

• AnthropicProvider::fetch_supported_models: same fallback change (the zai and minimax declarative providers are also affected)
• Add a #[cfg(test)] module with matching test cases

Testing

• cargo test -p goose-providers --lib openai::tests::fetch_supported_models_falls_back_on_non_404_error
• cargo test -p goose-providers --lib openai::tests::fetch_supported_models_returns_static_when_dynamic_false
• cargo test -p goose-providers --lib anthropic::tests::fetch_supported_models_falls_back_on_non_404_error
• cargo test -p goose-providers --lib anthropic::tests::fetch_supported_models_returns_static_when_dynamic_false

Related Issues

Relates to #10074
Discussion: LINK (if any)

Screenshots/Demos (for UX changes)

Before:

After:

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e76835896b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3f47661cc5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[itxaiohanglover]

Solid fix — falling back to the predefined model list on any error (not just 404) prevents a misconfigured /models endpoint from breaking the provider entirely. The test coverage for the fallback path is good.

[DOsinga]

Thanks for digging into this and for the small, well-scoped PR — the intent is good.

The problem is that fetch_supported_models isn't just a "nice to have" model list — it doubles as the configuration-correctness check. In the CLI configure flow (configure_provider), fetch_recommended_models → fetch_supported_models is called, and on error we surface the message and abort configuration. So today, a wrong base URL (exactly the #10074 case, where /models returns HTTP 200 + HTML) produces a visible "check your configuration" error that tells the user something is wrong.

Falling back to the static list on any error makes that signal disappear. It also swallows Authentication, CreditsExhausted, and RateLimitExceeded (the P2 codex raised, which is still unaddressed): a user with a bad API key or exhausted account would sail past config with a fabricated model list and only hit a confusing failure later at chat time. That's why this catch-all approach keeps getting proposed and turned down — it trades a clear config-time error for a murky runtime one.

The real fix for #10074 is on the base-URL side: guide the user to the correct base URL / fix the /models URL derivation for Zhipu. If a fallback is warranted at all, it should be narrowly scoped to "endpoint doesn't exist / response isn't a models payload" while still propagating auth, credit, rate-limit, and connection errors so misconfiguration stays visible.

Going to close this one for now. A couple of pointers for next time: we ask that AI review comments (the codex P2 here) get addressed or explained before a PR moves forward — see https://github.com/aaif-goose/goose/blob/main/CONTRIBUTING.md#ai-code-reviews. Really do appreciate the contribution, and a follow-up that fixes the base-URL handling would be very welcome.