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

[ardeyouxipianyi]

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:

Model	Text request	Image request
mimo-v2.5	200	200, image recognized correctly
mimo-v2.5-pro	200	404, no image-capable endpoint

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.

[Ingwannu]

Confirmed on current dev: the built-in mimo preset still lists mimo-v2.5-pro and mimo-v2.5 without provider-scoped noVisionModels, so the reported Pro request bypasses the sidecar. The requested distinction is narrow and consistent with existing registry policy: classify only mimo-v2.5-pro as text-only while leaving mimo-v2.5 native-vision capable and preserving custom destinations. I am preparing a focused dev fix with registry/parity and sidecar coverage.

[Ingwannu]

Focused fix is now in PR #2031. It classifies only canonical mimo-v2.5-pro for sidecar image handling, keeps mimo-v2.5 native-vision capable, and regression-tests custom-destination isolation. Focused suites, typecheck, privacy scan, and diff check pass; awaiting exact-head CI and another maintainer review.

[lidge-jun]

리뷰 · 우선순위 50 / 80

Xiaomi MiMo 토큰플랜의 mimo-v2.5-pro에 이미지를 보내면 비전 사이드카를 건너뛰고 게이트웨이가 404 No endpoints found that support image input 을 준다. 같은 호스트의 mimo-v2.5는 이미지를 받는다. 라우티드 프로바이더 호환이라 50이다. 기본 native 경로가 아니다.

src/providers/registry.ts 의 mimo 항목은 models에 mimo-v2.5-pro와 mimo-v2.5를 넣고 noVisionModels는 없다. 사이드카는 noVisionModels에 있는 모델만 텍스트 전용으로 보고 이미지를 설명으로 바꾼다. 목록이 비어 있으면 이미지 URL이 그대로 토큰플랜으로 간다.

같은 파일의 opencode-go 항목은 이미 mimo-v2.5-pro를 noVisionModels에 넣는다. Go 경로와 토큰플랜 경로가 어긋난 것이다. mimo-v2.5는 이미지 200이므로 목록에 넣으면 안 된다. 리포터 표와 같다.

사이드카 실행은 src/vision/index.ts 의 shouldResolveOpenAiVisionSidecar 와 isModelTextOnly 다. 레지스트리 한 줄이 그 분류를 연다. 카탈로그가 이미지 입력을 광고하는 것도 noVisionModels 멤버 기준이라는 주석이 registry에 있다. pro만 넣으면 첨부는 프록시까지 오고 설명 후 텍스트만 나간다.

해결방안

mimo 프로바이더에 noVisionModels: [mimo-v2.5-pro] 만 추가한다. mimo-v2.5는 빼 둔다. opencode-go 목록은 이미 맞으니 손대지 않는다. 회귀는 pro 이미지 요청이 사이드카를 타고 텍스트로 전달되어 404가 없는 것, v2.5 이미지 요청은 사이드카 없이 200인 것이다.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

리뷰 · 종결

dev에 이미 머지됨. #2031 (7a2d13a74) 가 mimo-v2.5-pro 이미지를 비전 사이드카로 보냄. 다음 배포 예정.

설명 모델을 아무 프로바이더로 여는 건 #1937. 이 이슈(#1927) 자체는 닫음.

이 댓글은 grok-bot이 작성했습니다