fix(providers): honor key_env/api_key_env on Azure Anthropic + accept alias in normalizer by teknium1 · Pull Request #16935 · NousResearch/hermes-agent

teknium1 · 2026-04-28T09:11:49Z

Summary

Three related fixes around custom env-var-name hints for provider entries — surfaced while auditing what OpenClaw's Hermes migrator reads vs what Hermes actually honors.

Problems

1. Azure Anthropic path silently ignored key_env / api_key_env hints.
If a user followed website/docs/guides/azure-foundry.md:105 literally:

model:
  provider: anthropic
  base_url: https://my-resource.services.ai.azure.com/anthropic
  api_key_env: MY_CUSTOM_KEY

Hermes raised "No Azure Anthropic API key found. Set AZURE_ANTHROPIC_KEY or ANTHROPIC_API_KEY." even when MY_CUSTOM_KEY was set in the environment. The resolver at hermes_cli/runtime_provider.py:1126 hardcoded the two env var names and never read model_cfg.

2. _normalize_custom_provider_entry didn't recognize api_key_env.
The normalizer accepted key_env and the camelCase keyEnv, but not api_key_env or apiKeyEnv. Any user who wrote api_key_env: in a custom_providers[i] or providers.<name> entry got a "unknown config keys ignored: api_key_env" warning and the hint was dropped.

3. _VALID_CUSTOM_PROVIDER_FIELDS didn't list key_env.
The canonical "supported fields" set in hermes_cli/config.py:2493 was missing key_env, even though the runtime reads it at auxiliary_client.py:1889, runtime_provider.py:491, main.py:1707/2955/3293. Documentation-as-code that drifted from reality.

Fixes

hermes_cli/runtime_provider.py: Azure Anthropic resolution now checks, in order:
1. os.getenv(model_cfg["key_env"])
2. os.getenv(model_cfg["api_key_env"]) (docs alias)
3. model_cfg["api_key"] (inline value, useful for multi-profile setups)
4. AZURE_ANTHROPIC_KEY (historical default)
5. ANTHROPIC_API_KEY (historical default)
Error message updated to mention key_env/api_key_env as an option.
hermes_cli/config.py::_normalize_custom_provider_entry: accept api_key_env as a snake_case alias for key_env, and apiKeyEnv as a camelCase alias. Both added to _KNOWN_KEYS so the "unknown config keys ignored" warning doesn't fire on valid configs.
hermes_cli/config.py::_VALID_CUSTOM_PROVIDER_FIELDS: add "key_env".
website/docs/guides/azure-foundry.md: flip the shown field to the canonical key_env and add a sentence noting the accepted aliases.

Validation

Test suite	Before	After
`tests/hermes_cli/test_runtime_provider_resolution.py`	149 passing	161 passing (+12 new in `TestAzureAnthropicEnvVarHint` and `TestProviderEntryApiKeyEnvAlias`)
`tests/hermes_cli/test_azure_detect.py`	4 passing	4 passing
`tests/hermes_cli/test_config.py`	Unchanged	Unchanged
`tests/hermes_cli/test_provider_config_validation.py` + `test_user_providers_model_switch.py` + `test_custom_provider_model_switch.py`	46 passing	46 passing

