@coderabbitai please review this PR. I will mention you again on every follow-up push and in review-thread replies so the review loop stays active.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

#!/bin/bash
# Fetch PR details and diff
gh pr view 1078 --repo ryoppippi/ccusage --json title,body,files,additions,deletions

echo "=== PR FILES ==="
gh pr diff 1078 --repo ryoppippi/ccusage

#!/bin/bash
echo "=== progress.rs (full) ==="
cat rust/crates/ccusage/src/progress.rs

echo ""
echo "=== adapter/all.rs (full) ==="
cat rust/crates/ccusage/src/adapter/all.rs

echo ""
echo "=== SharedArgs struct definition ==="
rg -n "struct SharedArgs" --type rust -A 20

echo ""
echo "=== has_content definition ==="
rg -n "fn has_content" --type rust -A 10

echo ""
echo "=== UsageLoadProgress::new or Default ==="
rg -n "fn new\|impl Default" --type rust -A 10 rust/crates/ccusage/src/progress.rs

echo ""
echo "=== ProgressState initialization ==="
rg -n "ProgressState {" --type rust -A 15

@ryoppippi: The changes are well-structured and correctly implement all three stated goals. Here are my findings:

rust/crates/ccusage/src/progress.rs

✅ Condvar replacement for AtomicBool + sleep

The switch from the spin-sleep pattern to Condvar::wait_timeout is correct. stop() now immediately wakes the worker via cvar.notify_all() in the common path (worker sleeping in wait_timeout).

Minor race window — there is a small window where an immediate wakeup can be missed:

Worker thread:                     stop() thread:
  state.lock() → render → drop     
                                   lock.lock() → *is_running=false → notify_all() → drop
  lock.lock()
  cvar.wait_timeout(...)  ← notification already sent; must wait full 80 ms to time out
  checks !*guard → break

If stop() fires between the worker's state lock release and the worker's lock.lock() for the condvar, the notify_all is sent before wait_timeout is entered and the worker will sleep up to one full SPINNER_INTERVAL (80 ms) before checking the flag. In practice this window is tiny and 80 ms is imperceptible, but it means the "wakes immediately on stop" guarantee is probabilistic rather than strict. A check-before-wait pattern would close the gap:

// After acquiring `guard`, check the flag before entering wait_timeout:
let Ok(guard) = lock.lock() else { break; };
if !*guard { break; }  // ← close the race window
let Ok((guard, _)) = cvar.wait_timeout(guard, SPINNER_INTERVAL) else { break; };
if !*guard { break; }

✅ rendered flag in ProgressState

