during training where possible, as there may be subtle changes to the source code affecting the prediction. In cases where published methods require specific library versions that conflict with the molscore Python environment or must be consistent with those used during training (currently, AiZynthFinder and RAscore ), scoring function scripts are run as a subprocess from their respective conda environment with the dependencies as specified by the authors. In order to improve user experience, molscore will check for these separate conda environments and if not present, attempt to create them automatically when the scoring function is used for the first time. However, there are several caveats to this approach, the first being the assumption of the use of conda for environment management, and the second being computational performance decrease. The performance decrease is because running a scoring function via a subprocess requires redundant loading of the relevant conda environment, redundant loading of scoring function parameters and I/O operations to send SMILES and receive respective scores via writing and reading to disk, each time. This suboptimal process adds to the overall wall time when using molscore which is negligible in the case of long running scoring functions like AiZynthFinder , but sub-optimal when using fast running scoring functions like RAscore . In future versions of molscore, we will move to running methods with conflicting/specific library dependencies as local servers to avoid redundant operations and send/receive data in memory instead, which will improve computational performance and overall software stability.