3415e274635499e13b93fd9b9e35af9ed1eef44c
The one kind whose dialect its route cannot imply is the openai kind: OpenAI itself serves the Responses API, an arbitrary OpenAI-compatible server only promises chat completions. That choice was implicit; now the user can make it. Config: ProviderInstance gains api (Option<ProviderApi>, chat | responses), serde snake_case, defaulting to absent — every config written before the field reads as unset and keeps its route rule. Registry: build() takes the stored choice as its fifth argument. An explicit chat/responses beats the route rule for the openai kind; unknown spellings fall back to the rule. A wiremock test proves the lift: build(openai, override_url, responses) lands on /responses. Frontends: the TUI's add-instance flow inserts a ChooseApi stage between the base-URL and key prompts for the custom-endpoint row only — arrows choose, enter records and descends, esc returns to the URL prompt; chat completions leads the list so enter-without-looking keeps what the route rule would have picked. The choice rides the pending login into the backend, the saved instance, and back out through from_profile. The ACP resolver honors the stored field via stored_api(); claw's ProviderParams gains the same field (config-file writable; its login forms do not ask yet). Every other kind's dialect stays its endpoint's own decision. New tests: the stage's default and esc contract, the explicit Responses pick, the end-to-end landing in the saved instance, the config serde round-trip both spellings plus old-file absence, and the registry's precedence rule. fmt, clippy -D warnings, and all 135 test groups pass; the WIP in screens/settings.rs, ui/pane.rs, palette.rs, README is untouched.
Languages
Rust
74.9%
Kotlin
13.8%
Vue
7.1%
TypeScript
3%
Dockerfile
0.5%
Other
0.6%