[Bug]: reasoningEfforts missing from live catalog for newer opencode-go models (same model has them under other providers) #2410

Client or integration

Codex CLI

Area

Catalog / models

Summary

ocx models live --json and the proxy's own /v1/models omit reasoningEfforts entirely for several opencode-go models, while the same model id exposes a full effort list under other providers. The pattern looks like a static metadata table that lags newly added models.

Effort still appears to be forwarded and honoured at request time, so the impact is on discovery and tooling, not on inference. Tooling that reads the catalog to pick a model or validate an effort before dispatch concludes these models support no reasoning efforts at all, and either skips them or omits the flag. Agent harnesses that select a model programmatically are the main casualty.

Reproduction

1. Ensure the proxy is running and the opencode-go provider is configured:

   ocx status
   jq -r '.providers | keys | join(", ")' ~/.opencodex/config.json

2. Query the proxy's model catalog directly and compare the same model across providers:

   P=$(jq -r .port ~/.opencodex/runtime-port.json)
   curl -s localhost:$P/v1/models -H 'authorization: Bearer probe' \
     | jq -r '.data[]? | select(.id|test("luna|glm-5.3|qwen3.8")) | "\(.id)  \(.reasoningEfforts // "no-effort-field")"'

   Observed:

   gpt-5.6-luna              [low, medium(default), high, xhigh, max]
   kiro/gpt-5.6-luna         [low, medium(default), high, xhigh, max]
   zai-plan/glm-5.3          [low, high, max(default)]
   opencode-go/gpt-5.6-luna  no-effort-field
   opencode-go/glm-5.3       no-effort-field
   opencode-go/qwen3.8-max   no-effort-field
   

   glm-5.3 is the clearest case: identical model id, populated under zai-plan, empty under opencode-go.

3. List every opencode-go model to see that populated and empty rows are interleaved, skewing toward recent additions:

   ocx models live --json \
     | jq -r '.[] | select(.provider=="opencode-go") | "\(.id)\t[\(.reasoningEfforts // [] | join(","))]"'

   glm-5, glm-5.1, glm-5.2      [low,medium,high,xhigh,max]
   glm-5.3                      []            <-- newest in family
   qwen3.5-plus … qwen3.7-plus  [low,medium,high,xhigh,max]
   qwen3.8-max                  []            <-- newest in family
   deepseek-v4-flash, -pro      [high,xhigh,max]
   kimi-k3                      [low,high,max]
   kimi-k2.5 / k2.6 / k2.7-code []
   gpt-5.6-luna                 []
   grok-4.5 / 4.6, hy3          []
   minimax-m2.5 / m2.7 / m3     []
   

4. Confirm the effort parameter is still forwarded despite the missing metadata:

   P=$(jq -r .port ~/.opencodex/runtime-port.json)
   for eff in low max; do
     curl -s -X POST localhost:$P/v1/responses \
       -H 'content-type: application/json' -H 'authorization: Bearer probe' \
       -d "{\"model\":\"opencode-go/gpt-5.6-luna\",\"input\":\"Think carefully: how many ways can 8 non-attacking rooks be placed on an 8x8 board? Answer with just the number.\",\"stream\":false,\"reasoning\":{\"effort\":\"$eff\"}}" \
       | jq -r '"'"'effort: reasoning_tokens=\(.usage.output_tokens_details.reasoning_tokens)'"'"'
   done

   low -> reasoning_tokens=31
   max -> reasoning_tokens=42
   

   One sample each, so this is not a claim about how well max is honoured — only that the parameter is not dropped. The metadata gap therefore looks cosmetic rather than functional.

Expected: reasoningEfforts is populated for opencode-go models that accept a reasoning effort, consistently with the same model under zai-plan / kiro / native.

Actual: the field is absent for those rows.

Version

opencodex 2.29.0

Operating system

Ubuntu 24.04.4 LTS (WSL2, kernel 6.18.33.2-microsoft-standard-WSL2)

Provider and model

opencode-go / gpt-5.6-luna, opencode-go / glm-5.3, opencode-go / qwen3.8-max (compared against zai-plan / glm-5.3, kiro / gpt-5.6-luna, native gpt-5.6-luna)

Logs or error output

No error is emitted; the field is silently absent from /v1/models and from ocx models live --json. Sample output is inline in Reproduction above.

Related but distinct: #962 (custom model rows dropping provider reasoning metadata) concerns custom rows, whereas this is live rows for a registry provider. #2406 looks like the same class of gap for image capabilities.