One of my favorite FCI programs is the one in MRCC, because it has a few advantages over the MOLPRO FCI program (which uses the program you described in your answer).
When the entire calculation fits in memory and can be done reasonably quickly, MOLPRO's FCI program probably offers the best combination of speed and convenience (selected CI programs like Dice and Arrow can get you the same numerical energy faster, but among other issues, require you to know what you're doing in terms of checking that the selected CI convergence parameters were selected appropriately).
However, when the calculation does not fit in memory, MOLPRO doesn't offer much (or anything at all). The FCI program in MRCC will likely be a lot slower for small systems, but for large systems it will try various things to make the RAM requirements smaller, and surprisingly it can even be faster in some cases despite requiring less RAM. The reason it can be faster while still requiring less RAM, is because unlike MOLPRO which only offers CISD and FCI but nothing in between (except if you use the MRCC plug-in), MRCC calculates CISD, CISCDT, CISDTQ, CISDTQP, CISDTQPH, CISDTQPHS, CISDTQPHSO, etc. and can use the previous CI calculation to give an initial guess for the next one. Therefore CISD can be extremely fast, and then the result can be used as a starting guess for CISDT, and so on, meaning that fewer iterations are required (sometime close to zero of them, I mean, I'm sure I've seen the FCI step converge after 1 or 2 iterations because CISDTQPH was so close to being FCI, but I often worked with a small number of electrons in a big basis set rather than the other way around).
So not only can MRCC's FCI program can make adjustments for large FCI calculations so that they don't require as much memory, but the calculations can converge more quickly if they start from (for example) a CISDTQ result, and as a bonus, you also get the CI(n) energies for all values of n (which can be helpful despite those energies not being size-consistent, for example if you can't get the FCI energy but you find that CISDTQ, CISDTQP, and CISDTQPH all agree to within 1 nano-hartree, then you can be confident that you have the FCI energy despite not having enough computing power to calculate it). Additionally, I've found MRCC's FCI program to be a lot better in terms of parallelization (the MOLPRO versions I used, required a factor of N more RAM in order to run on N cores, whereas this is far from the case for MRCC). Finally, when MOLPRO's FCI calculation crashes after several iterations, I found myself simply restarting the calculation from scratch because restarts never worked as smoothly for me as they do in MRCC. In MRCC, I found restarts to be the smoothest out of all electronic structure programs I've used.
There's still disadvantages of MRCC over other programs, and one is the huge amount of disk space that it can use for temporary files. Also, the
FCIDUMP format isn't precisely followed, but I regularly convert between
FCIDUMP and MRCC's
fort.55 format, and the other way around, using the method I described in my answer to: For software that does not support FCIDUMP format, what format is used and how can we get the software to interact with FCIDUMP integrals?. MRCC isn't available on GitHub, but you can get an academic license fairly easily, which means you'll get a password which allows you to download the entire source code.
I have done a CCSDTQ calculation in MRCC involving 28,466,110,261 > 28 billion configurations (and coupled cluster calculations are far more expensive than CI ones, so you can probably imagine having close to 1 trillion FCI determinants). This calculation used 747.255 GB of RAM and 23 CPU cores (seemingly not the smartest number of cores to use, I know).
Update: For butadiene I found in 2019 that CCSDTQP for butadiene (C4H6) requires 2.4T (when using 4 cores) to treat the 781605786195 (781 billion) excitaitons, which was well within the 3TB available on some of the nodes on Cedar and Graham at Compute Canada, so I do believe 1 trillion CI determinants would not be out of the question. Unfortunately, as the comments say, MRCC is not open source though (just free and with the source available to users, but not re-distributable without permission from the Mihaly Kallay).