Repository navigation
bunx ccusage@latest opencode takes over two minutes on large OpenCode history (~3.6 GB, 87k messages) #1344
Description
Activity
This issue was auto-closed. Issues from new contributors are auto-closed by default.
Maintainers review auto-closed issues and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md may not be reopened or receive a reply.
Keep the issue short, concrete, and written in your own voice.
If a maintainer replies
lgtmi, your future issues will stay open. If a maintainer replieslgtm, your future issues and PRs will stay open.See CONTRIBUTING.md.
I get the same problem with just 600 megabytes of history.
with bun, ccusage installed globally:% time ccusage opencode monthly ccusage opencode monthly 269.70s user 1.28s system 99% cpu 4:32.43 totalwith npx:
% time npx ccusage@latest opencode monthly npx ccusage@latest opencode monthly 271.60s user 1.54s system 99% cpu 4:34.97 totalboth with version @20.0.14
% du -h -d 1 ~/.local/share/opencode 0B ~/.local/share/opencode/repos 218M ~/.local/share/opencode/snapshot 245M ~/.local/share/opencode/bin 24K ~/.local/share/opencode/plans 188M ~/.local/share/opencode/storage 30M ~/.local/share/opencode/project 136K ~/.local/share/opencode/tool-output 8.2M ~/.local/share/opencode/log 1.3G ~/.local/share/opencodeMeasuring with Claude Code, which has a lot lot more data (around 6 gigabyte)
% time ccusage claude monthly ccusage claude monthly 2.55s user 1.15s system 35% cpu 10.377 totalTested on a MacBook M4 Pro
Reacted by turttonThank you for merging my changes!
Sorry about that — I didn't know that force pushing would prevent the PR from being reopened🙏Historical audit: this discussion was auto-closed by the legacy contributor gate. That closure did not assess technical importance.
Audit result: resolved. A later merged change or the current
mainimplementation covers this request. This item is kept for history and does not need to be reopened.
What do you want to change?
Speed up PricingMap::find() by adding a result cache so repeated lookups of the same model name skip expensive fuzzy matching. Also remove a redundant missing-pricing check in the OpenCode adapter.
Why?
bunx ccusage@latest opencodetakes over two minutes on my machine.Profiling showed that 91% of the time goes to PricingMap::find() — ~21 seconds for OpenCode alone, plus similar overhead from other agents.
My OpenCode SQLite database has ~87,000 messages and is 3.6 GB. Despite only 47 unique model names, each message independently repeats the full pricing lookup chain. 36% of lookups miss the exact HashMap and fall through to iterating all 2,200 pricing entries with substring matching — roughly 150 million string comparisons in total.
How? (optional)
Two changes:
The cache lives in the shared PricingMap layer, so all agent adapters (Claude Code, Codex, Amp, etc.) benefit from it transparently. Memory overhead is negligible (~5 KB for typical usage).