#Usage cache is rebuilding in the background. Displayed totals may be stale. refreshing: 150 pending

1 messages Β· Page 1 of 1 (latest)

terse laurel
#

This never actually updates cache. Latest version.

Usage cache is rebuilding in the background. Displayed totals may be stale. refreshing: 150 pending, 150 stale, 24 cached

Very slow Usage tab

marble geyserBOT
# terse laurel This never actually updates cache. Latest version. Usage cache is rebuilding ...

I checked the current docs/source. The Usage tab is built from local session transcript JSONL files; it scans/discovers sessions and then aggregates token/cost data, so 150 stale/pending sessions can be genuinely slow if those transcripts are large. But if the count literally never decreases after waiting/reloading, that smells like a stuck cache/worker path or a UI/gateway mismatch.

Can you paste the exact version anyway?

openclaw --version
openclaw status --all

Then try this quick isolation loop:

openclaw logs --follow

Open the Usage tab, hit refresh, and watch for errors around sessions.usage, usage.cost, transcript parsing, or gateway request timeouts. Also try narrowing the date range to today/7d; the UI currently caps list loading at 1,000 sessions, but it still has to read matching transcript files for aggregation.

marble geyserBOT
# terse laurel This never actually updates cache. Latest version. Usage cache is rebuilding ...

Docs refs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/concepts/usage-tracking
https://docs.openclaw.ai/reference/api-usage-costs

If it still sits at the same 150 pending, 150 stale, 24 cached with no log errors or progress, please file it as a bug with those command outputs + the log lines: https://github.com/openclaw/openclaw/issues. That’s enough signal for someone to reproduce the stuck rebuild path.