v0.8.65: Baidu Qianfan custom/first-class provider route fixture

[CaiWeibo]

Goal

Support the Baidu Qianfan coding plan model through the provider-scoped routing architecture.

This issue preserves @CaiWeibo's report that the model is not working with tools and that --provider needs a custom/provider option for configuring URL, API key, and model name.

Architecture Contract

This should fit #1519, #2608, #3084, #3311, and #3384.

Baidu Qianfan can be supported either as:

• a first-class ProviderDescriptor if the endpoint/auth/request protocol/model policy is stable enough; or
• a custom OpenAI-compatible/protocol-compatible provider config if users need to bring their own base URL, key, and model id.

In either path:

• model ids are provider-scoped wire ids;
• tool support must come from resolved-route capability/profile data;
• auth is resolved through provider-scoped auth sources;
• route selection goes through v0.8.65: Resolve every provider/model switch through a ReadyRouteCandidate #3384 before mutating state.

Scope

1. Identify Qianfan endpoint request protocol and auth scheme.
2. Decide first-class descriptor vs custom provider fixture.
3. Add provider-scoped config examples for base URL, API key/auth source, and model id.
4. Validate tool-call support and request serialization using mocked tests.
5. Expose readiness/capability in /provider and selectable model rows in /model.

Acceptance Criteria

• A Qianfan route can be configured with provider, base URL, auth source, and model id.
• Tool support is represented as supported/unsupported/unknown rather than assumed.
• --provider / /provider can select the route without requiring hardcoded global model strings.
• Unknown/custom Qianfan model ids are preserved under provider scope.
• Tests cover auth readiness, request protocol, tool capability, route explanation, and failed-route rollback.

Verification

cargo test -p codewhale-tui custom_provider --locked
cargo test -p codewhale-tui provider_adapter --locked
cargo test -p codewhale-tui route_resolver --locked
cargo test -p codewhale-tui tools --locked

Related

• v0.8.65: Custom provider endpoints, models, and auth within provider-scoped routing #1519 custom endpoints/models/auth.
• v0.8.65 EPIC: Separate provider facts, model facts, offerings, and route resolution #2608 provider/model/offering/catalog architecture.
• v0.8.65: Provider descriptors, wire protocol adapters, and conformance tests #3084 provider descriptors and wire protocol adapters.
• v0.8.65: Resolve every provider/model switch through a ReadyRouteCandidate #3384 atomic route resolution.
• v0.8.65: ModelProfile and resolved-route capability descriptors for tools/prompts #3365 resolved-route capability descriptors.

[github-actions]

Thanks @CaiWeibo for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

Thanks @CaiWeibo. I opened a scoped draft PR for the Qianfan route fixture: #3425

What landed in the branch:

• Adds qianfan as a first-class OpenAI-compatible provider descriptor, with aliases baidu-qianfan, baidu_qianfan, and baidu.
• Wires provider-scoped auth/base/model sources: [providers.qianfan], QIANFAN_API_KEY, QIANFAN_BASE_URL, QIANFAN_MODEL, plus BAIDU_QIANFAN_* aliases.
• Preserves custom Qianfan service/model IDs through config, /provider qianfan <model>, saved /model rows, and request shaping.
• Documents the default OpenAI-compatible endpoint and the model-scoped function/tool capability caveat.

Verification run:

• cargo test -p codewhale-config --locked qianfan
• cargo test -p codewhale-config --locked provider_kind_parses_openrouter_and_novita_aliases
• cargo test -p codewhale-config --locked provider_metadata_defaults_match_runtime_helpers
• cargo test -p codewhale-tui --bin codewhale-tui --locked qianfan
• cargo test -p codewhale-tui --bin codewhale-tui --locked deepseek_api_key_reads_metadata_env_vars_for_newer_providers
• cargo test -p codewhale-tui --bin codewhale-tui --locked has_api_key_uses_active_provider
• cargo test -p codewhale-tui --bin codewhale-tui --locked picker_lists_saved_models_from_other_providers
• cargo test -p codewhale-tui --bin codewhale-tui --locked reasoning_effort_off_is_omitted_for_strict_openai_like_providers
• python3 scripts/check-provider-registry.py
• cargo fmt --all -- --check
• git diff --check

Deferred from this scoped PR: full #3384 ReadyRouteCandidate route resolution, live model catalog probing, and live per-model tool/function capability validation. This keeps the safe provider-scoped route available without pretending every Qianfan model has the same tool behavior.

[Hmbown]

Closing — the Baidu Qianfan route fixture shipped in #3425 (merged 2026-06-23). qianfan is now a first-class OpenAI-compatible provider descriptor with aliases (baidu-qianfan, baidu_qianfan, baidu), provider-scoped auth/base/model ([providers.qianfan], QIANFAN_* / BAIDU_QIANFAN_* env), /provider qianfan <model> + saved /model row support, and a verified test suite (cargo test -p codewhale-config --locked qianfan, plus the tui/provider-registry checks). Thanks @CaiWeibo for the report.

The items explicitly deferred from #3425 — full ReadyRouteCandidate route resolution (#3384), live catalog probing, and per-model tool/function capability validation (#3385) — are tracked separately. Reopen if a Qianfan-specific regression shows up.