Speech / TTS OpenAI Compatible Can't Be Tested or Saved

[KotoriDruid]

Describe the bug

I have tried restarting AIRI, restarting the PC, disabling cache. On 0.12.0-beta.5

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (12) x64 AMD Ryzen 5 7600 6-Core Processor
    Memory: 5.34 GB / 15.16 GB
  Binaries:
    Node: 24.20.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.19.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (151.0.4129.101)
    Firefox: 154.0.1 - C:\Program Files\Mozilla Firefox\firefox.exe

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.

Contributions

• I am willing to submit a PR to fix this issue
• I am willing to submit a PR with failing tests (actually just go ahead and do it, thanks!)

[leaft]

Please provide a detailed description of the problem depicted in the image.

[0xSelenicDove]

Are u trying to run a local TTS model that its backend server is OpenAI Compatible?

[KotoriDruid]

Are u trying to run a local TTS model that its backend server is OpenAI Compatible?

Yes, I'm running audio.cpp server which is openai compatible. I put the link in the base url as I had done in previous versions and put a few random letters in the api key but couldn't test or save the configuration.

[0xSelenicDove]

Does your setup work in previous versions? If yes I'll investigate

[KotoriDruid]

Does your setup work in previous versions? If yes I'll investigate

yes it does, I had no problem in 11.3 and 10.2 before. I just uninstalled and reinstalled again to make sure. I'm using audio.cpp for hearing (speech to text) too and don't have any problems there. I also noticed the error Please enter an API key to test the voice. is there right from the start when I enter OpenAI Compatible tab when before if I recall correctly it would only come up if the API key was completely empty and would disappear if I input anything in there and the test voice button would light up.

[svershok]

have same issue. I have a workaround. I change settings in devtools>Application>storage>localstorage>file>settings/providers/configured

[leaft]

Investigation update

I (in fact codex) reproduced this issue on the current main branch at 097202cd3.

The defect is in the provider configuration state. A reachable TTS server is not required for the reproduction.

Reproduction

1. Clear settings/providers/configured from local storage.
2. Open the OpenAI Compatible Speech page.
3. Enter a non-empty API key.
4. Observe that the Test Voice button remains disabled.
5. Observe that the API key is absent from settings/providers/configured.

The local browser reproduction contains three cases:

• A fresh page does not enable Test Voice after API key input.
• A fresh page does not save the API key.
• A page with a stored full provider record works correctly.

The first two cases fail. The stored-provider case passes. This result also explains the local-storage workaround reported in this issue.

Root cause

packages/stage-ui/src/stores/providers/config.ts keeps full provider records in providers.

Each record contains identity, configuration, status, and ownership data:

providers[id] = {
  id,
  definitionId,
  config,
  status,
  configuredBy,
}

The same store exposes configs as a computed projection:

const configs = computed(() => Object.fromEntries(
  Object.entries(providers.value)
    .map(([providerId, provider]) => [providerId, provider.config]),
))

Several pages treat this computed projection as writable state.

If a full provider record exists, configs[id] points to the same nested reactive configuration object. A nested write then reaches the source object:

configs[id].apiKey = value

If the provider record does not exist, the page creates an entry in the computed result:

configs[id] = {}

This assignment does not create a full provider record in providers. It only changes the current computed result.

The immediate watcher in this file triggers that path:

packages/stage-pages/src/pages/settings/providers/speech/openai-compatible-audio-speech.vue

The watcher writes the default model and voice before the provider initialization runs.

initializeProvider() then checks providerCredentials[id]. This value comes from the same configs projection.

The temporary derived entry makes the check succeed. As a result, initializeProvider() skips ensureProvider().

The API key then goes into an object without a full provider record. The store does not save that object to local storage.

Related files

The confirmed failure involves these files:

• packages/stage-pages/src/pages/settings/providers/speech/openai-compatible-audio-speech.vue
• packages/stage-ui/src/components/scenarios/providers/speech-provider-settings.vue
• packages/stage-ui/src/composables/use-provider-validation.ts
• packages/stage-ui/src/stores/providers/provider.ts
• packages/stage-ui/src/stores/providers/config.ts

packages/stage-pages/src/pages/settings/providers/speech/comet-api-speech.vue contains the same immediate-watcher pattern. It has the same source-level risk.

Many Chat, Vision, Speech, and Transcription pages also write directly to configs. These pages currently work for one of two reasons:

• A stored full provider record already exists.
• Provider initialization completes before the first user input.

This behavior depends on component mount order and shared object references.

Whole-configuration assignments have an additional problem:

configs[id] = newConfig

These assignments replace a property on the computed projection. They do not replace providers[id].config.

Examples exist in:

• speech-provider-settings.vue
• use-provider-validation.ts
• transcription/aliyun-nls-transcription.vue
• transcription/browser-web-speech-api.vue

Proposed state boundary

The full providers map must remain the source of truth.

The configs projection must be read-only. Pages and shared components must not write to it directly.

Provider initialization must check the full provider record:

providerConfigStore.getProvider(providerId)

It must not use the projected configuration as the existence check.

Configuration changes must use store actions. The action must first create the full provider record when it is absent.

The regression coverage needs two levels:

• Store tests for provider creation and configuration updates.
• Browser component tests for fresh-page input and persistence.

The browser regression must include both a missing provider and a stored provider. This coverage prevents mount order from hiding the failure.