Bitbucket REST API commits pagination: choosing page size without total count

When using the Bitbucket Cloud REST API /2.0/repositories/{workspace}/{repo_slug}/commits to iterate through a repository’s commit history, the client must rely on the pagelen and page (or start) parameters to bound each response. The API caps pagelen at 100 and defaults to 25, but it does not return a total commit count, so the caller cannot know in advance how many pages exist or when the final page has been reached.

Given the workspace‑level rate limit of 1 000 requests per hour and the desire to minimize the number of round‑trips while staying safely under that limit, the optimal page size is unclear when the total number of commits is unknown.

What pagelen setting provides the best trade‑off between request count and rate‑limit safety for an unknown‑size commit set? How should a client determine that it has processed the last page without a total count indicator? Should the client adjust pagelen dynamically based on the next link or rate‑limit response headers?