Codex weekly-only primary window is mislabeled as “5-hour limit”

Disclosure: This analysis, evidence collection, issue text, and submission were performed by Hermes Agent using @mac-wifi's GitHub account with the account owner's authorization.

Bug description

When OpenAI Codex returns a single seven-day account-usage window in rate_limit.primary_window, Hermes WebUI labels it “5-hour limit”. The percentage and reset timestamp appear to be correct; the window label is wrong.

This is currently reproducible with a ChatGPT Plus / OpenAI Codex OAuth account. The provider response explicitly identifies the window as 604800 seconds (seven days), but that duration metadata is discarded before the WebUI renders the quota card.

Observed behaviour

At 2026-08-07 14:21:39 Europe/London, Settings → Providers showed:

• Label: 5-hour limit
• Remaining: 15% (85% used)
• Reset: 08/08/2026, 11:10:59

The displayed reset was 20h 49m 20s after the last-checked time, so it could not describe a five-hour window.

A subsequent sanitized live query of the same Codex usage endpoint returned:

{
  "plan_type": "plus",
  "rate_limit": {
    "primary_window": {
      "limit_window_seconds": 604800,
      "reset_at": 1786183859,
      "used_percent": 87
    }
  }
}

604800 seconds is exactly seven days. Reset epoch 1786183859 is 2026-08-08T10:10:59Z / 2026-08-08T11:10:59+01:00, matching the WebUI timestamp. There was no secondary_window in the response.

Steps to reproduce

1. Configure an OpenAI Codex OAuth credential whose usage response currently contains only a seven-day primary_window.
2. Open Settings → Providers.
3. Refresh provider usage.
4. Observe that the sole window is labelled “5-hour limit”, despite limit_window_seconds: 604800 and a reset potentially more than five hours away.

Expected behaviour

The label should be derived from provider duration metadata, not from primary_window/secondary_window slot position:

• 18000 seconds / 300 minutes → 5-hour limit
• 604800 seconds / 10080 minutes → Weekly limit
• Missing or unknown duration → neutral Usage limit (or preserve a neutral upstream label)

Root-cause findings

The installed Hermes Agent parser currently maps slots by position and discards limit_window_seconds:

for key, label in (("primary_window", "Session"), ("secondary_window", "Weekly")):
    ...
    AccountUsageWindow(
        label=label,
        used_percent=float(used),
        reset_at=_parse_dt(window.get("reset_at")),
    )

The WebUI then converts Codex Session to 5-hour limit:

if(provider==='openai-codex'){
  if(raw.toLowerCase()==='session') return t('provider_quota_session_limit');
  if(raw.toLowerCase()==='weekly') return t('provider_quota_weekly_limit');
}

The same slot-based backend mapping and frontend rewrite are still present on current WebUI origin/master at commit 5f3117f81e2031361f01e557318baf1010ad21c3 (2026-08-05), so updating the local WebUI alone does not resolve it.

A robust fix likely needs Hermes Agent's AccountUsageWindow/Codex parser to preserve or correctly interpret limit_window_seconds, plus WebUI rendering that does not infer a five-hour duration solely from the label Session.

Environment

• OS: Debian GNU/Linux 13 (x86_64), kernel 6.12.90+deb13.1-amd64
• WebUI: v0.52.106, commit 0a31a4a1e2a0977d55673b91ca15eea73d2e06c9
• Current upstream WebUI checked: 5f3117f81e2031361f01e557318baf1010ad21c3
• Hermes Agent: v0.18.2 (2026.7.7.2), upstream aecb9ca8, local 111544d5 (+1 carried commit)
• Hermes runtime Python: 3.11.15
• OpenAI SDK: 2.24.0
• Provider/account: OpenAI Codex OAuth, Plus plan, one device_code credential

No token, account ID, or credential content is included above.

Related

• #6805 is a broader provider-status/limits feature request and independently notes that the OpenAI Codex API now reports a single weekly window (limit_window_seconds: 604800). This issue is the focused correctness bug in the existing Providers quota card.
• #1805 introduced the position-based Session/Weekly rendering path.