Replacing the has_content() check in cleanup with state.rendered is strictly more correct. has_content() can be true before the first tick (state was mutated but the worker hadn't rendered yet), which would cause a spurious \r\x1b[K\x1b[?25h write to stderr. rendered only becomes true inside ProgressState::render(), meaning ANSI cleanup runs only when cursor-hide was actually emitted. #[derive(Default)] on ProgressState correctly initializes it to false.

✅ Throttling — removing state.render() from set_status / set_state

Removing the eager render() calls in set_status and set_state means all terminal writes now flow exclusively through the worker tick at 80 ms cadence. This is the core fix for bursty redraws on all-agent runs.

rust/crates/ccusage/src/adapter/all.rs

✅ loader_shared with json: true

This is a clean approach to progress suppression. Setting json: true on the per-agent SharedArgs clone causes each agent's track_usage_load call to evaluate should_show_usage_load_progress(true, …) → false, so the nested per-agent UsageLoadProgress instances are created in disabled mode and produce no output. The original shared.json is still used for wants_json() at the top of run(), so the actual output format is unaffected.

One documentation note: json in SharedArgs carries dual semantics — "user requested JSON output" and now also "suppress nested progress". Since this is an internal struct, a code comment at the loader_shared construction site would help future readers understand the intent:

// Set json: true so per-agent loaders skip their own progress output;
// the aggregate progress in load_rows owns the terminal line.
let loader_shared = SharedArgs {
    json: true,
    ..shared.clone()
};

✅ Lock ordering — no deadlock risk

stop() acquires running mutex → releases → joins worker → acquires state mutex. The worker acquires state mutex → releases → acquires running mutex. The two never hold both locks simultaneously, so there is no deadlock.

Summary: The PR is sound. The race window note above is the only substantive suggestion (and it's low-severity). The json: true approach works correctly given the current implementation boundaries. All three objectives — throttled rendering, suppressed nested loaders, and immediate stop wakeup — are achieved.

@coderabbitai I pushed a follow-up commit addressing your Condvar stop-wake race note by checking the running flag before entering the timed wait.

Validation:

• direnv exec . cargo fmt --manifest-path rust/crates/ccusage/Cargo.toml --check
• direnv exec . cargo test --manifest-path rust/Cargo.toml -p ccusage progress::tests
• pre-push oxfmt and clippy

Please review the latest push.

#!/bin/bash
echo "=== Latest commits on PR branch ==="
gh pr view 1078 --repo ryoppippi/ccusage --json commits --jq '.commits[-3:]'

echo ""
echo "=== Latest diff for progress.rs ==="
gh pr diff 1078 --repo ryoppippi/ccusage -- rust/crates/ccusage/src/progress.rs

#!/bin/bash
echo "=== Full progress.rs on PR branch ==="
cat rust/crates/ccusage/src/progress.rs

@ryoppippi The fix is correct and complete. The worker loop now implements the canonical check-before-wait pattern:

let Ok(guard) = lock.lock() else { break; };
if !*guard { break; }                                    // ← pre-wait check (new)
let Ok((guard, _)) = cvar.wait_timeout(guard, SPINNER_INTERVAL) else { break; };
if !*guard { break; }                                    // ← post-wait check

This closes the race window precisely: if stop() fires between the state-lock release and the condvar lock.lock(), the worker acquires the mutex, reads false, and exits immediately rather than sleeping up to 80 ms. The two-check structure (pre-wait + post-wait) is the idiomatic and correct pattern for condition variable loops.

Everything else from the original commit — throttled rendering, rendered flag cleanup, json: true progress suppression — is intact and unaffected. No further concerns.

(^◕ᴥ◕^)

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

ccusage performance comparison

PR SHA: c763be975783
Base SHA: ba2d04f756ca

This compares the Rust PR release binary against the configured base package on the same CI runner.

Package runner startup

Execution setup measures any pre-benchmark package materialization used by the execution benchmark. Bunx temp cache measures one bunx -p <url> ccusage --version run with an empty Bun install cache. Warm reuses that cache and reports the median of repeated runs.

Cached bunx execution performance

Runs the same large fixture through bunx -p <pkg.pr.new URL> ccusage after the Bun install cache has already been populated by the startup measurement. This separates cached package-runner execution from first-fetch package materialization.

Fixtures: Claude /home/runner/work/_temp/ccusage-large-fixture (1.01 GiB, 2,597 files), Codex /home/runner/work/_temp/ccusage-large-codex-fixture (1.01 GiB, 2,597 files)
Base package: ba2d04f756ca; PR package: c763be975783. Both run through bunx -p <pkg.pr.new URL> ccusage using the warmed Bun install cache from package runner startup, measured by hyperfine with 0 warmups and 1 runs.

Package runtime diagnostics

Compares the PR package wrapper, the installed native optional dependency binary, and the workspace release binary on the same large fixture. This identifies whether slow package results come from JavaScript wrapper overhead, the published native binary build, or the Rust core itself.

Fixtures: Claude /home/runner/work/_temp/ccusage-large-fixture (1.01 GiB, 2,597 files), Codex /home/runner/work/_temp/ccusage-large-codex-fixture (1.01 GiB, 2,597 files)
All rows run --offline --json, measured by hyperfine with 0 warmups and 1 runs. This isolates wrapper overhead from the installed native optional dependency and the workspace release binary built on the runner.

Committed fixture performance

Committed small fixtures for stable PR-to-PR feedback and explicit Claude/Codex command coverage.

Fixtures: Claude apps/ccusage/test/fixtures/claude (0.00 MiB, 2 files), Codex apps/ccusage/test/fixtures/codex (0.00 MiB, 1 files)
Base runs the published ccusage package from pkg.pr.new, installed before measurement; PR runs rust/target/release/ccusage directly. Both run --offline --json, measured by hyperfine with 2 warmups and 7 runs.

Large real-world-shaped fixture performance

Generated fixtures shaped from aggregate local log statistics: thousands of JSONL files, many small sessions, and a long tail of larger sessions. No real prompts, paths, or outputs are stored in the fixtures.

Fixtures: Claude /home/runner/work/_temp/ccusage-large-fixture (1.01 GiB, 2,597 files), Codex /home/runner/work/_temp/ccusage-large-codex-fixture (1.01 GiB, 2,597 files)
Base runs the published ccusage package from pkg.pr.new, installed before measurement; PR runs rust/target/release/ccusage directly. Both run --offline --json, measured by hyperfine with 0 warmups and 1 runs.

Artifact size

Lower medians and smaller artifacts are better. CI runner noise still applies; use same-run ratios as directional PR feedback, not release guarantees.

ccusage performance comparison

PR SHA: c763be975783
Base SHA: ba2d04f756ca

This compares the PR package against the configured base package on the same CI runner.

Package runner startup

Execution setup measures any pre-benchmark package materialization used by the execution benchmark. Bunx temp cache measures one bunx -p <url> ccusage --version run with an empty Bun install cache. Warm reuses that cache and reports the median of repeated runs.

Cached bunx execution performance

Runs the same large fixture through bunx -p <pkg.pr.new URL> ccusage after the Bun install cache has already been populated by the startup measurement. This separates cached package-runner execution from first-fetch package materialization.

Fixtures: Claude /home/runner/work/_temp/ccusage-large-fixture (1.01 GiB, 2,597 files), Codex /home/runner/work/_temp/ccusage-large-codex-fixture (1.01 GiB, 2,597 files)
Base package: ba2d04f756ca; PR package: c763be975783. Both run through bunx -p <pkg.pr.new URL> ccusage using the warmed Bun install cache from package runner startup, measured by hyperfine with 0 warmups and 1 runs.

Package runtime diagnostics

Compares the PR package wrapper, the installed native optional dependency binary, and the workspace release binary on the same large fixture. This identifies whether slow package results come from JavaScript wrapper overhead, the published native binary build, or the Rust core itself.

Fixtures: Claude /home/runner/work/_temp/ccusage-large-fixture (1.01 GiB, 2,597 files), Codex /home/runner/work/_temp/ccusage-large-codex-fixture (1.01 GiB, 2,597 files)
All rows run --offline --json, measured by hyperfine with 0 warmups and 1 runs. This isolates wrapper overhead from the installed native optional dependency and the workspace release binary built on the runner.

Committed fixture performance

Committed small fixtures for stable PR-to-PR feedback and explicit Claude/Codex command coverage.

Fixtures: Claude apps/ccusage/test/fixtures/claude (0.00 MiB, 2 files), Codex apps/ccusage/test/fixtures/codex (0.00 MiB, 1 files)
Base runs the published ccusage package from pkg.pr.new, installed before measurement; PR runs the published ccusage package from pkg.pr.new, installed before measurement. Both run --offline --json, measured by hyperfine with 2 warmups and 7 runs.

Large real-world-shaped fixture performance

Generated fixtures shaped from aggregate local log statistics: thousands of JSONL files, many small sessions, and a long tail of larger sessions. No real prompts, paths, or outputs are stored in the fixtures.

Fixtures: Claude /home/runner/work/_temp/ccusage-large-fixture (1.01 GiB, 2,597 files), Codex /home/runner/work/_temp/ccusage-large-codex-fixture (1.01 GiB, 2,597 files)
Base runs the published ccusage package from pkg.pr.new, installed before measurement; PR runs the published ccusage package from pkg.pr.new, installed before measurement. Both run --offline --json, measured by hyperfine with 0 warmups and 1 runs.

Artifact size

Lower medians and smaller artifacts are better. CI runner noise still applies; use same-run ratios as directional PR feedback, not release guarantees.