Hermes proposes account-level controls for credential pools

Hermes contributors have proposed a more explicit control surface for multi-account credential pools. Separate changes expose entry identity, set deterministic priority, clear one account's local exhaustion state and force a supported OAuth entry through the existing refresh path. The common problem is operational: adding a healthy account or recovering one account should not require editing a secret-bearing file or clearing every sibling's cooldown. These are open CLI proposals, not instructions to mutate a production pool today.

The facts

- The priority proposal adds placement after account creation and a command to move an existing entry by index, ID or exact label. - Priority values remain a contiguous zero-based sequence, with out-of-range requests clamped and the effective position reported. - The ordering command reports when a provider does not use fill_first; Anthropic's manual-before-seeded ordering is preserved. - The targeted reset proposal clears only the selected credential; omitting the target retains the existing pool-wide behavior. - The refresh proposal rejects unsupported non-OAuth entries and leaves a failed refresh benched or quarantined rather than claiming recovery. - The listing proposal exposes entry IDs and priorities so operators can target ambiguous labels without reading the underlying auth file.

Why it matters

Pooling accounts creates state that cannot be reduced to connected or disconnected. A grant can be alive while its quota is exhausted, an account can recover outside the agent, and a local cooldown can outlast that recovery. The refresh proposal explicitly says token refresh proves the grant, not replenished quota: a still-capped entry can receive another rate limit and return to cooldown. That is a more truthful operational model than a reset button that implies the provider's allowance has changed.

Current

Inspected on 2026-09-07. The Hermes Agent stable-release baseline is v2026.8.31 published 2026-08-31T19:29:49Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is NousResearch/hermes-agent PR #104664 (https://github.com/NousResearch/hermes-agent/pull/104664). Supporting context comes from NousResearch/hermes-agent PR #104661 (https://github.com/NousResearch/hermes-agent/pull/104661); NousResearch/hermes-agent PR #104660 (https://github.com/NousResearch/hermes-agent/pull/104660); NousResearch/hermes-agent PR #104662 (https://github.com/NousResearch/hermes-agent/pull/104662). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Review identity, ordering and recovery as separate decisions. An operator should be able to identify the exact entry, predict the next selection under the configured strategy, and observe whether recovery persisted after reload. The refresh author reports a bounded live test on a four-account Codex pool, with the recovered entry serving subsequent requests; that is a case report, not a promise for every provider. Priorities are also not pinning: random or least-used selection cannot be made deterministic by merely moving a row. Wait for the appropriate merged version and test with a scoped account before replacing established recovery procedures.

Caveat

The proposals are open and their tests are contributor-reported, with focused suites rather than a full green repository suite. No credentials were inspected or changed for this article. Local status reset does not restore provider quota, and OAuth recovery does not authorize bypassing provider restrictions.