[Bug] opencode.ai/zen/go/v1 returns 400 "Model is unavailable" for deepseek-v4-flash (CLI works; same key, same pool) #41211

[Bug] OpenCode Go /go/v1 returns "Model is unavailable" for deepseek-v4-flash (Hermes + direct HTTP both fail; OpenCode CLI succeeds)

Summary

https://opencode.ai/zen/go/v1/chat/completions returns HTTP 400 with Error from provider (Console Go): Upstream request failed: Model is unavailable. for model: "deepseek-v4-flash" consistently. Same key works for other models on the same endpoint (e.g. glm-5 returns HTTP 200 with a valid chat completion), and the same opencode-go/deepseek-v4-flash model works fine when invoked through the OpenCode CLI (opencode run -m opencode-go/deepseek-v4-flash). The failure only reproduces via the /zen/go/v1 Console Go endpoint.

Environment

• OpenCode CLI: 1.18.14 (bin/opencode.exe)
• Account: OpenCode Go subscription ($5 first month / $10 renewal), Go pool, deepseek-v4-flash documented at 31,650 req / 5h, 79,050 req / week
• Errors are reproducible from any HTTP client, not specific to Hermes

Steps to reproduce

1. Obtain the Go subscription key from the OpenCode account (same key the OpenCode CLI uses; visible in ~/.local/share/opencode/auth.json)
2. Issue a direct HTTPS request:

curl -X POST https://opencode.ai/zen/go/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENCODE_GO_API_KEY" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"ping"}],"max_tokens":15}'

Expected

HTTP 200 with a chat completion (matching documented behavior — the model is listed on the OpenCode Go plan table with 31,650 req / 5h).

Actual

HTTP 400, body:

{"error":{"type":"server_error","message":"Error from provider (Console Go): Upstream request failed: Model is unavailable."}}

Control comparisons (same key, same endpoint, same headers)

All controls run within ~10 seconds of each other with the same credentials, the same base URL, and the same headers. Only model: "deepseek-v4-flash" returns 400 "Model is unavailable"; every other model in the test matrix either works or returns a supported-name error. This points to a Console Go upstream-routing failure for that specific model ID, not an auth/key/account issue (auth would have given 401, not 400).

CLI works, HTTP does not

opencode.exe run -m opencode-go/deepseek-v4-flash "hi" returns a valid response (verified 2026-08-08, ~30s after the HTTP failure). Internal logger output:

message=stream providerID=opencode-go modelID=deepseek-v4-flash llm.runtime=ai-sdk

So the CLI invokes the same providerID/modelID pair and the same Go pool, but reaches DeepSeek V4 Flash through a different code path than the /zen/go/v1 Console Go endpoint — likely a direct path bypassing Console Go. The HTTP Console Go path is the only one failing today.

Impact

• Third-party clients (e.g. Hermes, OpenAI-compatible agents, custom scripts) hitting the documented Go endpoint cannot use the Flash quota, even though the same account is happily calling Flash through the official CLI.
• Error message is uninformative: "Model is unavailable" gives no hint that other models on the same pool + endpoint are reachable.

Request

Please confirm whether deepseek-v4-flash is currently intended to be served by https://opencode.ai/zen/go/v1/chat/completions, or whether the Console Go endpoint is supposed to fail over / redirect to the same path the CLI uses. If the endpoint is in a transient bad state today, an incident note with ETA would help. A more specific error code (e.g. provider_routing_failed_for_model=deepseek-v4-flash) would also make this much easier to triage from outside.

Suggested investigation

• Check whether the /zen/go/v1 Console Go router has a routing entry pointing at a downstream provider that is currently failing for deepseek-v4-flash only
• Confirm the CLI's actual upstream host/endpoint for opencode-go/deepseek-v4-flash (so the HTTP endpoint can be aligned to it or proxied through it)