Try it online!
Or rather, some arbitrarily large variation thereof. Taken from this answer where an explanation on how it works can be found. Additionally, running this "in perpetuity" would require a version of the interpreter which does not self-halt after 1,000,000 execution steps, but I will assume this as true as the unobtaining machine the code is running on as it only requires an adjustment to one line of code.
According to TIO this can print numbers out to 100 in about 0.141s (the flux here is almost irrelevant in terms of the final result: +/- ~10 bytes for being 10 times faster or slower for needing an extra digit of precision). So reaching 99999999999999999999999999999 should take about 4,471,080,669,710,806,697
(1018) years...and ten of its most significant decimals would still be
0, which bumps things to 1028 years. Depicted code only has 39 digits worth of precision in base-10 and we can go bigger.
Only one byte different takes it to an effective base 78 (with a maximum value around 6x1073). Tweaking the "0" down to the lowest allowable character ("#") brings that to base 92 (with a maximum value around 4x1076).
That brings us to needing a 515 digit base 92 number, which is also doable using the
´ command to need only n+1 cells to represent a base 10 number with n digits (for the purposes of
write location offsets), e.g. this program changes the
4´3, and as long as an empty row of cells is supplied between the column value (~1 byte per digit for all the spaces in order to allow for 3 digit numbers) and the
10B command any value can be expressed and needing approximately 5722 bytes.
However, we can still raise the integer base a bit more.
˿ is the last non-combining Unicode value accessible without performing any additional logic checks, allowing for a base 733 number which means that we only need 353 digits of precision, reducing the program size of about 3940 bytes.
But we can still go smaller still.
35-767 is not the largest unicode block usable without needing additional logic. If we instead use Unicode values 880 to 6831 (inclusive) we have an effective base of 5953, requiring only 268 digits of precision. Accounting for the two bytes needed to represent the initial characters, that gives a program size of approximately 3275 bytes.
Adding in the additional logic would allow for a maximum base of 64654, requiring only 211 digits of precision and costing only another 79 bytes or so based on this answer.
But we can still golf a few bytes. Remember the
´ command? We don't really need it. Now that we're down to only a 211 digit number, all the values needed (up to 216) can be represented with only 2-3 bytes (instead of 5): char values implicitly convert to integers when required in any command that expects integers and nearly all the chars needed (from 5 to 216) can be utilized in this manner. Only 10, 60, 62, 94 and 118 are problematic. And all of them can still be expressed in 4 bytes or less:
10 -> a
60 -> 6X
62 -> 6X2+
94 -> 9x4+
118 -> bX8+
For 62, 94, and 118 it ends up being easier to just not use those columns. Increases program size by 8 bytes each (24 bytes) in order to not need the spaces to align the commands out to 118 (236 bytes).
Final score: 1823 bytes.
211 digit number - 1 byte per digit of initial value
Programmatic overhead - 56 bytes (roughly, the left 4 columns and right 3 columns)
Digit processing - 7 bytes * digits (1477 bytes)
Bad Character logic - ~79 bytes (some additional control flow is likely required)
(Intermediate values were approximated at 10 bytes (original program height) per digit of initial value +57 +unicode penalty where appropriate: eg. 1 byte per digit of initial value +1 or +2 for representation in programmatic overhead).
It may be possible to turn this answer into a self-repeating execution instead of a quine, but I have so far not had success getting it to
Eval properly. I suspect that it attempts to Eval the string and the parser throws an error for some reason. If that were fixed, a shorter solution to the "take forever" problem would be possible: push the quine, duplicate, Eval, compare with original (lossless). If not the same: loop, else terminate. The number of Eval attempts (i.e. the original period count) is already near the number of years required by this challenge, so increasing the number of loops by a factor of ~32 billion (iteration -> years) seems relatively doable in less than 1300 bytes. Increasing the program length from 387 "digits" to 485 "digits" looks like it would be enough.