Feature Request: Add FunASR Speech-to-Text node

[LauraGPT]

Note

License and capability clarification (2026-07-14): FunASR is a toolkit, not a single checkpoint. The FunASR and SenseVoice repository source code is MIT; model weights follow each model card. SenseVoiceSmall supports Chinese, Cantonese, English, Japanese, and Korean, and its weights use the linked FunASR Model Open Source License Agreement. Fun-ASR-Nano-2512 is Apache-2.0. Language coverage, punctuation, and performance depend on the selected model and runtime configuration.

Feature Request

Flowise is a great low-code AI builder. A Speech-to-Text node powered by FunASR would enable voice/audio processing workflows.

Use cases:

• Voice input → STT → chatflow processing
• Audio file transcription in document processing chains
• Meeting recordings → transcription → Q&A

Why FunASR?

• OpenAI-compatible API: /v1/audio/transcriptions endpoint — easy integration
• SenseVoice: Ultra-fast ASR (234M params), 50+ languages, self-hosted
• Built-in VAD + punctuation + speaker diarization
• No API key needed: Fully local deployment

Server:

funasr-server --device cuda
# OpenAI-compatible /v1/audio/transcriptions

• GitHub: https://github.com/modelscope/FunASR (16K+ stars)

[TanishValesha]

Is this feature request triaged/accepted by the maintainers? I'd be interested in contributing an implementation if it's aligned with the roadmap.

[LauraGPT]

I checked the current main implementation before proposing code. Flowise already has most of the transport we need: packages/components/src/speechToText.ts uses the OpenAI-compatible transcription client for LocalAi STT, and SpeechToText.jsx already exposes a custom base URL. The remaining gap is first-class discovery and a no-key configuration path; today a FunASR user would have to select a provider named LocalAI and create a LocalAI credential even though a local funasr-server does not require one.

I see three possible scopes:

1. Document FunASR under the existing LocalAI provider. Smallest change, but the provider name and mandatory credential make the workflow confusing.
2. Generalize/rename LocalAI STT to OpenAI-compatible STT. Broader reuse, but it changes an existing saved provider surface and needs migration/backward-compatibility care.
3. Recommended: add a small first-class FunASR entry that reuses the existing OpenAI-compatible client. This keeps existing configs untouched and gives FunASR/SenseVoice correct defaults without a new runtime dependency.

A focused first PR could be limited to:

• Add funASRSTT to the existing chatflow STT backend and UI provider lists (not a new model dependency or standalone inference node).
• Default base URL to http://localhost:8000/v1 and model to sensevoice; expose optional language.
• Make the provider credential optional. With no credential, pass an internal placeholder required by the SDK; if a credential is selected, forward its API key for deployments behind an authenticated gateway.
• Accept the normal OpenAI-compatible { "text": "..." } response.
• Keep WebSocket streaming, diarization controls, and provider-specific extensions out of the first PR.
• Add a co-located unit test with mocked storage/client calls that verifies base URL, model, language, uploaded filename, optional auth, and returned text; run the components test/build plus the UI build.

Would maintainers prefer the dedicated provider in option 3, or the generic provider in option 2?

@TanishValesha, since you already offered to contribute: if you want to take the implementation, please do. I can provide a real funasr-server endpoint smoke test and review the request/response contract. If you would rather not take it, I can implement once the preferred scope is confirmed, so we avoid duplicate PRs.