dsh-voice 0.4.0

Two things that only make sense together: the plugin could not be configured from its own settings card at all, so a new provider would have been unreachable.

Your own recognition providers

Any OpenAI-compatible API can now be declared in the settings and used in both fallback chains next to the built-in four. Two templates, because those APIs disagree on how audio is sent:

Template	Endpoint	Request	Transcript read from
openai-transcriptions	{baseURL}/audio/transcriptions	multipart: file, model, language	text
openai-chat-audio	{baseURL}/chat/completions	JSON with input_audio: base64 and format	choices[0].message.content

OpenRouter has no /audio/transcriptions endpoint at all and needs the chat template:

- id: dsh-voice
  config:
    customProviders:
      - key: openrouter
        template: openai-chat-audio
        baseURL: https://openrouter.ai/api/v1
        model: google/gemini-2.5-flash
        keyEnv: OPENROUTER_API_KEY
    message:
      chain:
        - provider: openrouter
        - provider: local-whisper

The chat template accepts WAV and MP3 only, while the browser records webm/opus, so the audio goes through the same ffmpeg conversion the local whisper provider already used — ffmpeg is required for openai-chat-audio. A custom name cannot shadow a built-in one: a typo would otherwise silently replace a working provider in someone's chain.

Fixed: the settings card was blank and read-only

The host half never called settings.register, so the namespace the card binds to was undeclared: the snapshot came back empty with writable: false and the card rendered grey fields with nothing to save. Configuration is now read on every call, so an edit applies to the next request instead of after a restart.

Install

dsh plugin --profile web add @goodandready/dsh-voice