Repository navigation
usage: dashboard shows 0 tokens for today with opencode CLI >= 2.0 #262
Description
Summary
The usage dashboard shows 0 tokens for today when using opencode CLI >= 2.0, because the CLI SQLite history reader queries the wrong table with a stale providerID filter.
Environment
- Extension:
ltmoerdani.opencode-copilot-chat0.7.9 - opencode CLI: 2.0.32
- OS: Linux (Omarchy)
Reproduction
- Use opencode CLI >= 2.0 (which writes sessions to
session_v2table, notmessage) - Open the usage dashboard in VS Code
- "Today" shows 0 tokens despite active CLI usage
Expected Behavior
The dashboard should display today's token usage from the local opencode.db.
Actual Behavior
Today shows 0. The SQL in out/usage/history.js reads from the message table filtering providerID = 'opencode-go', but CLI >= 2.0 writes today's data to session_v2 (with flat columns) and uses providerID = 'opencode'.
Additional Context
The message table still has historical rows (pre-2.0) with providerID = 'opencode', but today's sessions only exist in session_v2. A UNION ALL across both tables resolves it. Patch applied locally and verified working.
Activity
ltmoerdani commentedon Oct 20, 2026
Confirmed and fixed in #263. You were right that the reader was stuck on the old
messagetable — CLI 2.x moved per-message usage intosession_messageand we weren't reading it.One thing on the patch from the issue: I had to change the approach, because on a migrated database
session_v2holds one aggregated row per session (its Go total equals the per-message total), soUNION ALLagainst it doubles every dollar and token. Measured on my own DB: $5.34 reported vs $2.67 actual. TheproviderID = 'opencode'filter also picks up Zen free-model usage — Go rows useopencode-go. What shipped instead: a UNION overmessage+session_message(deduplicated by row), with the cwd joined fromsession_v2.directory, plus a fallback for fresh 2.x installs that never had the legacy table.The fix lands in v0.7.10 — it'll reach you through the normal extension update once we publish, no settings change needed on your side.
Happy to hear you'd already patched it locally — the table layout in your report saved me some schema archaeology. If the numbers look off after v0.7.10, ping this thread.