Hermes Agent Merges Provider-Switch Routing Fix to Prevent API Keys from Being Sent to Old Endpoints

On October 16, Hermes Agent merged fix #139613 into main, addressing mixed provider routing when creating local sessions. If a request specified a new provider but no base_url, the system could retain the old endpoint from the configuration while using credentials for the new provider, sending a valid key to a different service. This caused an apparent authentication failure and crossed a credential transmission boundary. Merge record

The original report on October 15 used a switch from DeepSeek to Xiaomi as an example: the session had selected a Xiaomi model, but the request was still sent to DeepSeek and returned HTTP 401. The discussion also included reproductions involving other provider combinations. The report noted that an error response could also cause the credential pool to mark a valid key as exhausted, blocking auxiliary calls such as title generation. As a result, replacing the key might not resolve the issue. Issue and reproduction details

The official documentation explains that the runtime resolver produces a unified provider, protocol mode, endpoint, and key for use by chat, gateway, scheduling, and other paths. It also emphasizes that credentials should correspond to their respective endpoints. From an engineering perspective, this incident shows that even when downstream components share a resolver, upstream configuration merging can still create contradictory routes if it updates the provider and URL separately. Runtime provider resolution documentation

The new fix compares the resolved routing identity. When the provider actually changes, it first clears the old endpoint, protocol, and credential settings, then applies explicitly supplied overrides. Aliases for the same route retain their settings, preventing name differences such as vllm and custom from mistakenly deleting a local endpoint. Reviewers observed requests using a real gateway and two local model servers, confirming that after the fix, the key was sent to the expected host. This was a controlled test and does not represent every deployment scenario. Fix and verification

Deployers should next confirm whether their release includes the merge and check the actual routing in both newly created and existing sessions. The official architecture documentation describes expected behavior; it is not independent verification of this defect. Public information has not confirmed that any misdirected keys were abused.