Bug: MiMo 2.5 image attachments return "Param Incorrect"

[khubaib12345]

Bug: MiMo 2.5 image attachments return Param Incorrect

Summary

Freebuff's model selector lists MiMo 2.5 (mimo/mimo-v2.5) as Balanced · Images, indicating that the model is configured as multimodal.

However, attaching a PNG consistently results in:

Error: Param Incorrect

Normal text requests work successfully with the same model and session.

Based on inspection of the open-source client code, the model configuration and client-side image-processing pipeline appear to be functioning correctly. The failure therefore appears to occur after the client sends the multimodal content, likely in the server-side completions/provider layer.

Environment

• Model: mimo/mimo-v2.5
• Freebuff
• Image format tested: PNG
• Normal text requests: ✅
• Image attachment requests: ❌ Param Incorrect

Reproduction

1. Select MiMo 2.5.
2. Verify the model selector displays:

Balanced · Images

3. Start a new conversation.
4. Send:

hello

The model responds normally.

5. Attach a PNG image and send it.
6. The request fails with:

Error
Param Incorrect

The behavior is reproducible across multiple PNG upload attempts.

Client-side findings

The open-source client appears to have the expected multimodal pipeline.

Model configuration

common/src/constants/freebuff-models.ts configures MiMo 2.5 with:

const MIMO_V25_MODEL = {
  id: FREEBUFF_MIMO_V25_MODEL_ID,
  displayName: 'MiMo 2.5',
  tagline: 'Balanced',
  multimodal: true,
  // ...
}

getFreebuffModelImageSupport() also returns true for the MiMo 2.5 model.

This appears to explain why the UI correctly displays · Images.

Image processing

The client-side image pipeline appears to perform:

PNG
 ↓
processImageFile()
 ↓
base64
 ↓
processImagesForMessage()
 ↓
MessageContent[]
 ↓
SDK run({ content })
 ↓
callMainPrompt({ content })

The resulting message content contains image data rather than merely the filename/path.

OpenAI-compatible conversion

The client conversion layer also appears capable of converting image content into an OpenAI-compatible structure equivalent to:

{
  "type": "image_url",
  "image_url": {
    "url": "data:image/png;base64,..."
  }
}

Therefore, there is no obvious evidence that the PNG is failing during local file processing.

Suspected failure area

The likely boundary is:

Freebuff CLI/client
        ↓
multimodal MessageContent
        ↓
server-side completions/provider layer
        ↓
MiMo API

The server-side completions layer appears to be outside the open-source portion available for inspection.

The key question is whether that layer correctly transforms the received multimodal message into the request expected by MiMo.

Possible causes to investigate

These are hypotheses rather than confirmed root causes.

1. Image content is not forwarded correctly

The server may receive the image content but fail to preserve it as a true multimodal content part before constructing the MiMo request.

Please verify that image inputs reach MiMo in an appropriate form, such as:

{
  "type": "image_url",
  "image_url": {
    "url": "data:image/png;base64,..."
  }
}

2. reasoning_content is not preserved

MiMo's reasoning/thinking mode has specific requirements around preserving historical assistant reasoning_content in subsequent requests.

Please verify whether the server reconstructs multi-turn messages and accidentally drops reasoning_content.

If this field is required for a particular request path, dropping it could produce a provider-side parameter error.

3. MiMo-specific parameter mapping

Please verify the parameters generated by the server against the current MiMo API schema, particularly token-related parameters such as:

max_tokens
max_completion_tokens

The exact accepted parameter should be confirmed against the current upstream MiMo API rather than assumed.

Important diagnostic distinction

The observed behavior is:

Normal text request
        ↓
        ✅ works

PNG image attachment
        ↓
        ❌ Param Incorrect

This indicates that the general MiMo model integration is functioning for text, while the failure is isolated to the image/multimodal request path or to additional request-state handling triggered by that path.

Requested investigation

Please investigate the server-side completions/provider integration for mimo/mimo-v2.5 and, if possible, capture the raw upstream request/response.

Specifically:

1. Confirm that getFreebuffModelImageSupport('mimo/mimo-v2.5') is respected by the server-side request path.
2. Confirm that image content is forwarded to MiMo as actual multimodal content rather than being dropped or converted incorrectly.
3. Verify preservation of reasoning_content in multi-turn MiMo requests.
4. Verify MiMo-specific request parameter mapping.
5. Capture the raw upstream MiMo error associated with Param Incorrect.

Expected behavior

Because MiMo 2.5 is exposed in Freebuff as:

Balanced · Images

a PNG attachment should be accepted and passed to the model so that MiMo can process its visual content.

Actual behavior

Text works, but attaching a PNG consistently produces:

Error: Param Incorrect

Additional note

The open-source client-side implementation appears to already contain the necessary multimodal plumbing. As a result, a server-side request-transformation issue is currently the leading hypothesis.

The exact upstream MiMo request and error response would allow the root cause to be identified conclusively.