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

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:

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.