Skip to content

Repository navigation

bunx ccusage@latest opencode takes over two minutes on large OpenCode history (~3.6 GB, 87k messages) #1344

New issue
New issue
Closed
Closed
bunx ccusage@latest opencode takes over two minutes on large OpenCode history (~3.6 GB, 87k messages)#1344
Labels
triage:resolvedResolved by a later change or current implementation.

Description

@turtton
turtton
opened on Jun 21, 2026

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 opencode takes over two minutes on my machine.

Image

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:

  1. Add a result cache to PricingMap::find() — A OnceLock<Mutex<FxHashMap<String, Option>>> caches lookup results by model name (including misses). With only 47 unique models, the expensive fallback scan would run at most 47 times instead of 67,000+. The cache is invalidated automatically whenever the pricing table is updated (load_json, apply_overrides, etc.), so it stays consistent.
  2. Skip the redundant missing-pricing check in the OpenCode adapter — Both calculate_open_code_cost and missing_open_code_pricing independently iterate through the same model candidates. When cost calculation already found pricing, the second check can be skipped entirely.

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).

Activity

  1. pullfrog commented on Jun 21, 2026

    @pullfrog
    pullfrogBot
    on Jun 21, 2026 – with Pullfrog
    Contributor

    Pullfrog  ｜ Build this ➔ ｜ Make a plan ➔

  2. github-actions commented on Jun 21, 2026

    @github-actions
    github-actionsBot
    on Jun 21, 2026 – with GitHub Actions
    Contributor

    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 replies lgtm, your future issues and PRs will stay open.

    See CONTRIBUTING.md.

  3. github-actions
    closed this as completedon Jun 21, 2026
  4. ryoppippi
    reopened this on Jun 21, 2026

  5. ryoppippi commented on Jun 21, 2026

    @ryoppippi
    ryoppippi
    on Jun 21, 2026
    Member

    @turtton could you send a pr?

  6. Marrocco-Simone commented on Jul 7, 2026

    @Marrocco-Simone
    Marrocco-Simone
    on Jul 7, 2026

    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 total

    with npx:

    % time npx ccusage@latest opencode monthly
npx ccusage@latest opencode monthly  271.60s user 1.54s system 99% cpu 4:34.97 total

    both 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/opencode

    Measuring 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 total

    Tested on a MacBook M4 Pro

  7. turtton commented on Jul 9, 2026

    @turtton
    turtton
    on Jul 9, 2026
    ContributorAuthor

    Thank you for merging my changes!
    Sorry about that — I didn't know that force pushing would prevent the PR from being reopened🙏

  8. turtton
    closed this as completedon Jul 9, 2026

  9. ryoppippi commented on Aug 31, 2026

    @ryoppippi
    ryoppippi
    on Aug 31, 2026
    Member

    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 main implementation covers this request. This item is kept for history and does not need to be reopened.

  10. ryoppippi
    added
    triage:resolvedResolved by a later change or current implementation.
    on Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    triage:resolvedResolved by a later change or current implementation.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions