Summary
When running a cron-based usage monitor (built on session_status), Day window usage appears unstable:
- Day percentage/reset values sometimes jump unexpectedly (e.g., after a normal downward trend, suddenly returning near/at 100%).
- Usage fields are intermittently missing — some runs return only Tokens/Cache/Context, with no 5h/Day usage window lines.
- Output alternates between “window-based usage” and “token-only view” across adjacent runs, reducing monitor reliability.
Reproduction
- Create a cron job that calls
session_status at fixed intervals (hourly / every 2 hours).
- Parse and report
5h and Day window usage from the response.
- Let it run continuously for 24h+.
Observed over time:
- Some runs show normal decrement behavior.
- Some runs show abrupt Day window jumps.
- Some runs contain no usage-window fields at all (token/cache only).
Actual behavior
- Adjacent runs from the same monitor can disagree in structure and values.
- It is hard to distinguish a real provider-side reset vs data-source inconsistency.
Expected behavior
- Provide stable structured usage fields (preferably JSON), e.g.:
usage.window5h.percent
usage.window5h.resetAt
usage.windowDay.percent
usage.windowDay.resetAt
usage.source
- If upstream usage is unavailable, return an explicit availability state (e.g.,
usage.unavailable=true + reason), instead of silently omitting fields.
- If a reset is legitimate, include metadata to explain it (e.g.,
resetReason / billing-cycle boundary).
Impact
- Threshold automation (e.g., “disable low-priority jobs when Day <= 50%”) can misfire.
- Usage alerts become noisy/untrustworthy.
- End-user confidence in quota reports decreases.
Environment
- OpenClaw:
2026.2.26 (bc50708)
- Provider/model:
openai-codex/gpt-5.3-codex (OAuth)
- Trigger path: cron job ->
session_status parsing
- Channel: Telegram (delivery only, likely unrelated to root cause)
Current workaround
- Only emit 5h/Day report when both fields are present.
- Fallback to token-only output when window fields are missing.
- Mark sudden resets as “suspected reset / needs confirmation.”
Summary
When running a cron-based usage monitor (built on
session_status), Day window usage appears unstable:Reproduction
session_statusat fixed intervals (hourly / every 2 hours).5handDaywindow usage from the response.Observed over time:
Actual behavior
Expected behavior
usage.window5h.percentusage.window5h.resetAtusage.windowDay.percentusage.windowDay.resetAtusage.sourceusage.unavailable=true+ reason), instead of silently omitting fields.resetReason/ billing-cycle boundary).Impact
Environment
2026.2.26 (bc50708)openai-codex/gpt-5.3-codex(OAuth)session_statusparsingCurrent workaround