Alright AE folks, let’s test a long comp in Copernicus. All effects are done inside a single file. Rendering 380 frames in MPlay took 40s on the first pass (no caching), averaging ~10 fps. Not bad! (Spoiler: could’ve been faster imho, ran into a few hiccups). It didn't run out of memory, and no crashes either.
Making effects in Copernicus is a blast. Easy to build, and it flies if you do it right. Super easy to set up and flies if done right. Tinkering with it is pure joy, and finding new ways to utilize nodes is highly satisfying. If you’re into AE, you should definitely give Copernicus a shot. Sure, there are few ready-made complex effects, but it's a reason to build them yourself and see how they work, right?
Quick lifehack: to bypass slow rasterization in animation, just rasterize the required attribute once and drive it via remap. Works like a charm for curves and can even do the trick for geometry. And of course, don’t forget to regularly bring up the cache manager with Shift+Alt+M (a huge thank you to the devs for making it so 'convenient') and clear the caches.
Highly recommend.

There are also some issues that showed up quite strongly:
Time Dependency Leaks.
The main problem is time dependency leaks. As the number of nodes grows, they start recooking even when they theoretically shouldn’t, and it’s hard to understand why. Leaks happen even through Time Shift and Switch nodes.
There’s also strange behavior with heavy subnets: inside a subnet (on the last node with the display flag) I get 24 FPS, but outside, on the subnet itself, it drops to 10–15 FPS, even though the other subnets are completely unrelated. If I delete the other subnets, performance returns to 24 FPS. It seems that the sheer number of subnets (or nodes inside them) already slows down composition assembly just by existing.

Compile Blocks.
I expected compile blocks to collapse the graph and improve performance, but in most cases they significantly tank the FPS. SOP/rasterize nodes (Font, Curve, etc.) should never be placed inside a block — they constantly recook. There were cases where a Rasterize was completely cut off by a Switch outside the block, yet enabling compilation still caused that external Rasterize to start recooking.
Even with regular nodes, adding a block often cuts FPS by 20–30%. Because the contents of the block are collapsed, they don’t show up in the Performance Monitor, making troubleshooting almost impossible. In the end I had to completely abandon compile blocks.

Cache Node — Feature Requests.
Short Cache Range: Currently the Cache node caches everything. If I only need a 50-frame range, I have to build workarounds with Switches and Nulls, otherwise it eats gigabytes of RAM. A built-in range limit would be very useful. Also, $F doesn’t work for filtering in Time Pack, and it constantly recooks the incoming “rasterize geo” even when caching only a few fixed frames. In its current state it’s not really usable as a cache.
Compressed Cache: Would it be possible to store packed data (like PNG) and decompress only the current frame? It would be slower, but far more RAM-efficient and better than manual disk caching.
Manual Time Dependency Toggle: A way to manually break time dependency. For example, a Switch with the condition $F > 200 currently forces the entire chain to recalculate for all 300 frames instead of cooking just twice.

Native Time Clipping
Time Shift is convenient for shifting clips coming from nodes, but to avoid unnecessary recooks of heavy clips it’s better to clip them so that frames outside the range become empty. Having this control natively would be great.

So, starting with build 457, `$F` now works in the Cable Unpack node (kudos to the developers). This allows us to retrieve a local cache from the Time Pack. The Time Pack itself still triggers recooking, but this can be bypassed by adding a 1-frame cache node after it (an entirely unnecessary step in my view, but it works). Now, we can fetch and insert our cache at any point on the timeline. If you strip out the names beforehand and keep only the indices, the Cable Unpack setup becomes incredibly simple—just $F-Nframes — and it runs instantly. This opens up some interesting possibilities.
Yes, Copernicus is the real deal.

Gaalvk
Short Cache Range: Currently the Cache node caches everything. If I only need a 50-frame range, I have to build workarounds with Switches and Nulls, otherwise it eats gigabytes of RAM. A built-in range limit would be very useful. Also, $F doesn’t work for filtering in Time Pack, and it constantly recooks the incoming “rasterize geo” even when caching only a few fixed frames. In its current state it’s not really usable as a cache.

Similar to the SOP Cache Node with the "Cache Any Frame" turned off?

If cooked outside the range, you'd expect it to just cook through, or are you not cooking outside the range?

Is the goal to allow you go hit the "Reload Playbar Range" without grabbing 240 frames, but only 50?

What I meant was that we have an animation that becomes very heavy within a narrow frame range—for instance, because an effect radius is being animated or there’s a stamp point affecting a large number of vertices. It slows down significantly between frames 100 and 130, while the rest is manageable. It makes sense not to cache the entire timeline, but only the 30 frames starting at 100, using "passthrough" for the frames before and after.
In my current test, I see that the switch with frame limits correctly toggles between the main stream and the cache, caching only the specified range. Honestly, I’m not sure why it didn't work when I was assembling the full composition—back then, the cache kept ballooning to its maximum size. Maybe I just got confused or missed something obvious. I’ve set up an HDA with the switch to keep things clear; let's see how it performs in practice.
With the switch setup, the "reload" function isn't applicable, of course, but I don't think that’s a major loss for such short ranges. We can consider that the problem with a small cache has been solved, although it may not be obvious to most. And thank you for your attention to the problem.