Minimax TTS token use, but not configured.

[maiden geyser]

I have Microsoft TTS configured, but I still see that Minimax TTS token burn is happening.
I do not have Minimax TTS even configured. So where does this Minimax TTS token Use come from?

[willow vale]

I checked the current docs/source. There are two different things that can look like “MiniMax TTS token use”:

1. TTS fallback: OpenClaw treats MiniMax TTS as configured if it can see a MiniMax key, even if you did not put a messages.tts.providers.minimax block in config. The MiniMax speech provider checks messages.tts.providers.minimax.apiKey or MINIMAX_API_KEY. If Microsoft is your primary provider but fails/timeouts, TTS fallback can try other configured speech providers, including MiniMax.

2. Usage/quota snapshot, not TTS audio: commands like openclaw status --usage / openclaw models status --json call MiniMax’s usage endpoint when MiniMax auth exists, to show quota windows. That can show MiniMax usage even if no MiniMax TTS request happened.

Quick checks:

• What version are you on? openclaw --version
• In the chat/session, run /tts status and look for Provider, Fallback, and Attempted providers.
• Check whether your gateway environment has MINIMAX_API_KEY, MINIMAX_CODE_PLAN_KEY, or MINIMAX_CODING_API_KEY set. If MiniMax is only meant for coding/model usage, that same MINIMAX_API_KEY can also make the MiniMax speech provider available as a fallback.

Docs:
https://docs.openclaw.ai/tools/tts
https://docs.openclaw.ai/reference/api-usage-costs

[maiden geyser]

OpenClaw 2026.5.14-beta.1 (cef4145)
📊 TTS status
State: ❌ disabled
Chat override: default
Provider: microsoft (✅ configured)
Persona: arnold
Text limit: 1500 chars
Auto-summary: on

Yes I have the minimax Coding plan and I am using the API key. How to I disable this fallback? also Minimax is not configured, yet my 2 agents who I regularly use have 2 different voices. Where does this config come from? I do have 2 different voices configured for Microsoft tts.

[willow vale]

Yep, this is the key detail: MiniMax Coding Plan via MINIMAX_API_KEY currently also makes MiniMax TTS look configured, because the MiniMax speech provider checks that env var directly.

To disable that TTS fallback while keeping MiniMax coding-plan usage, move the key off MINIMAX_API_KEY and onto the coding-plan-specific env var:

MINIMAX_CODE_PLAN_KEY=...
# or MINIMAX_CODING_API_KEY=...
# do not set MINIMAX_API_KEY

Then restart the gateway and run /tts status again. The MiniMax coding/provider usage path accepts MINIMAX_CODE_PLAN_KEY / MINIMAX_CODING_API_KEY, but MiniMax TTS only falls back to MINIMAX_API_KEY, so that separates the two.

For the voice difference: that is probably not MiniMax if your status says provider is microsoft. Voice can come from three places:

• your Microsoft TTS provider config, e.g. messages.tts.providers.microsoft.voice
• TTS local prefs at ~/.openclaw/settings/tts.json or whatever OPENCLAW_TTS_PREFS / messages.tts.prefsPath points to
• model/agent emitted TTS directives, because messages.tts.modelOverrides is enabled by default and voice overrides are allowed by default

[willow vale]

If you want agents to stop changing voices, set:

{
  messages: {
    tts: {
      provider: "microsoft",
      modelOverrides: {
        allowVoice: false,
        allowModelId: false,
        allowVoiceSettings: false,
        allowProvider: false
      }
    }
  }
}

[willow vale]

If you actually want two agents to have two fixed Microsoft voices, keep them explicitly in your agent/persona instructions or separate TTS prefs/config, but disable model voice overrides if you don’t want the model improvising.

Docs: https://docs.openclaw.ai/tools/tts

[maiden geyser]

I do want my agents to have distinct voices, so that is correctly setup.. my question was how does minimx know they need to have different voices when that is not configured? the voicenames for Microsoft are not the same as minimax. How can I see if it fails over?

[willow vale]

MiniMax does not know your Microsoft voice names.

What happens in the code is provider-scoped:

• If Microsoft is the selected provider, a generic voice directive/override is parsed by the Microsoft provider and stored as a Microsoft override.
• If Microsoft fails and TTS falls back to MiniMax, that Microsoft voice override is not translated to MiniMax.
• MiniMax then uses its own configured/default MiniMax voice, unless you explicitly configured MiniMax TTS voice settings or used a MiniMax-specific directive.

So if you hear two distinct voices while Microsoft is succeeding, that’s your Microsoft setup working. If it falls back to MiniMax, expect MiniMax’s default voice, not a mapped equivalent of the Microsoft voice name.

To see whether failover happened:

1. Generate or wait for a TTS attempt.

   • Even with auto-TTS disabled, you can test manually with:
     /tts audio this is a test of the current tts provider

2. Immediately run:

[willow vale]

/tts status

If fallback happened, status should include lines like:

Last attempt: ✅
Provider: minimax
Fallback: microsoft -> minimax
Attempts: microsoft -> minimax
Attempt details: ...

If Microsoft succeeded, it should just show Microsoft as the provider and no fallback line.

For deeper proof, watch logs while testing:

[willow vale]

openclaw logs --follow

Verbose logs include messages like “primary provider microsoft failed; trying fallback providers.”

[maiden geyser]

