Bug Description
hermes doctor can falsely report a valid Gemini API key as invalid because the health check uses OpenAI-style Bearer authentication against Google's native Generative Language API.
For Gemini API keys, this is wrong:
Authorization: Bearer <GEMINI_API_KEY>
The native Gemini API accepts API-key authentication via query parameter:
https://generativelanguage.googleapis.com/v1beta/models?key=<GEMINI_API_KEY>
or equivalent Google API-key auth mechanisms.
Expected Behavior
When probing generativelanguage.googleapis.com / Gemini native API, hermes doctor should validate with Gemini-compatible API-key auth, e.g.:
httpx.get(url, params={"key": key}, headers={"User-Agent": ...})
and should not send Authorization: Bearer for Gemini API-key checks.
Actual Behavior
Doctor uses Bearer auth for the Gemini /models probe, causing HTTP 401 even when the key is valid and runtime Gemini calls work.
Reproduction
- Configure a valid
GEMINI_API_KEY.
- Run
hermes doctor.
- Observe Gemini is reported invalid or unhealthy.
- Verify the same key directly:
curl "https://generativelanguage.googleapis.com/v1beta/models?key=$GEMINI_API_KEY"
- Direct Gemini API-key auth succeeds, while Bearer auth fails with 401.
Root Cause
Doctor treats Gemini like a generic Bearer-token provider instead of using Gemini's native API-key authentication convention.
Suggested Fix
In the doctor provider probe, when provider is Gemini or the probe URL host matches generativelanguage.googleapis.com:
- remove the
Authorization: Bearer ... header
- send
params={"key": key} or another Gemini-supported API-key auth style
- keep existing Bearer behavior for non-Gemini providers
Related Existing Reports / PRs
This is a focused current-main report related to:
Environment
- Hermes Agent current main around commit
4fdfdf674
- Provider: Gemini / Google AI Studio
- Command:
hermes doctor
Bug Description
hermes doctorcan falsely report a valid Gemini API key as invalid because the health check uses OpenAI-style Bearer authentication against Google's native Generative Language API.For Gemini API keys, this is wrong:
Authorization: Bearer <GEMINI_API_KEY>The native Gemini API accepts API-key authentication via query parameter:
or equivalent Google API-key auth mechanisms.
Expected Behavior
When probing
generativelanguage.googleapis.com/ Gemini native API,hermes doctorshould validate with Gemini-compatible API-key auth, e.g.:and should not send
Authorization: Bearerfor Gemini API-key checks.Actual Behavior
Doctor uses Bearer auth for the Gemini
/modelsprobe, causing HTTP 401 even when the key is valid and runtime Gemini calls work.Reproduction
GEMINI_API_KEY.hermes doctor.curl "https://generativelanguage.googleapis.com/v1beta/models?key=$GEMINI_API_KEY"Root Cause
Doctor treats Gemini like a generic Bearer-token provider instead of using Gemini's native API-key authentication convention.
Suggested Fix
In the doctor provider probe, when provider is Gemini or the probe URL host matches
generativelanguage.googleapis.com:Authorization: Bearer ...headerparams={"key": key}or another Gemini-supported API-key auth styleRelated Existing Reports / PRs
This is a focused current-main report related to:
Environment
4fdfdf674hermes doctor