Skip to content

session_status usage data is unstable: Day window jumps and usage fields intermittently missing #39400

Description

@hualinsen

Summary

When running a cron-based usage monitor (built on session_status), Day window usage appears unstable:

  1. Day percentage/reset values sometimes jump unexpectedly (e.g., after a normal downward trend, suddenly returning near/at 100%).
  2. Usage fields are intermittently missing — some runs return only Tokens/Cache/Context, with no 5h/Day usage window lines.
  3. Output alternates between “window-based usage” and “token-only view” across adjacent runs, reducing monitor reliability.

Reproduction

  1. Create a cron job that calls session_status at fixed intervals (hourly / every 2 hours).
  2. Parse and report 5h and Day window usage from the response.
  3. 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

  1. Provide stable structured usage fields (preferably JSON), e.g.:
    • usage.window5h.percent
    • usage.window5h.resetAt
    • usage.windowDay.percent
    • usage.windowDay.resetAt
    • usage.source
  2. If upstream usage is unavailable, return an explicit availability state (e.g., usage.unavailable=true + reason), instead of silently omitting fields.
  3. 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.”

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions