BerriAI/litellm · error · MinimaxException

Error processing MiniMax response: {e}

Error message

Error processing MiniMax response: {e}

What it means

A catch-all raised by the MiniMax TTS response transformer when any unexpected exception (other than a MinimaxException or JSONDecodeError) escapes while building HttpxBinaryResponseContent from the upstream response. It wraps the original exception in a MinimaxException (HTTP 500) with the upstream headers, preserving the error text in the message.

Source

Thrown at litellm/llms/minimax/text_to_speech/transformation.py:387

            binary_response: Final = httpx.Response(
                status_code=200,
                headers=clean_headers,
                content=audio_bytes,
                request=raw_response.request,
            )

            return HttpxBinaryResponseContent(binary_response)

        except json.JSONDecodeError as e:
            raise MinimaxException(
                status_code=500,
                message=f"Failed to parse MiniMax response: {e}",
                headers=dict(raw_response.headers),
            )
        except Exception as e:
            if isinstance(e, MinimaxException):
                raise
            raise MinimaxException(
                status_code=500,
                message=f"Error processing MiniMax response: {e}",
                headers=dict(raw_response.headers),
            )

    def get_complete_url(
        self,
        model: str,
        api_base: str | None,
        litellm_params: dict,
    ) -> str:
        """
        Construct the MiniMax endpoint URL.
        """
        base_url = api_base or get_secret_str("MINIMAX_API_BASE") or self.TTS_BASE_URL
        base_url = base_url.rstrip("/")

        # MiniMax uses a simple endpoint path

View on GitHub (pinned to 6c2dcb801b)

Solutions

1. Inspect the wrapped message — it embeds the original exception text which names the real cause.
2. Verify the TTS request params (voice, model, non-empty input text) so upstream actually returns audio bytes.
3. Update litellm (and httpx) to the latest patch release in case response-construction code changed.
4. If behind a corporate proxy, bypass it for the MiniMax domain to rule out body mangling.
5. Reproduce with litellm.set_verbose=True to capture the full upstream response before the failure.

Example fix

# before
audio = litellm.text_to_speech(model="minimax/tts-01", input=text)

# after — validate inputs that commonly yield empty/bad audio
if not text.strip():
    raise ValueError("input text must be non-empty for MiniMax TTS")
audio = litellm.text_to_speech(model="minimax/tts-01", input=text, voice=voice_id)

if not isinstance(text, str) or not text.strip():
    raise ValueError("TTS input must be non-empty text")

from litellm.exceptions import APIError
try:
    audio = litellm.text_to_speech(model="minimax/tts-02-hd-preview", input=text)
except APIError as e:
    log.exception("MiniMax TTS response processing failed: %s", e)  # message embeds root cause
    raise

When it happens

Trigger: MiniMax TTS call succeeds at HTTP level but processing fails: audio bytes are empty/corrupt so constructing the httpx.Response or HttpxBinaryResponseContent fails, header cleaning raises, or an environment/dependency issue (e.g. httpx version incompatibility) surfaces during response assembly.

Common situations: Empty audio returned by upstream (bad voice/model combination, zero-length input text), a misbehaving intermediary that strips the audio body, or litellm/httpx version drift changing Response construction semantics.

Related errors

• Failed to parse MiniMax response: {e}
• No audio part found in the response
• Error compiling prompt '{prompt_id}': {e}
• Error compiling prompt '{prompt_id}': {e}, prompt_spec: {pro
• Failed to load prompt '{encode_prompt_id(prompt_id)}' from G

AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15). Data as JSON: /api/errors/f55569e395ef3f93. Report an issue: GitHub.