Enhancement: Add Nous Research / Hermes Agent as a provider

[sean808080]

Provider request: Nous Research / Hermes Agent

What is it?
Nous Research runs a managed AI subscription portal (Nous Portal) that powers Hermes Agent. Users authenticate via OAuth at portal.nousresearch.com and receive usage credits/limits similar to other providers CodexBar already tracks.

Why add it?
Nous Portal is a growing subscription tier (OpenAI-compatible endpoint) with monthly credit budgets. Users would benefit from seeing their Nous credit balance and reset windows directly in the menu bar alongside their other providers.

Auth method / endpoints to explore

• Auth: OAuth via Nous Portal (portal.nousresearch.com)
• API base: OpenAI-compatible endpoint; credits/usage likely accessible via the portal dashboard or a /v1/usage style endpoint
• Relevant docs: https://hermes-agent.nousresearch.com/docs/integrations/nous-portal

Precedent
Similar to how OpenRouter (API token + usage endpoint) and other portal-based providers are handled. If Nous exposes a /v1/usage or billing RPC endpoint, the integration pattern should be straightforward.

Happy to help test or provide more details about the API surface if the Nous team can share endpoint docs.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 9, 2026, 2:43 PM ET / 18:43 UTC.

Summary
Keep open: current main and the latest release do not include a Nous/Hermes provider, and the request fits CodexBar’s provider direction but needs endpoint/auth discovery before implementation is safe.

Reproducibility: not applicable. this is a new-provider enhancement request, not a bug in existing behavior. Current-main verification was a source search showing the provider is absent.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Maintainers should first confirm the Nous endpoint/auth contract and whether this provider belongs in core before a fix lane attempts code.

Review details

Best possible solution:

Add Nous after maintainers confirm a stable usage or billing API and an auth flow that fits the existing provider descriptor, fetch strategy, settings, docs, and focused test patterns.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a new-provider enhancement request, not a bug in existing behavior. Current-main verification was a source search showing the provider is absent.

Is this the best way to solve the issue?

Unclear: CodexBar has a maintainable provider pattern and OpenRouter-like precedent, but the request first needs a documented Nous usage endpoint and an auth/privacy decision.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No stable Nous Portal usage or billing endpoint is identified in the issue, so implementation could otherwise drift into fragile dashboard scraping or private API assumptions.
• Nous auth/config storage may affect provider auth and privacy behavior, which VISION.md says needs sign-off when unclear.

Codex review notes: model gpt-5.5, reasoning high; reviewed against a4f278d91fe4.

Label changes

Label changes:

• add P3: This is a useful but speculative provider enhancement with no broken current CodexBar behavior.
• add impact:auth-provider: The request is specifically about adding a new provider and OAuth/API-backed usage source.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a useful but speculative provider enhancement with no broken current CodexBar behavior.
• impact:auth-provider: The request is specifically about adding a new provider and OAuth/API-backed usage source.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; it directs provider work to stay small, mirror new logic with focused tests, avoid live provider/keychain probes unless requested, and keep provider data siloed. (AGENTS.md:4, a4f278d91fe4)
• Vision fit: VISION.md makes provider limits, credits, spend, status, and reset windows core scope, while putting unclear auth/privacy provider additions in the sign-off bucket. (VISION.md:3, a4f278d91fe4)
• Not implemented on current main: UsageProvider currently enumerates providers through deepgram and has no Nous, Hermes, or nousresearch case; a repository-wide search for those names returned no source, test, or docs hits. (Sources/CodexBarCore/Providers/Providers.swift:5, a4f278d91fe4)
• Latest release check: The latest release tag v0.32.5 also has no Nous/Hermes references in the provider enum or provider docs. (920997c6a365)
• Provider addition surface: The development docs list the expected new-provider touchpoints: UsageProvider case, core descriptor/fetcher wiring, app-side implementation, registry registration, and icon assets. (docs/DEVELOPMENT.md:101, a4f278d91fe4)
• Existing OpenRouter precedent: OpenRouter is the closest current API-token precedent: it uses provider metadata with credits support and an API fetch strategy, with docs describing credits/key-rate-limit API reads and an overrideable API URL. (Sources/CodexBarCore/Providers/OpenRouter/OpenRouterProviderDescriptor.swift:34, a4f278d91fe4)

Likely related people:

• Peter Steinberger: Current checked-out provider enum, registry, OpenRouter descriptor, and provider docs blame to this author in the available history. (role: recent area contributor; confidence: medium; commits: 920997c6a365, a4f278d91fe4; files: Sources/CodexBarCore/Providers/Providers.swift, Sources/CodexBar/Providers/Shared/ProviderImplementationRegistry.swift, Sources/CodexBarCore/Providers/OpenRouter/OpenRouterProviderDescriptor.swift)
• Ratul Sarna: git shortlog over provider paths shows substantial adjacent provider-area history, but the shallow checkout does not expose exact commits for this routing signal. (role: adjacent provider contributor; confidence: low; files: Sources/CodexBarCore/Providers, Sources/CodexBar/Providers)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.