Skip to content

[Bug]: direct sessions show "unknown/1049k (?%)" because totalTokens stored as null in sessions.json on v2026.5.18 #84490

@rrtt217

Description

@rrtt217

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

All direct/main/dashboard/dreaming sessions show unknown/1049k (?%) because totalTokens is stored as None in sessions.json across all directly-managed sessions on v2026.5.18, while subagent sessions correctly record usage.

Steps to reproduce

  1. Start OpenClaw 2026.5.18 (50a2481) with default Pi runtime.
  2. Open any direct channel (QQBot direct message, webchat, dashboard, or dreaming narrative).
  3. Interact with the session normally.
  4. Run openclaw status — observe unknown/1049k (?%) in the status line.
  5. Inspect ~/.openclaw/agents/main/sessions/sessions.json — note totalTokens: None for all direct-type sessions.

Alternatively:

  • Use session reset to create a fresh session.
  • Repeat steps 3-5 — the new session also shows totalTokens: None.

Expected behavior

The session status display should show the actual token usage (e.g. 6.4k/1.0m (1%)), and sessions.json should store the cumulative totalTokens as an integer just like subagent sessions do.

Actual behavior

  • Session status displays unknown/1049k (?%) or ?/1049k (?%).
  • sessions.json records totalTokens: None for all direct/main/dashboard/dreaming session entries.
  • Session .jsonl files contain no usage.totalTokens field in any of their message entries (0 out of 61 lines in the main qqbot session file).
  • SubAgent sessions are not affected — all 8 subagent sessions correctly have totalTokens as integers (14k~96k).
  • Manual session reset and session new do NOT fix the issue.

OpenClaw version

2026.5.18 (50a2481)

Operating system

Linux (Fedora 44), x86_64

Install method

npm global (stable channel)

Model

deepseek-v4-flash-ascend (via ustc provider)

Provider / routing chain

openclaw -> https://api.llm.ustc.edu.cn/v1 -> deepseek-v4-flash-ascend

Additional provider/model setup details

Model is configured under providers.ustc in openclaw.json. contextTokens set to 1048576 (1M). Default runtime is OpenClaw Pi Default. No per-agent overrides; default agent only.

Logs, screenshots, and evidence

Evidence from sessions.json (aggregated by session type):

cron           totalTokens=None: 1  totalTokens=ok: 1
dashboard      totalTokens=None: 2
dreaming       totalTokens=None: 4  totalTokens=ok: 1
main           totalTokens=0:   1  totalTokens=None: 1
qqbot:direct   totalTokens=None: 2
subagent       totalTokens=ok:  8

Total sessions: 20. Sessions with totalTokens=None: 10 (50%). All subagent sessions (8/8) work fine.

Sample session entry showing the bug:

{
  "label": "qqbot:c2c:05694447D9D906990AF9B7B1D231EE38",
  "sessionFile": ".../sessions/8e41486e-4d41-4b89-a468-b1f556a8ce4e.jsonl",
  "contextTokens": 1048576,
  "totalTokens": null
}

Session jsonl file (61 lines) — zero lines contain usage.totalTokens.
Last line shows no usage tracking at all: {'type': 'id', 'parentId': 'timestamp', 'message'}

Impact and severity

Affected: All direct/main/dashboard/dreaming sessions on v2026.5.18.
Severity: Medium (cosmetic + data integrity). The token usage display is broken showing unknown/1049k (?%) instead of actual consumption. The totalTokens field is not persisted in sessions.json for affected session types.
Frequency: Always (10/10 affected sessions).
Consequence: Users cannot see actual token usage in session status. Session metadata integrity is partially lost. Token tracking for cost calculation and compaction decisions may be affected.
Workaround: None available. session reset and session new do not resolve the issue.

Additional information

This appears to be a regression in v2026.5.18 where the usage tracking path for direct sessions (Pi Default runtime) was changed. SubAgent sessions use a different runtime path that still records usage correctly. The jsonl file for the qqbot direct session (61 lines) has zero usage entries — the usage field is simply never written. This is not a display bug but a storage bug.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:data-lossCan lose, corrupt, or silently drop user/session/config data.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions