Stability of Datasmith runtime

From my experience using Datasmith Runtime, I’ve noticed that it can be unstable at times—possibly due to its reliance on local port-based communication. This approach, while dynamic, may be introducing inconsistencies or performance issues, especially in larger or more complex scenes.

I’d like to propose an alternative or complementary approach:
Implementing a local file system-based cache, similar to how some engines and renderers manage persistent data. For example, a global cache folder (e.g.,
C:/ProgramData/DatasmithRuntime/Cache) could be used to store mesh data (triangles), materials, shaders, etc.

While this method might be slightly slower than pure runtime communication, it would improve stability and repeatability, especially for applications like architectural visualization where accuracy and fidelity are prioritized over speed. In such workflows, reusing cached, verified assets is often more desirable than real-time asset conversion.

Ideally, there could be a user-configurable option to choose between:

Fast runtime (port-based) loading
Stable, cache-based loading (file system-backed)

This would give developers and architects flexibility to prioritize what matters most for their specific use case—speed or accuracy.

Would love to hear thoughts from the community or Epic team on whether such a feature could be considered in future versions.