Skip to content

[Feature Request] Fallback priority list for AI / LLM models #846

Description

@MineraleYT

Platform

macOS

Problem / Motivation

Description

Currently, when configuring AI processing or LLM post-processing, the user can only select a single specific provider or model, such as local Whisper, Groq, or Mistral AI. If that chosen model fails due to a rate limit, a connection timeout, an API error, or because a local model fails to load, the app simply stops and displays an error message stating that the model is unavailable or hit a rate limit.

Context / Current Behavior

  1. Run a transcription or workflow that triggers an AI model.
  2. If the selected provider is offline or rate-limited, the workflow fails immediately.
  3. The user must manually open the settings and switch to an alternative provider to try again.

Why is it needed?

Relying on a single AI provider introduces a single point of failure. API servers go down, rate limits are easily hit during heavy usage, and local models might occasionally fail to initialize due to RAM or system constraints. A sequential fallback mechanism would dramatically improve the resilience and reliability of automated workflows.

Proposed Solution

Objective

Implement a priority and fallback list for AI models, similar to the microphone priority request. If the primary model fails or returns an error, the system should automatically pass the prompt to the next model in the sequence. If none of the models in the list succeed, the application should gracefully stop without rendering an output.

Expected Behavior Example

A user creates a priority list:

  1. Local Whisper / Local LLM (First choice) -> If it fails to load or times out...
  2. Groq API (Second choice) -> If it hits a rate limit or returns an API error...
  3. Mistral AI (Third choice) -> If this also fails, do not return a broken response; stop gracefully.

Requirements

  • Provide a UI, like an ordered or reorderable list, in the settings to define the sequence of fallback AI providers and models.
  • Detect API errors (such as 429 Rate Limit or 5xx Server Error) or local engine crashes, and trigger the next engine in line instead of aborting the workflow.
  • If the final model in the list fails, exit cleanly without outputting error fragments to the target application.
  • Maintain backward compatibility so users can still lock a workflow to a single specific provider if they prefer.

Alternatives Considered

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions