Bug Description
hermes doctor probes GET https://opencode.ai/zen/go/v1/models for OpenCode Go and reports HTTP 404.
That probe does not match the official OpenCode Go documentation.
Official sources:
The official Go docs list these models:
glm-5.1
glm-5
kimi-k2.5
mimo-v2-pro
mimo-v2-omni
minimax-m2.7
minimax-m2.5
And map them to these API surfaces:
https://opencode.ai/zen/go/v1/chat/completions
https://opencode.ai/zen/go/v1/messages
I could not verify an official Go provider listing endpoint at GET /zen/go/v1/models.
With the same valid OPENCODE_GO_API_KEY:
GET https://opencode.ai/zen/go/v1/models -> 404
POST https://opencode.ai/zen/go/v1/chat/completions -> 200
POST https://opencode.ai/zen/go/v1/messages -> 200
So hermes doctor is producing a false negative by probing an endpoint that is not documented for OpenCode Go and fails in live HTTP tests.
Steps to Reproduce
- Configure a valid
OPENCODE_GO_API_KEY.
- Run
hermes doctor.
- Observe
OpenCode Go (HTTP 404).
- Compare the hardcoded probe with the documented endpoints:
curl -i \
-H "Authorization: Bearer $OPENCODE_GO_API_KEY" \
https://opencode.ai/zen/go/v1/models
curl -s \
-H "Authorization: Bearer $OPENCODE_GO_API_KEY" \
-H "Content-Type: application/json" \
https://opencode.ai/zen/go/v1/chat/completions \
-d '{"model":"mimo-v2-pro","messages":[{"role":"user","content":"Reply with OK"}],"temperature":0}'
curl -s \
-H "x-api-key: $OPENCODE_GO_API_KEY" \
-H "Content-Type: application/json" \
https://opencode.ai/zen/go/v1/messages \
-d '{"model":"minimax-m2.7","max_tokens":16,"messages":[{"role":"user","content":"Reply with OK"}]}'
Expected Behavior
hermes doctor should not mark OpenCode Go unhealthy when the documented Go endpoints succeed with the same key.
Actual Behavior
hermes doctor reports:
Checking OpenCode Go API...
⚠ OpenCode Go (HTTP 404)
Root Cause Analysis (optional)
On remote main, Hermes hardcodes the OpenCode Go doctor probe to GET /models:
But the official OpenCode Go docs and route tree expose chat/completions and messages, not a verified GET /models listing surface.
Proposed Fix (optional)
Smallest fix:
- stop treating OpenCode Go as a provider with a required
GET /models health probe in hermes_cli/doctor.py
Alternatives:
- report
key configured only, or
- probe one documented Go endpoint instead of
GET /zen/go/v1/models
Are you willing to submit a PR for this?
Bug Description
hermes doctorprobesGET https://opencode.ai/zen/go/v1/modelsfor OpenCode Go and reportsHTTP 404.That probe does not match the official OpenCode Go documentation.
Official sources:
The official Go docs list these models:
glm-5.1glm-5kimi-k2.5mimo-v2-promimo-v2-omniminimax-m2.7minimax-m2.5And map them to these API surfaces:
https://opencode.ai/zen/go/v1/chat/completionshttps://opencode.ai/zen/go/v1/messagesI could not verify an official Go provider listing endpoint at
GET /zen/go/v1/models.With the same valid
OPENCODE_GO_API_KEY:GET https://opencode.ai/zen/go/v1/models->404POST https://opencode.ai/zen/go/v1/chat/completions->200POST https://opencode.ai/zen/go/v1/messages->200So
hermes doctoris producing a false negative by probing an endpoint that is not documented for OpenCode Go and fails in live HTTP tests.Steps to Reproduce
OPENCODE_GO_API_KEY.hermes doctor.OpenCode Go (HTTP 404).curl -i \ -H "Authorization: Bearer $OPENCODE_GO_API_KEY" \ https://opencode.ai/zen/go/v1/modelsExpected Behavior
hermes doctorshould not mark OpenCode Go unhealthy when the documented Go endpoints succeed with the same key.Actual Behavior
hermes doctorreports:Root Cause Analysis (optional)
On remote
main, Hermes hardcodes the OpenCode Go doctor probe toGET /models:But the official OpenCode Go docs and route tree expose
chat/completionsandmessages, not a verifiedGET /modelslisting surface.Proposed Fix (optional)
Smallest fix:
GET /modelshealth probe inhermes_cli/doctor.pyAlternatives:
key configuredonly, orGET /zen/go/v1/modelsAre you willing to submit a PR for this?