Performance: statusline/daily commands timeout with large data directories (~750 files, 4GB)

Description

The ccusage statusline and ccusage daily commands timeout when processing a Claude Code data directory with many session files.

Environment

ccusage version: 18.0.5
OS: Arch Linux (kernel 6.6.87.2-microsoft-standard-WSL2)
Installation: System package from AUR
Node: via system ccusage binary

Data Metrics

~/.claude/ size: 4.3GB
Number of .jsonl files: 749

Steps to Reproduce

Have a Claude Code data directory with ~750 jsonl files totaling ~4GB

Run any of these commands:

ccusage statusline  # via stdin with proper JSON input
ccusage daily
ccusage daily --since $(date +%Y%m%d)
ccusage daily --offline

All commands timeout (tested with 30s timeout)

Expected Behavior

Commands should complete within a few seconds, especially:

ccusage daily --since <today> should only process today's files
--offline mode should be fast (no network calls)
statusline should be very fast for status bar integration

Actual Behavior

Commands hang indefinitely. Debug output shows config loading completes, then processing stalls:

[ccusage] ℹ Debug mode enabled - showing config loading details
[ccusage] ℹ Searching for config files:
[ccusage] ℹ   • Checking: /path/.ccusage/ccusage.json (not found)
[ccusage] ℹ   • Checking: /home/user/.claude/ccusage.json (not found)
[ccusage] ℹ No valid configuration file found
[ccusage] ℹ No config file loaded, using CLI args only for 'daily' command
<hangs here>

When not using --offline, after ~25s it prints:

[ccusage]  WARN  Fetching latest model pricing from LiteLLM...
[ccusage] ℹ Loaded pricing for 2455 models
<continues hanging>

Impact

statusline integration is unusable for users with significant Claude Code history
Must use wrapper scripts with aggressive timeouts as workaround

Possible Causes

Reading all 749 jsonl files upfront instead of lazy/streaming
No early exit when date filters could skip files
No file-level caching to skip unchanged files

Workaround

Using a wrapper script that calls ccusage statusline with a 1s timeout and falls back gracefully:

ccout=$(echo "$input" | timeout 1 ccusage statusline 2>/dev/null)
if [ $? -ne 0 ]; then
    # fallback to basic status without cost info
fi

@ryoppippi

After exploring the repo, I found these PRs that directly address this issue:

PR perf(ccusage): add timestamp cache for faster file processing #766 - Timestamp cache: 28.2s → 8.4s (70% faster) for 8600+ files
PR feat: add intelligent file caching and time-based filtering for statu… #623 - File caching + time filtering: 18s → 0.6s for 216MB data

Both have been open for months. Would love to see one of these merged! 🙏

cc @ryoppippi

My case is even bigger. I have a session opened so big node crashes trying to read it. The reading process should be donde in streams...

ccusage daily

 WARN  Fetching latest model pricing from LiteLLM...                                                                                                                      ccusage 5:56:23 PM

ℹ Loaded pricing for 2477 models                                                                                                                                         ccusage 5:56:23 PM
node:internal/fs/promises:540
    throw new ERR_FS_FILE_TOO_LARGE(size);
          ^

RangeError [ERR_FS_FILE_TOO_LARGE]: File size (2415830827) is greater than 2 GiB
    at readFileHandle (node:internal/fs/promises:540:11)
    at async loadDailyUsageData (file:///usr/local/lib/node_modules/ccusage/dist/data-loader-CzOPffdg.js:3621:20)
    at async Object.run (file:///usr/local/lib/node_modules/ccusage/dist/index.js:4303:21)
    at async executeCommand (file:///usr/local/lib/node_modules/ccusage/dist/index.js:1122:2)
    at async cli (file:///usr/local/lib/node_modules/ccusage/dist/index.js:1034:2)
    at async file:///usr/local/lib/node_modules/ccusage/dist/index.js:5110:1 {
  code: 'ERR_FS_FILE_TOO_LARGE'
}

Node.js v22.21.1

@aldoeliacim

@aldoeliacim @LuisGMM
I ran into similar issues - ccusage was consuming too much resources for statusline integration.

Ended up building a Rust-based alternative called toktrack.
It uses simd-json + rayon for parallel processing, so resource usage stays minimal

~0.04s for 4GB / 3000+ files
Low memory footprint (no Node.js/V8 overhead)
Might work as a workaround while waiting for a fix toktrack

It has JSON output (toktrack daily --json) so you could pipe it to a custom statusline script if needed.

(Not affiliated with ccusage - just sharing what solved it for me)

The current Claude loader no longer reads whole JSONL files with readFile. It uses marker/line streaming plus worker-based loading, and applies since/minUpdateTime mtime filtering. The statusline path also uses update-time filtering for today and active-block loads. The main causes reported here, large JSONL files, many files, and the 2GB file crash, are resolved on current main. Further speed work should be tracked in #922 as per-file caching.

Navigation Menu

Repository navigation

Performance: statusline/daily commands timeout with large data directories (~750 files, 4GB) #821

Description

Environment

Data Metrics

Steps to Reproduce

Expected Behavior

Actual Behavior

Impact

Possible Causes

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Performance: statusline/daily commands timeout with large data directories (~750 files, 4GB) #821

Description

Description

Environment

Data Metrics

Steps to Reproduce

Expected Behavior

Actual Behavior

Impact

Possible Causes

Workaround

Activity

aldoeliacim commented on Jan 23, 2026

LuisGMM commented on Feb 4, 2026

mag123c commented on Feb 11, 2026

ryoppippi commented on May 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions