[Provider compatibility] DeepSeek V4.1 Flash and GLM-5.3 Flash modality gaps on OpenCode Go and CommandCode disable combo image input

[thisisjun786]

Client or integration

Codex App

Provider or upstream service

OpenCode Go (opencode-go) and CommandCode Auth (command-code). Scope: DeepSeek V4.1 Flash and GLM-5.3 Flash only.

OpenCodex version

@bitkyc08/opencodex 2.52.0 on Linux. The installed src/providers/registry.ts and src/providers/derive.ts were byte-identical to upstream main at 4d37c35155fe283722566d32892b8753c1230be7 when investigated. The relevant classifications also remain on dev at eb81eaaf8d02210b9b0782d90ff6d6074b7bc892.

Endpoint or capability

Model discovery, inputModalities / input_modalities, combo image capability, and native vision versus vision-sidecar routing.

Current behaviour

On an existing installation, ocx models live --json omitted inputModalities for all four routes:

Provider	Exact upstream model ID
opencode-go	deepseek-v4.1-flash
opencode-go	glm-5.3-flash
command-code	deepseek/deepseek-v4.1-flash
command-code	z-ai/glm-5.3-flash

A failover combo containing precisely these four targets advertised only ["text"]. Its image/multimodal capability was unavailable. The serialized Codex catalog already advertised image input for the individual routes, so the two capability surfaces disagreed.

The upstream defaults do not positively declare image input for these IDs. OpenCode Go additionally places deepseek-v4.1-flash in noVisionModels. CommandCode's image allowlist contains the older DeepSeek vision-preview ID, but neither of the current Flash IDs above.

Expected behaviour

Model rows, exported catalogs, combo capability intersection, and request routing should consistently reflect each exact provider route's supported modalities. Native image-capable routes should receive the original image; routes requiring a sidecar should retain an explicit distinction from native vision.

Please verify these four current routes and update their provider-specific declarations accordingly. This report proves a catalog inconsistency and a catalog-level workaround; it does not claim that image recognition has been verified on these gateways.

Minimal redacted request or reproduction

1. On 2.52.0, configure the two providers with valid credentials and select the four IDs above. The observed installation had an older persisted OpenCode Go noVisionModels list containing deepseek-v4-flash and deepseek-v4-pro, but not deepseek-v4.1-flash. Its modality map had no entry for either current Flash ID.
2. Create a failover combo with those four targets and automatic image input. Run ocx models live --json; inspect the four rows and the combo's inputModalities.
3. Merge the following fragment into the existing providers' modelInputModalities maps, preserving all other entries and credentials. These are partial configuration fragments, not replacement provider objects:

{
  "opencode-go": {
    "modelInputModalities": {
      "deepseek-v4.1-flash": ["text", "image"],
      "glm-5.3-flash": ["text", "image"]
    }
  },
  "command-code": {
    "modelInputModalities": {
      "deepseek/deepseek-v4.1-flash": ["text", "image"],
      "z-ai/glm-5.3-flash": ["text", "image"]
    }
  }
}

4. Apply the updated provider configuration to the running proxy and synchronize the catalog. In this session, ocx config set followed by ocx sync left the server's live list stale; saving the preserved provider objects through POST /api/providers refreshed it.
5. Re-run ocx models live --json and inspect the serialized Codex catalog. All four routes and the combo now advertise ["text", "image"].

Actual response or error

Redacted projection of the observed CLI output; <omitted> denotes a missing property:

Before:
opencode-go  deepseek-v4.1-flash           inputModalities=<omitted>
opencode-go  glm-5.3-flash                 inputModalities=<omitted>
command-code deepseek/deepseek-v4.1-flash  inputModalities=<omitted>
command-code z-ai/glm-5.3-flash            inputModalities=<omitted>
four-target combo                        inputModalities=["text"]

After explicit modality declarations and live provider refresh:
all four routes                          inputModalities=["text","image"]
four-target combo                        inputModalities=["text","image"]

Upstream documentation

The concrete client requirement is documented by OCX's combo intersection code: missing modalities become ["text"], excluding image input from the combo.

Related reports: #4436 reports native image acceptance on the first-party DeepSeek API; #4296 concerns GLM-5.3 Flash modality metadata on Z.AI. Neither establishes image transport or recognition on the OpenCode Go or CommandCode routes covered here. No gateway-specific specification or live image-recognition result was verified in this investigation.

Suggested mapping or implementation notes

• Audit the CommandCode image allowlist for the two current IDs. Its negative comment concerns older deepseek/deepseek-v4-flash and non-Flash GLM IDs, not evidence about these exact new routes.
• Revisit OpenCode Go's DeepSeek classification. If native vision is confirmed, add positive modality declarations and remove the corresponding sidecar classification.
• Keep discovery and runtime policy aligned: catalog enrichment only seeds noVisionModels when the saved array is absent, while request routing unions registry and saved lists. A positive local modality declaration alone therefore does not demonstrate that OpenCode Go DeepSeek bypasses the sidecar.
• Verify both fresh defaults and upgraded configurations, plus a combo containing all four targets. If probing image recognition, use content-dependent answers and inspect the actual served route/sidecar behavior rather than accepting HTTP 200 as proof.

Additional context and attachments

Related: #4436, #4296, #2406. This issue covers gateway-specific catalog declarations and their combo impact. Only the local configuration was changed; no upstream patch or deployment was performed. No image-generation/completion probes were made for these four routes. No credentials, full configuration files, account details, or private request bodies are attached.