The new tests cover every path in the Azure Anthropic resolution chain (key_env hit, api_key_env alias hit, key_env-beats-fallback precedence, inline api_key, historical env var fallback, unset-var-falls-through, helpful error message, non-Azure path doesn't consult key_env) and lock the normalizer alias behavior.

Compatibility

Pre-existing configs using AZURE_ANTHROPIC_KEY / ANTHROPIC_API_KEY continue to work unchanged (fallback chain).
Configs using key_env continue to work (already honored via normalizer, now also honored in Azure path).
Configs using api_key_env (previously silently broken) now work.

… alias in normalizer Three related fixes around custom env-var-name hints for provider entries. 1. Azure Anthropic path: previously hardcoded to look up AZURE_ANTHROPIC_KEY then ANTHROPIC_API_KEY with no way to override. If a user wrote model: provider: anthropic base_url: https://my-resource.services.ai.azure.com/anthropic key_env: MY_CUSTOM_KEY the key_env hint was silently ignored and the resolver raised 'No Azure Anthropic API key found' even when MY_CUSTOM_KEY was set in the environment. The runtime now checks, in order: (1) os.getenv(model_cfg.key_env) (2) os.getenv(model_cfg.api_key_env) # docs alias (3) model_cfg.api_key # inline value (4) AZURE_ANTHROPIC_KEY # historical default (5) ANTHROPIC_API_KEY # historical default Error message updated to mention key_env as an option. 2. Provider entry normalizer (_normalize_custom_provider_entry): accept 'api_key_env' as a snake_case alias for 'key_env', and 'apiKeyEnv' as a camelCase alias. Adds both to the _KNOWN_KEYS set so the 'unknown config keys ignored' warning doesn't fire on valid configs. 3. _VALID_CUSTOM_PROVIDER_FIELDS: add 'key_env'. That set documents supported custom_providers entry fields; it was drifting from reality since key_env has been read at runtime in auxiliary_client.py, runtime_provider.py, and main.py for a while. Docs: website/docs/guides/azure-foundry.md now uses the canonical key_env field and notes that api_key_env / keyEnv / apiKeyEnv are accepted as aliases. Validation: 12 new tests in test_runtime_provider_resolution.py covering all 5 Azure Anthropic resolution paths + 4 normalizer-alias tests. Pass rate across related suites (165 + 46 tests): 100%.

Registers tencent-tokenhub (https://tokenhub.tencentmaas.com/v1) as a new API-key provider with model tencent/hy3-preview (256K context). - PROVIDER_REGISTRY entry + TOKENHUB_API_KEY / TOKENHUB_BASE_URL env vars - Aliases: tencent, tokenhub, tencent-cloud, tencentmaas - openai_chat transport with is_tokenhub branch for top-level reasoning_effort (Hy3 is a reasoning model) - tencent/hy3-preview:free added to OpenRouter curated list - 60+ tests (provider registry, aliases, runtime resolution, credentials, model catalog, URL mapping, context length) - Docs: integrations/providers.md, environment-variables.md, model-catalog.json Author: simonweng <simonweng@tencent.com> Salvaged from PR #16860 onto current main (resolved conflicts with #16935 Azure Anthropic env-var hint tests and the --provider choices= list removal in chat_parser).

… alias in normalizer (#16935) Three related fixes around custom env-var-name hints for provider entries. 1. Azure Anthropic path: previously hardcoded to look up AZURE_ANTHROPIC_KEY then ANTHROPIC_API_KEY with no way to override. If a user wrote model: provider: anthropic base_url: https://my-resource.services.ai.azure.com/anthropic key_env: MY_CUSTOM_KEY the key_env hint was silently ignored and the resolver raised 'No Azure Anthropic API key found' even when MY_CUSTOM_KEY was set in the environment. The runtime now checks, in order: (1) os.getenv(model_cfg.key_env) (2) os.getenv(model_cfg.api_key_env) # docs alias (3) model_cfg.api_key # inline value (4) AZURE_ANTHROPIC_KEY # historical default (5) ANTHROPIC_API_KEY # historical default Error message updated to mention key_env as an option. 2. Provider entry normalizer (_normalize_custom_provider_entry): accept 'api_key_env' as a snake_case alias for 'key_env', and 'apiKeyEnv' as a camelCase alias. Adds both to the _KNOWN_KEYS set so the 'unknown config keys ignored' warning doesn't fire on valid configs. 3. _VALID_CUSTOM_PROVIDER_FIELDS: add 'key_env'. That set documents supported custom_providers entry fields; it was drifting from reality since key_env has been read at runtime in auxiliary_client.py, runtime_provider.py, and main.py for a while. Docs: website/docs/guides/azure-foundry.md now uses the canonical key_env field and notes that api_key_env / keyEnv / apiKeyEnv are accepted as aliases. Validation: 12 new tests in test_runtime_provider_resolution.py covering all 5 Azure Anthropic resolution paths + 4 normalizer-alias tests. Pass rate across related suites (165 + 46 tests): 100%. Co-authored-by: teknium1 <teknium@users.noreply.github.com>

… alias in normalizer (NousResearch#16935) Three related fixes around custom env-var-name hints for provider entries. 1. Azure Anthropic path: previously hardcoded to look up AZURE_ANTHROPIC_KEY then ANTHROPIC_API_KEY with no way to override. If a user wrote model: provider: anthropic base_url: https://my-resource.services.ai.azure.com/anthropic key_env: MY_CUSTOM_KEY the key_env hint was silently ignored and the resolver raised 'No Azure Anthropic API key found' even when MY_CUSTOM_KEY was set in the environment. The runtime now checks, in order: (1) os.getenv(model_cfg.key_env) (2) os.getenv(model_cfg.api_key_env) # docs alias (3) model_cfg.api_key # inline value (4) AZURE_ANTHROPIC_KEY # historical default (5) ANTHROPIC_API_KEY # historical default Error message updated to mention key_env as an option. 2. Provider entry normalizer (_normalize_custom_provider_entry): accept 'api_key_env' as a snake_case alias for 'key_env', and 'apiKeyEnv' as a camelCase alias. Adds both to the _KNOWN_KEYS set so the 'unknown config keys ignored' warning doesn't fire on valid configs. 3. _VALID_CUSTOM_PROVIDER_FIELDS: add 'key_env'. That set documents supported custom_providers entry fields; it was drifting from reality since key_env has been read at runtime in auxiliary_client.py, runtime_provider.py, and main.py for a while. Docs: website/docs/guides/azure-foundry.md now uses the canonical key_env field and notes that api_key_env / keyEnv / apiKeyEnv are accepted as aliases. Validation: 12 new tests in test_runtime_provider_resolution.py covering all 5 Azure Anthropic resolution paths + 4 normalizer-alias tests. Pass rate across related suites (165 + 46 tests): 100%. Co-authored-by: teknium1 <teknium@users.noreply.github.com>

Registers tencent-tokenhub (https://tokenhub.tencentmaas.com/v1) as a new API-key provider with model tencent/hy3-preview (256K context). - PROVIDER_REGISTRY entry + TOKENHUB_API_KEY / TOKENHUB_BASE_URL env vars - Aliases: tencent, tokenhub, tencent-cloud, tencentmaas - openai_chat transport with is_tokenhub branch for top-level reasoning_effort (Hy3 is a reasoning model) - tencent/hy3-preview:free added to OpenRouter curated list - 60+ tests (provider registry, aliases, runtime resolution, credentials, model catalog, URL mapping, context length) - Docs: integrations/providers.md, environment-variables.md, model-catalog.json Author: simonweng <simonweng@tencent.com> Salvaged from PR NousResearch#16860 onto current main (resolved conflicts with NousResearch#16935 Azure Anthropic env-var hint tests and the --provider choices= list removal in chat_parser).