ok I do not see any fallback, and voices are different so that should mean it uses Microsoft. TTS state says disabled... does this mean microsoft is disabled?

[willow vale]

No — State: disabled means automatic TTS for chat replies is off. It does not mean the Microsoft provider is disabled.

Your status line:

Provider: microsoft (✅ configured)

means Microsoft is available and configured. With TTS disabled, OpenClaw should not automatically attach audio to normal replies, but Microsoft can still be used when something explicitly requests TTS, for example:

• /tts audio ...
• a voice/Talk/voice-call path
• an explicit TTS tool/action from an agent or integration

So your read is right: no fallback + distinct Microsoft voices means Microsoft is the one being used. The disabled state just means “don’t auto-speak every eligible reply.”

[maiden geyser]

is there a way to find out what is using my Minimax tts? I am only using the coding plan for OpenClaw... so I need to know if its being used.. if not I need to open an issue to Minimax.

[willow vale]

Yes. You can get pretty strong evidence from OpenClaw’s side.

First, check recent logs for actual MiniMax TTS calls/fallbacks:

openclaw logs --limit 1000 --max-bytes 1000000 --plain | rg -i "TTS:|t2a_v2|minimax"

Then do a controlled test:

openclaw logs --follow --plain | rg -i "TTS:|t2a_v2|minimax"

In another chat, run:

[willow vale]

/tts audio this is a controlled tts audit test
/tts status

What to look for:

• If OpenClaw used MiniMax TTS, /tts status should show Provider: minimax or Fallback: microsoft -> minimax.
• In verbose-ish logs, fallback paths show lines like primary provider microsoft failed; trying fallback providers.
• The actual MiniMax TTS endpoint is /v1/t2a_v2. Seeing that is the smoking gun.

Best isolation test: separate the coding-plan key from the generic MiniMax key.

MINIMAX_CODE_PLAN_KEY=your_key
# unset/remove MINIMAX_API_KEY

[willow vale]

Restart the gateway after that. OpenClaw’s coding-plan usage path can use MINIMAX_CODE_PLAN_KEY, but the MiniMax TTS provider only becomes configured from messages.tts.providers.minimax.apiKey or MINIMAX_API_KEY. So after this change, OpenClaw should not be able to call MiniMax TTS accidentally.

If MiniMax still reports TTS usage after MINIMAX_API_KEY is removed and logs show no t2a_v2 / no Provider: minimax, then I’d suspect MiniMax dashboard/accounting attribution and open an issue with them. Include timestamps from your OpenClaw logs and the fact that only coding-plan env vars were present.

[maiden geyser]

now it did failover. 📊 TTS status
State: ❌ disabled
Chat override: default
Provider: microsoft (✅ configured)
Persona: arnold
Text limit: 1500 chars
Auto-summary: on

Last attempt (339s ago): ✅
Text: 35 chars
Provider: minimax
Persona: arnold
Fallback: microsoft -> minimax
Attempts: microsoft -> minimax
Attempt details: microsoft:failed(provider_error) persona=arnold:applied 30242ms, minimax:success(ok) persona=arnold:missing 1819ms
Latency: 1819ms

does the tts status only show last tts run? So if I would do it again and MS tts would work, would it still show there was a fallback?

[willow vale]

Yes — /tts status shows the most recent TTS attempt only.

So if you run TTS again and Microsoft succeeds, the “Last attempt” block should be overwritten with something like:

Provider: microsoft
Attempts: microsoft

and it should no longer show Fallback: microsoft -> minimax.

For history, use logs instead:

openclaw logs --limit 2000 --max-bytes 2000000 --plain | rg -i "TTS:|microsoft|minimax|fallback|t2a_v2"

[willow vale]

That status output is useful, though: Microsoft failed after ~30s, then MiniMax succeeded. The persona=arnold:missing bit also confirms MiniMax did not have an Arnold voice/persona mapping, so it used MiniMax without that matching voice config.

[maiden geyser]

I do not see this failover in the logs:
najef@OpenClaw-Server:~$ openclaw logs --limit 1000 --max-bytes 1000000 --plain | rg -i "TTS:|t2a_v2|minimax"
Log tail truncated (increase --max-bytes).
najef@OpenClaw-Server:~$ openclaw logs --follow --plain | rg -i "TTS:|t2a_v2|minimax"
Log tail truncated (increase --max-bytes).

[willow vale]

That output means the log window you fetched was still too small, and the useful TTS lines may also only appear when verbose/debug logging is enabled.

Two practical ways to inspect it:

openclaw logs --limit 5000 --max-bytes 10000000 --plain | rg -i "tts|fallback|minimax|microsoft|t2a"

If that still only says truncated, go bigger:

openclaw logs --limit 20000 --max-bytes 50000000 --plain | rg -i "tts|fallback|minimax|microsoft|t2a"

For future attempts, turn verbose on before testing:

[willow vale]

/verbose on
/tts audio this is a failover audit test
/tts status

Then tail:

openclaw logs --follow --plain | rg -i "tts|fallback|minimax|microsoft|t2a"

One nuance: /tts status is currently the best evidence for the last attempt because it stores structured attempt details in memory. Regular logs may not contain the same detailed “Attempt details” line unless verbose/debug logging was active at the time. Your status output already proves OpenClaw attempted Microsoft, got a provider error after ~30s, then used MiniMax successfully.