MiMo token-plan mimo-v2.5-pro image requests bypass the vision sidecar and fail with 404 #1927

Client or integration

Codex App

Provider or upstream service

Xiaomi MiMo token-plan (mimo)

OpenCodex version

2.24.1 installed locally. The missing classification is also present in main v2.24.2 and current dev commit 4d9738f43601eec2a063658efa89d33420bea5b7, checked on August 17, 2026.

Endpoint or capability

POST /v1/chat/completions — image input and vision-sidecar routing for mimo-v2.5-pro

Current behaviour

The built-in mimo provider registers both mimo-v2.5-pro and mimo-v2.5, but does not declare either model in noVisionModels.

As a result, mimo/mimo-v2.5-pro is not classified as a vision-sidecar consumer. When a request containing image_url reaches the proxy, the image is forwarded directly to the token-plan gateway instead of being described by the configured vision sidecar.

The upstream then returns:

404 No endpoints found that support image input

Live control tests against the same token-plan gateway on August 17, 2026 produced:

Expected behaviour

Only mimo-v2.5-pro should be classified in the token-plan provider's noVisionModels.

When an image is sent to mimo/mimo-v2.5-pro, OpenCodex should:

1. Allow the attachment to reach the proxy.
2. Send the image to the configured vision sidecar.
3. Replace the image with the resulting text description.
4. Forward the text-only request to mimo-v2.5-pro.

mimo/mimo-v2.5 should remain natively vision-capable and continue receiving image input directly.

Minimal redacted request or reproduction

curl -i http://127.0.0.1:10100/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mimo/mimo-v2.5-pro",
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "text",
            "text": "What is in this image?"
          },
          {
            "type": "image_url",
            "image_url": {
              "url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAusB9Wl2hWQAAAAASUVORK5CYII="
            }
          }
        ]
      }
    ],
    "max_tokens": 64
  }'

Actual response or error

HTTP/1.1 404

{
  "error": {
    "message": "Provider error 404: No endpoints found that support image input",
    "type": "",
    "param": null,
    "code": "404"
  }
}

Upstream documentation

No public per-model input-modality specification was found for the Xiaomi token-plan gateway.

Its /v1/models response for mimo-v2.5-pro contains only:

{
  "id": "mimo-v2.5-pro",
  "object": "model",
  "owned_by": "xiaomi"
}

It does not expose input_modalities, capabilities, or an equivalent field. The compatibility distinction above is therefore based on live endpoint testing.

Suggested mapping or implementation notes

Add the following classification to the built-in mimo registry entry:

{
  id: "mimo",
  // ...
  models: ["mimo-v2.5-pro", "mimo-v2.5"],
  noVisionModels: ["mimo-v2.5-pro"],
}

Suggested regression coverage:

• mimo-v2.5-pro is recognized as text-only and activates the vision sidecar.
• mimo-v2.5 remains natively vision-capable.
• A same-named custom mimo provider pointing to a different destination does not inherit this classification.

This mirrors the existing provider-scoped classification introduced for opencode-go in commit 852ab046, while preserving native image input for mimo-v2.5 and custom-destination isolation.

Additional context and attachments

There is an existing precedent for this exact classification pattern in the provider registry.

On July 7, 2026, commit 852ab04636fb7557759536738a94ccff384d9fda (fix(sidecar): web-search 429 failover + timeouts, vision fail-closed, coverage drift) corrected vision-sidecar coverage drift for opencode-go.

Before that change, the opencode-go registry entry classified only glm-5.2 in noVisionModels. The commit expanded the list to cover all Zen Go models known to be text-only from Jawcode metadata and endpoint verification, including:

glm-5
glm-5.1
glm-5.2
deepseek-v4-flash
deepseek-v4-pro
mimo-v2-pro
mimo-v2.5-pro
minimax-m2.5
minimax-m2.7
qwen3.7-max

The commit description explicitly records that opencode-go noVisionModels should cover all Zen Go text-only models, including mimo-*-pro. Its registry comment identifies these as text-only Zen Go models classified from Jawcode metadata so that the vision sidecar describes images for them.

This establishes an existing OpenCodex policy: when a provider's model-discovery response does not expose usable modality metadata, known text-only models are classified in that provider's static noVisionModels list so image requests use the vision sidecar instead of reaching an incompatible upstream endpoint.

The Xiaomi MiMo token-plan provider was added later, on August 7, 2026, in commit 14fd4e773b4188e1fa4349af25d51a6eda73eda2, through issue #1158 and PR #1211. That change focused on selecting the working openai-chat wire, preserving custom-tool support, clamping unsupported reasoning levels, and protecting existing custom destinations. It did not test or classify image-input compatibility.

Live testing on August 17, 2026 now shows the relevant token-plan distinction:

mimo-v2.5       — image input succeeds
mimo-v2.5-pro   — 404 No endpoints found that support image input

Therefore, adding noVisionModels: ["mimo-v2.5-pro"] to the mimo token-plan registry entry follows the project's existing provider-scoped vision classification design. It does not introduce a new mechanism or copy capability metadata globally between providers.

The opencode-go provider already carries the equivalent classification, but provider metadata is intentionally scoped to each provider entry, so it is not inherited by mimo.

No credentials, tokens, account identifiers, or private request data are included.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on a concrete client requirement and live upstream behaviour.