Skip to content

Read Cursor's usage in pages of 1000, in parallel, and only since the cache - #24

Merged
lr00rl merged 1 commit into
mainfrom
fix/20261023_cursor-usage-speed
Oct 23, 2026
Merged

lr00rl merged 1 commit into
mainfrom
fix/20261023_cursor-usage-speed

Conversation

@lr00rl

@lr00rl lr00rl commented Oct 23, 2026

Copy link
Copy Markdown
Owner

Summary

Reading Cursor's usage list asked for a year of events in pages of 100, one after another, then for the billing cycle, all under a 45 s limit. Each request takes seconds, so on a ~2,000-event account a cold read hit the limit at 900 events, saved a partial list and waited five minutes before trying again.

  • Pages of 1000 events (the most the service accepts); pages after the first fetched four at a time.
  • Billing cycle and plan name asked for alongside the events and each other (also speeds up quota).
  • A full read of the year once a week; in between, only events from 48 h before the newest cached one, replacing the cached events from there on.
  • Trace callbacks serialized for the concurrent requests.

Test plan

  • go vet ./..., gofmt -l ., go test ./..., go test -race ./internal/cursorusage
  • New tests: 2,500 events in three pages of 1000, each counted once; an incremental read starting 48 h before the newest cached event without double counting; a full read again after a week.
  • Live account, same index: cold read 10.2 s with all 1,982 events (was 46.9 s, stopped at 900); stale-cache read 3.2 s, same 1,982 events and 413 conversations.

…ce the cache

Reading Cursor's usage list asked for a year of events in pages of 100,
one after another, then for the billing cycle, all under a 45 s limit.
Each request takes seconds, so on this account (about 2,000 events) a
cold read ran into the limit at 900 events, saved a partial list, and
was not retried for five minutes. The figures came from the notes in
B3010_cursor-agent and the same approach in cursor2api.

- Pages hold 1000 events, the most the service accepts, and the pages
  after the first are fetched four at a time.
- The billing cycle and the plan name are asked for at the same time as
  the events, and as each other, which also makes quota's check faster.
- A full read of the year runs once a week. In between, a read asks only
  from 48 hours before the newest cached event and replaces the cached
  events from there on, which also picks up late changes to recent ones.
- The trace callbacks are serialized, since requests now run at once.

Measured against the live account with the same index: a cold read
takes 10.2 s and gets all 1,982 events (it took 46.9 s and stopped at
900); a read after the cache goes stale takes 3.2 s and ends with the
same 1,982 events and 413 conversations.
@lr00rl
lr00rl merged commit bc79f15 into main Oct 23, 2026
2 checks passed
@lr00rl
lr00rl deleted the fix/20261023_cursor-usage-speed branch October 23, 2026 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant