Summary

Describe the problem and fix in 2–5 bullets:

• Problem: Codex secondary usage window was labeled solely from limit_window_seconds, which can report 86400 even when reset cadence is clearly weekly.
• Why it matters: openclaw models status can display Day ... while showing multi-day reset countdowns, which misrepresents codex quota scope.
• What changed: codex usage parsing now infers secondary label from reset cadence as a fallback (using primary/secondary reset gap) and keeps explicit weekly windows intact.
• What did NOT change (scope boundary): no auth/profile probing, transport, or CLI rendering pipeline changes outside codex usage label selection.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: models status states "Day" but displays weekly usage for openai-codex #29783
• Related [Bug]: Heartbeat task continues to use the previous model after a timeout error and model switch #31705

User-visible / Behavior Changes

• openclaw models status now labels codex secondary usage as Week when reset cadence indicates a weekly budget, even if API window seconds report 24h.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node v22, Vitest
• Model/provider: openai-codex usage parser path
• Integration/channel (if any): N/A
• Relevant config (redacted): N/A

Steps

1. Parse codex usage payload where:
   • primary_window.reset_at = T
   • secondary_window.limit_window_seconds = 86400
   • secondary_window.reset_at = T + 5 days
2. Run usage formatting in models status pipeline.
3. Observe secondary label.

Expected

• Secondary label is Week (cadence is clearly weekly).

Actual

• Before fix: secondary label was Day whenever limit_window_seconds mapped to 24h.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Before:

• pnpm vitest src/infra/provider-usage.fetch.codex.test.ts -t "reset cadence"
• Failure: expected Week label, received Day.

After:

• pnpm vitest src/infra/provider-usage.fetch.codex.test.ts
• pnpm vitest src/infra/provider-usage.test.ts src/infra/provider-usage.format.test.ts src/commands/models/list.status.test.ts
• pnpm check

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • explicit weekly secondary windows remain Week.
  • ambiguous 86400 secondary window with weekly reset cadence now maps to Week.
  • standard daily case (short reset cadence) remains Day.
• Edge cases checked:
  • codex usage parser tests and broader provider usage/model-status tests pass.
• What you did not verify:
  • live codex dashboard/API account-specific behavior in a real OAuth account.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this commit.
• Files/config to restore: N/A (code-only parser change).
• Known bad symptoms reviewers should watch for: unexpected Week labeling where reset cadence is not actually long-lived.

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk: cadence-based fallback could over-label Week if reset timestamps are malformed.
  • Mitigation: fallback only applies in the 24h-labeled secondary window case and requires a large reset-gap threshold.