Repository navigation
Conversation
The reader requested one page of account events at a time. Cursor caps a page at 1,000 events and takes about a second to answer one, so a busy account spent most of a minute here before Usage could show anything. Keep up to six pages requested ahead of the one being consumed. Pages are still consumed in page order, so the read ends as it did before, and any request still in flight is cancelled when it does. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a focused optimization of the existing Cursor history fetch path, adding bounded six-page concurrency while preserving page order, result handling, timeouts, and cancellation. The accompanying tests cover ordering, concurrency, failures, authentication responses, and cleanup, with no product-default or static-analysis changes. Notes:
You can add or adjust custom eligibility rules. Learn more. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: pingdotgg/t3code/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthrough
ChangesCursor usage pagination
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Refactor Sequence Diagram(s)sequenceDiagram
participant Caller
participant Reader as readCursorAccountUsage
participant Page as readPage
participant Cursor as Cursor API
Caller->>Reader: Read account usage
Reader->>Page: Request up to six pages ahead
Page->>Cursor: Fetch usage page
Cursor-->>Page: Return page response
Page-->>Reader: Return validated events
Reader-->>Caller: Return events in page order
Suggested reviewers: Merge Risk: ⚪ Minimal · up to The change accelerates Cursor usage retrieval while preserving ordered results and cancelling outstanding requests. No actionable merge-blocking risk remains beyond normal checks. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 1 system. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
What Changed
The Cursor account history reader now keeps up to six pages requested ahead of the one it is consuming, instead of requesting each page only after the previous one returned.
Pages are still consumed strictly in page order, so the count check, boundary-overlap reconciliation, the terminal-page rule and the "Sign in to Cursor again" result behave exactly as they did page by page. When the read ends for any reason, requests still in flight are cancelled.
The existing loop body became
readPagewith no changes inside it; the new code is the loop that drives it. 23 changed lines outside tests.Why
Usage waits for every source before it shows anything, and on a busy Cursor account this reader is nearly all of that wait.
Cursor caps a page at 1,000 events (larger sizes return 400) and takes about a second to answer one regardless of size. A 30-day window with 36,479 events is 37 requests, which were made one after another.
A trace from a live server recorded a 60.9 s usage load with 60.6 s of it inside
UsageService.collectDirs. On the same machine the warm Claude, Codex, Grok and OpenCode scan takes about 0.4 s. 60 s is also this reader's deadline, past which Cursor history is dropped for that load.#10409 verified the reader against 118 Cursor records, which fit in one page.
I looked for a way to avoid paging. The dashboard CSV export is a single request but took 38 s and has no conversation ids, the aggregated endpoint does not reconcile with the event list, and the Admin API is Enterprise-only.
Validation
cursorUsageReader,usageTranscriptReaderandUsageService; formatting, targeted lint and the server typecheck pass.Usage still waits for Cursor before showing the local providers. This shortens that wait; it does not remove it.
Checklist
Implemented and verified with Claude Opus 5.5 through the Claude Code harness.
🤖 Generated with Claude Code