Checks

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

[lidge-jun]

리뷰 · 우선순위 68 / 80

설명
이 이슈는 OpenCode Go와 CommandCode Auth에서 DeepSeek V4.1 Flash·GLM-5.3 Flash 네 경로의 이미지(입력 모달리티) 선언이 비어 있거나 부정 목록에 묶여, 페일오버 콤보가 inputModalities=["text"]만 광고하게 되는 카탈로그 불일치다. 보고자는 2.52.0에서 ocx models live --json으로 네 행에 inputModalities가 없고 콤보는 text-only였다가, modelInputModalities에 네 ID를 수동으로 넣고 POST /api/providers로 새로고침하니 콤보까지 text+image가 살아났다고 했다. 업스트림이 이미지 지원을 “긍정 선언”하지 않는 경우와, Zen Go의 noVisionModels에 deepseek-v4.1-flash가 들어 있는 상태가 겹친 결과로 보인다. 이슈 본문도 “인식 검증까지 한 것은 아니다. 카탈로그 일관성 문제”라고 선을 그었다.

지금 dev(HEAD 8e6c99608)를 보면 일부가 이미 움직였다. 1파티 DeepSeek 쪽은 #4500으로 deepseek-flash를 네이티브 멀티모달로 두고 modelInputModalities에 text+image를 심었다. 하지만 이슈가 가리킨 게이트웨이 ID는 그대로다. src/providers/registry.ts의 opencode-go는 여전히 noVisionModels에 deepseek-v4.1-flash(및 deepseek-v4-flash)를 넣고, GLM Flash용 긍정 modelInputModalities 시드는 Go 블록에 없다. command-code의 COMMAND_CODE_IMAGE_MODELS/COMMAND_CODE_MODEL_INPUT_MODALITIES는 deepseek/deepseek-v4-flash-vision-exp 등 예전 vision-preview·Luna·Muse 쪽만 있고, deepseek/deepseek-v4.1-flash와 z-ai/glm-5.3-flash는 없다. Z.AI 직접 레지스트리 행은 glm-5.3-flash를 네이티브 VLM으로 빼 두었지만, CommandCode·Go 경로는 그 결정을 공유하지 않는다. #4497(채팅 이미지 파트 수용)과도 겹치지 않는다. 와이어 파싱이 아니라 discovery/시드 문제다.

우선순위 68은 콤보 이미지 라우팅이 실제로 막히는 사용자 체감이 있고, 수정 범위가 registry 시드·noVisionModels 정리·parity 테스트로 좁기 때문이다. 다만 업스트림이 아직 이미지를 거절하면 시드만 바꾸면 사이드카/네이티브 오판이 난다. 이슈가 요청한 대로 “경로별 정확한 선언 + 네이티브 vs 사이드카 구분”을 유지해야 한다. types/config 분할과 무관하고, 닫지 말고 레지스트리 PR로 이어가면 된다.

라인 문제
src/providers/registry.ts opencode-go noVisionModels - deepseek-v4.1-flash가 들어 있어 이미지가 사이드카로 밀리거나 콤보 교집합에서 빠질 수 있다.
src/providers/registry.ts COMMAND_CODE_IMAGE_MODELS - Flash ID(deepseek/deepseek-v4.1-flash, z-ai/glm-5.3-flash) 미포함. vision-preview만 긍정 선언.
심볼 opencode-go modelInputModalities - GLM-5.3-Flash·DeepSeek V4.1 Flash 긍정 시드 부재. 라이브 discovery가 모달리티를 안 주면 행이 비어 보인다.
심볼 콤보 intersection - 네 text-only/미선언 교집합 → ["text"]. 보고 재현과 일치.
심볼 ocx config set + ocx sync vs POST /api/providers - 라이브 목록 갱신 경로가 어긋난다는 운영 메모. 별도 UX/동기화 이슈로 쪼갤지 판단 필요.

메인테이너의 판단이 필요한 지점

• Go의 deepseek-v4.1-flash를 1파티 #4500과 같이 네이티브 image로 올릴지, 업스트림 프로브 전엔 noVisionModels에 남길지.
• CommandCode allowlist에 Flash 두 ID를 넣을지, live profile이 올 때만 merge할지.
• config set/sync 후 라이브 목록이 남는 문제를 이 이슈에 묶을지 새 이슈로 뺄지.

너의 추천
업스트림 이미지 프로브(작은 PNG) 결과를 이슈에 한 줄 붙인 뒤, 증거가 있는 경로만 modelInputModalities에 text+image를 시드하고 Go noVisionModels에서 해당 ID를 빼는 PR을 열자. 프로브 전이면 help-wanted로 두고 시드만 추측으로 올리지 말 것. 콤보 교집합 회귀 테스트를 같이 넣자.

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

[lidge-jun]

Staying open. Recording why, because a merged PR nearby makes it look closable and it is not.

#4500 treated first-party deepseek-flash as native multimodal. That is a different id from the two this issue names. On dev at 72335fc6ac, opencode-go still lists deepseek-v4.1-flash in noVisionModels, and the Command Code image allowlist still omits both deepseek/deepseek-v4.1-flash and z-ai/glm-5.3-flash.

So the reported models still arrive without an image declaration. The residual is exactly the two gateway-prefixed ids, not the first-party one.