fix: auto-refresh model list when switching post-processing providers

[that-lucas]

Summary

• Auto-fetch available models when switching post-processing providers, so the model dropdown immediately reflects what's valid for the new provider
• Clear cached model options and reset the stored model when the Custom provider's base URL changes
• Clear cached model options on any provider switch to prevent stale entries from lingering

Problem

When a user switches post-processing providers (or changes the Custom provider's base URL), the previously stored model value persists without validation. If that model doesn't exist on the new provider's API, the post-processing request silently 404s at runtime. The user receives no feedback — their transcription is pasted without post-processing, and there's no indication anything went wrong.

This is particularly likely with the Custom provider, where a user might point the base URL at different APIs over time (e.g., Groq → Cerebras), each with different model naming conventions (openai/gpt-oss-120b vs gpt-oss-120b).

Changes

1. usePostProcessProviderState.ts — handleProviderSelect now awaits the provider switch and auto-fetches models for the new provider, so the dropdown is immediately populated with valid options.
2. settingsStore.ts (setPostProcessProvider) — Clears cached model options when switching providers, preventing stale entries from a previous fetch.
3. settingsStore.ts (updatePostProcessBaseUrl) — Clears cached models and resets the stored model to empty when the base URL changes, since the previous model is almost certainly invalid for the new endpoint.

Note

This doesn't address the broader issue that post-processing failures are completely silent to the user — a toast or overlay notification on API errors would be a valuable follow-up. This PR reduces the likelihood of hitting that silent failure by keeping the model dropdown in sync with the active provider.

Origin story

This was discovered while setting up a debug workflow for transcript optimization prompts. The goal was to have two prompts in Handy: one using the Cerebras provider (structured output, clean text pasted) and a second using a Custom provider pointed at the same Cerebras API (legacy mode, JSON output with both original and improved text for comparison).

With structured-output providers (OpenAI, Cerebras, OpenRouter, etc.), Handy strips ${output} from the prompt, sends the transcript as the user message, and forces a {"transcription": "..."} response schema — so there's no way to get custom JSON output for debugging. The Custom provider uses the legacy path (single user message, no schema), which allows full control over the output format.

After switching the Custom provider's base URL to Cerebras and selecting a debug prompt, post-processing silently failed. The cause: the model dropdown retained openai/gpt-oss-120b (valid for the previous endpoint) instead of gpt-oss-120b (what Cerebras expects), resulting in a 404 with no user-facing error.

[Copilot]

Pull request overview

This PR improves the post-processing provider settings UX by keeping the model dropdown in sync with the active provider (and Custom provider endpoint), reducing cases where an invalid persisted model causes silent runtime failures.

Changes:

• Clear cached model options when switching post-processing providers.
• Auto-fetch available models after provider switch so the dropdown updates immediately.
• When Custom provider base_url changes, clear cached models and reset the stored model value.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/stores/settingsStore.ts	Clears cached model options on provider switch; clears cached models + resets stored model on base URL change.
src/components/settings/PostProcessingSettingsApi/usePostProcessProviderState.ts	Awaits provider switch and triggers a model auto-fetch for the newly selected provider.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (1)

src/stores/settingsStore.ts:399

• commands.setPostProcessProvider returns a Result, but its status isn’t checked here. If the Tauri invoke fails and the binding returns { status: "error" } (without throwing), this code will still call refreshSettings() and won’t rollback to previousId, leaving the UI in an incorrect provider state. Handle the returned Result (throw or branch on status) so failures reliably trigger rollback and so callers can detect failure.

      try {
        await commands.setPostProcessProvider(providerId);
        await refreshSettings();
      } catch (error) {
        console.error("Failed to set post-process provider:", error);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cjpais]

Thanks this is a good change, I'll review the code when I can and pull it in

[that-lucas]

Thanks this is a good change, I'll review the code when I can and pull it in

No, thanks to you, man! Your tool is absolutely great. I use it every day, the whole day, and it makes my day so much easier. Thank you so much!