At Records.md it says that the A006988 records for 10^n-th prime were computed using primecount. However, those records (starting at 10^23) are all larger than 216289611853439384ll ~= 2.16e17, which is the maximum cutoff for the algorithm given here: https://github.com/kimwalisch/primecount/blob/master/src/nth_prime.cpp#L27

Even assuming a modified copy without that limit, the primesieve code as-is would require PrimePi(sqrt(n))*8 bytes for its sieving primes, which is PrimePi(sqrt(6.06e26))*8 ~= 6.011 TiB. (I will note that this estimate seems off however, as running primecount -n 210000000000000000 only used ~365MiB in the final sieve phase, as opposed to the expected PrimePi(sqrt(8948810122159045867))*8 ~= 1.073GiB.)

Were the records set with a modified version? If so, why is that limit in place?