[Bug]: /status Tokens: 0 regressed — SessionStore totals drift from SessionDB/state.db

[Louise-Qiuqiu]

Bug Description

/status can still show Tokens: 0 even when the current gateway session has substantial token usage recorded in SQLite.

This appears to be a regression of the symptom fixed in #1465 / PR #1476, but with a changed root cause.

Steps to Reproduce

1. Run Hermes through the gateway (Telegram in my case).
2. Have a longer conversation so the session clearly accumulates token usage.
3. Send /status.
4. Inspect the same session in both persistence layers.

Expected Behavior

/status should report the real token usage for the current session.

Actual Behavior

/status reports Tokens: 0 even though the same session has non-zero token usage in state.db.

Evidence

In my reproduction, the same session ID had:

• sessions.json / SessionEntry.total_tokens = 0
• state.db token fields populated with large non-zero values

Example from one affected session:

• session_id: 20260407_170736_30bcaff2
• sessions.json total_tokens = 0
• state.db input_tokens = 171876
• state.db output_tokens = 7295
• state.db cache_read_tokens = 1517184
• state.db reasoning_tokens = 2648

Regression History

Issue #1465 was fixed by PR #1476 (fix(gateway): make /status report live state and tokens).

That fix explicitly threaded input_tokens / output_tokens from gateway/run.py into session_store.update_session(...), and added regression coverage in tests/gateway/test_status_command.py.

A later refactor appears to have reintroduced the visible bug:

• commit 20441cf2 (fix(insights): persist token usage for non-CLI sessions)
• gateway/run.py stopped passing token counts into session_store.update_session(...)
• gateway/session.py::update_session() was reduced to only updating lightweight metadata like last_prompt_tokens
• the previous regression test assertion was also weakened so it no longer verifies token propagation into SessionStore

Root Cause Analysis

Current behavior looks like this:

• real token usage is persisted directly into SQLite / state.db
• /status still reads session_entry.total_tokens
• session_entry.total_tokens comes from SessionStore / sessions.json
• that field is no longer kept in sync with the real token counts

So the symptom is a regression, but the root cause has changed:

• old root cause (/status always shows Tokens: 0 and Agent Running: No #1465): gateway never forwarded actual token counts into SessionStore
• current root cause: token persistence moved to SQLite, but /status still depends on stale SessionStore token totals

Affected Component

Gateway

Messaging Platform (if gateway-related)

Telegram

Operating System

Ubuntu 24.04 Server

Python Version

3.13.5

Hermes Version

0.7.0

Relevant Files

• gateway/run.py
• gateway/session.py
• tests/gateway/test_status_command.py

Proposed Fix (optional)

One of these needs to happen consistently:

1. Make /status read token usage from SessionDB / SQLite instead of SessionStore.total_tokens, or
2. Restore synchronization so SessionStore.total_tokens is updated from the authoritative token counts again.

Either way, the regression test should assert the source used by /status, so this does not drift again.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[KianaMei]

环境是 Ubuntu 24.04 + Telegram Gateway。

复现链路：

1. Telegram 私聊正常对话，模型实际在工作。
2. 发送 /status。
3. Bot 返回：
   • Session ID: 20260410_085716_79db24
   • Tokens: 0
4. 紧接着继续追问“什么破玩意 tokens 0啥意思”，后续这一轮对话又实际跑了 293.7s 才返回，所以不是“没调用模型”。

本地证据：

• agent.log:43220 里，Bot 发出的 /status 消息正文明确是：
  • Session ID: 20260410_085716_79db24
  • Tokens: 0
• gateway.log:346 里，用户随后追问 什么破玩意 tokens 0啥意思
• gateway.log:356 里，这轮追问最终完成：response ready ... time=293.7s api_calls=5

同一个 session 在 SQLite 里的真实 token：

select id, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, model
from sessions
where id = '20260410_085716_79db24';

结果：

• input_tokens = 191921
• output_tokens = 1826
• cache_read_tokens = 122496
• cache_write_tokens = 0
• reasoning_tokens = 0
• model = gpt-5.4

另外，当前 chat 对应的 SessionStore 仍然是这种状态：

• session_key = agent:main:telegram:dm:8184390568
• session_id = 20260410_094709_58a9b2
• total_tokens = 0
• input_tokens = 0
• output_tokens = 0
• cache_read_tokens = 0
• cache_write_tokens = 0
• last_prompt_tokens = 70317

：

• state.db 里的真实 token 在增长
• SessionStore / sessions.json 的 total_tokens 仍然是 0
• /status 继续读的是这份脱节的 SessionStore 统计

[DEAD1SIDE]

/insights looks to be affected as well for me.

[malaiwah]

PR #8355 includes the get_session_token_totals() fix from #5989 (same approach — read from SessionDB, fall back to SessionStore) as part of a broader /status overhaul. Credit to @blasai1739217-cmyk for the original diagnosis and fix in #5989.

[BrennerSpear]

We're seeing this too.

In our case it showed up via Discord /status: Hermes was clearly alive and responding in-thread, but /status reported Tokens: 0, and the status output was generally misleading about current session state.

Our local inspection matches the root cause described here: /status is still reading session_entry.total_tokens, while the real token/accounting state is no longer being kept in sync there. So from the user side it looks like the session has no usage even after multiple messages.

So: +1, reproduced from our side too.