OpenCode Go: 10 of 35 cataloged models return persistent errors on /v1 endpoint (500s, oa-compat format, upstream not serving)

OpenCode Go — Unusable Models Report (10 of 35 listed models return persistent errors)

Date: 2026-09-05
Plan: OpenCode Go ($10/month, full)
Endpoint tested: https://opencode.ai/zen/go/v1 (OpenAI-compatible oa-compat format)
Key: Single OPENCODE_GO_API_KEY — same key successfully completes on 24/35 models, so this is not an auth or billing issue.
Method: Each model called with POST /v1/chat/completions, prompt "Reply with exactly the single word: pong", max_tokens=64. Every model below failed identically on 3 consecutive attempts (persistent, not transient).

---

Summary

Your /models catalog advertises models that are not actually reachable on the Go plan. 10 of 35 fail with persistent errors, falling into three root-cause buckets. One additional model (kimi-k2.7-code) was failing during initial testing but recovered on retry.

Working (24): minimax-m3, minimax-m2.5, deepseek-v4-pro, deepseek-v4-flash, deepseek-v4-flash-vision-exp, glm-5, glm-5.1, glm-5.2, glm-5.3, glm-5.3-flash, qwen3.5-plus, qwen3.6-plus, qwen3.7-plus, qwen3.7-max, qwen3.8-max, qwen3.8-flash, kimi-k3, kimi-k2.6, mimo-v2.5, mimo-v2.5-pro, longcat-2.0, hy3, hy4-preview, omen-alpha

---

Bucket 1 — OpenCode Go gateway 500 "Internal server error" (4 models)

These never reach an upstream model; OpenCode's own router crashes.

Model	Error (HTTP 500)
minimax-m2.7	{"type":"error","error":{"type":"error","message":"Internal server error"}}
gpt-5.6-luna	{"type":"error","error":{"type":"error","message":"Internal server error"}}
muse-spark-1.3-contributor	{"type":"error","error":{"type":"error","message":"Internal server error"}}
muse-spark-1.2-contributor	{"type":"error","error":{"type":"error","message":"Internal server error"}}

Notes / known context:

• Matches the widely-reported OpenCode Go service instability (see GitHub issue anomalyco/opencode#36889 "OpenCode Go service (zen/go/v1) frequent intermittent outages — HTTP 000 / 503 / Cloudflare 524", plus multiple r/opencode threads).
• For the muse-spark models specifically there is a documented adapter-routing bug in the OpenCode/OCX stack: the model is routed through the openai-chat adapter, which yields a 500, whereas it only works through the openai-responses adapter. Community workaround for the local CLI is modelAdapters: { "muse-spark-...": "openai-responses" }. The HTTP /v1 endpoint has no such escape hatch, so these are unusable.
• gpt-5.6-luna and minimax-m2.7 appear to be listed but not wired on the Go router.

Ask: Please investigate why these four models 500 at the gateway, fix the muse-spark adapter routing, and either wire gpt-5.6-luna / minimax-m2.7 or remove them from the catalog.

---

Bucket 2 — Format incompatibility on oa-compat endpoint (1 model)

Model	Error (HTTP 401)
grok-4.6	{"type":"error","error":{"type":"ModelError","message":"Model grok-4.6 is not supported for format oa-compat"}}

Ask: Either serve grok-4.6 through an adapter that supports it on the /v1 endpoint, or clearly mark it as "not available via API / OpenAI-compatible format only" in the catalog so subscribers know it can't be reached through this endpoint.

---

Bucket 3 — Upstream providers not serving the model (5 models)

These reach an upstream but the upstream rejects / doesn't serve the model.

Model	Error
mimo-v2-pro	HTTP 400 Error from provider (Console Go): Upstream request failed: [400] Unsupported model mimo-v2-pro
mimo-v2-omni	HTTP 400 ... [400] Unsupported model mimo-v2-omni
hy3-preview	HTTP 400 ... Upstream request failed: Model is unavailable.
grok-4.5	HTTP 503 ... Upstream request failed: Endpoint is unavailable.
kimi-k2.5	HTTP 400 ... [404] No allowed providers are available for the selected model. Providers serving moonshotai/kimi-k2.5-0127: siliconflow, deepinfra, atlas-cloud, digitalocean, venice, novita, amazon-bedrock, phala, but your request's provider.only preference permits only: moonshotai.

Notes:

• mimo-v2-pro / mimo-v2-omni: the newer mimo-v2.5 / mimo-v2.5-pro both work; these older v2 variants are not routed. Please either enable them or remove from catalog.
• hy3-preview: hy3 and hy4-preview both work; only hy3-preview is dead.
• grok-4.5: xAI endpoint capacity/outage (consistent with OpenCode changelog entries about retrying xAI capacity errors).
• kimi-k2.5: clearly a routing/config bug on OpenCode's side. The upstream model moonshotai/kimi-k2.5-0127 is served by 8 providers (siliconflow, deepinfra, atlas-cloud, digitalocean, venice, novita, amazon-bedrock, phala) but not by moonshotai itself, yet the request pins provider.only: moonshotai. Please fix the provider whitelist.

---

Repro

KEY="$(grep '^OPENCODE_GO_API_KEY=' ~/.hermes/.env | cut -d= -f2-)"
for m in minimax-m2.7 gpt-5.6-luna muse-spark-1.3-contributor muse-spark-1.2-contributor \
         mimo-v2-pro mimo-v2-omni kimi-k2.5 hy3-preview grok-4.5 grok-4.6; do
  curl -sS -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
    -d '{"model":"'$m'","messages":[{"role":"user","content":"Reply with exactly: pong"}],"max_tokens":64}' \
    https://opencode.ai/zen/go/v1/chat/completions | head -c 300
  echo "  <= $m"
done

---

Requested actions (prioritized)

1. Fix the kimi-k2.5 provider whitelist (provider.only: moonshotai → allow the 8 providers that actually serve it). Smallest, clearly-correct fix.
2. Fix muse-spark adapter routing (openai-chat → openai-responses) to stop the 500s.
3. Investigate gateway 500s for gpt-5.6-luna / minimax-m2.7; wire them or de-list.
4. Serve grok-4.6 via a compatible adapter on /v1, or mark it format-limited in the catalog.
5. Enable or de-list mimo-v2-pro, mimo-v2-omni, hy3-preview; restore grok-4.5 endpoint.
6. Publish the long-requested status.opencode.ai so subscribers can distinguish "service down" from "model not available" instead of guessing.

Start by running the provided curl reproduction against /v1/chat/completions and compare the failing models with the /models catalog. Trace the catalog entries, provider restrictions, and adapter routing for kimi-k2.5 and the muse-spark models first. Done means the prioritized failures either serve successfully through the endpoint or are accurately removed or marked unavailable, with regression coverage for the routing decisions.