Summary
When Hermes is configured with provider=openai-codex as base_url=https://chatgpt.com/backend-api/codex, requests consistently show up as “Other” in the Codex usage dashboard instead of clearer categories like CLI or Exec.

See https://chatgpt.com/codex/settings/usage page:

This creates confusion for users who rely on the Codex dashboard to understand where usage is coming from.

Context

• Hermes has a built-in openai-codex provider path (not a local one-off hack).
• Codex usage dashboard categories (CLI / Extension / GitHub Code Review / Exec / Other) are user-facing, but Hermes-driven traffic is currently grouped as Other.
• This issue is about telemetry/attribution clarity and compliant integration behavior.
• This is NOT a request for User-Agent spoofing or impersonation.

What I checked (to avoid duplicates)
Related but not the same:

• Feature: Session Usage Visibility — Persistent Token Totals and Context Window Percentage in the CLI #1091 (session usage visibility in Hermes CLI)
• [Bug]: terminal subprocesses inherit OPENAI_BASE_URL and break external Codex CLI when Hermes uses a custom endpoint #1002 (OPENAI_BASE_URL leakage into subprocesses)
• [Bug]: Codex Responses request has unsupported field(s): parallel_tool_calls, prompt_cache_key, tool_choice. #930 (Codex Responses field compatibility)
• ChatGPT OAuth setup for openai-codex does not verify/install Codex CLI dependency #259 (Codex setup/dependency flow)

None of these directly address Codex dashboard category attribution for Hermes-origin traffic.

Steps to reproduce

1. Configure Hermes with:
   • model.provider: openai-codex
   • model.base_url: https://chatgpt.com/backend-api/codex
2. Use Hermes normally for coding tasks with tool calls.
3. Open Codex usage dashboard in ChatGPT (settings/usage breakdown).
4. Observe traffic appears under “Other”.

Expected behavior
One (or more) of the following:

1. Documented explanation in Hermes docs: why traffic appears as “Other” and what determines category mapping.
2. If feasible and compliant, adjust integration so Hermes traffic is attributed more specifically (for example Exec-like where appropriate), without spoofing or misrepresentation.
3. Add a runtime note/warning in Hermes status output when using openai-codex path:
   “Codex dashboard may classify Hermes traffic as Other.”

Actual behavior
Usage is visible, but attribution is opaque (“Other”), causing user confusion and making plan/limit analysis harder.

Why this matters

• Users use these categories for cost/limit planning.
• “Other” obscures workload source and reduces trust in telemetry.
• This is increasingly important for heavy automation and cron-based workflows.

Requested outcome
Please clarify maintainers’ intended stance and roadmap:

• Is “Other” expected and unavoidable for Hermes architecture today?
• Is there a compliant path to better category attribution?
• If not, can we at least document this clearly in the provider docs and CLI status output?

Acceptance criteria

• Clear maintainer statement on expected Codex category behavior for Hermes traffic.
• Documentation update in provider/config docs (openai-codex section).
• Optional: Hermes status/doctor hint about usage-category interpretation.
• Optional (if feasible/compliant): improved attribution behavior with tests.