The paper by Hartung et al. describes a new library that is developed to couple external software, ranging from Python diagnostics to ESM components, to the ICON model. The article provides an extensive description of the ComIn library’s capabilities, underlying motivations and an overview of potential applications that can benefit the ICON community. I think the paper is well structured, providing necessary details to describe the ComIn library and the reasoning behind the software design. I recommend  this article for a publication in GMD, however some minor comments should be addressed.

Specific comments:

* L187-193: Could you specify in which cases plugins are executed asynchronously? Is this possible for couplers and I/O servers when used as plugins through ComIn v0.1.0 or do these tasks also rely on blocking callbacks such as for synchronous plugins?

* The authors cautiously point out that plugin implementation and the use of additional resources to run plugins are the user’s responsibility. Indeed, synchronous execution of a plugin can pause the ICON model for quite some time for a computationally inefficient plugin, which is indicated in the manuscript. On the contrary, the article does not really show evidence of efficient execution of ICON/ComIn for an “efficient plugin” (e.g. a simple monitoring Python script to generate a map or compute a mean field value). A test with ComIn disabled in ICON-NWP is described and shows that the ICON/ComIn implementation introduces very little overhead for ICON, which is an important result to stress. But the current test runs do not show the impact of activating ComIn for ICON. An additional testcase would be desirable to show how much of a typical ICON timestep is spent on running a fast plugin.

* L255: Compatibility between the ICON-ComIn versions is verified by ComIn but what about the ComIn-plugin(s) compatibility? Does the software development process guarantee API backward compatibility so that plugins can be used with newer versions of ICON/ComIn? If not, do users need to develop several versions of a plugin depending on the ICON version in use?

* Sect 3.4.2: It can be complex for a Python script developer to work with ICON data produced on an unstructured grid in a parallel setup. Providing data post-processing functionalities (or at least guidelines on how to proceed) would improve the user experience and facilitate ComIn adoption. Does ComIn provide functionalities (through its API or as plugin examples) to reconstruct fields globally and to regrid fields on the target grids of plugins? Could you clarify how plugin developers should work with ICON data provided by ComIn? Sect 5 provides a valuable list of possibilities offered by the library but lacks details on how users should proceed.  

* L438-441: Prototyping with Python to develop parametrizations would first require a translation of the Fortran code into Python. This may not be straightforward, considering that the two programming languages handle efficient array computations very differently. It is unclear why switching languages would speed-up the model development process, not to mention the optimization process which can only be carried out in the model’s native language. Nevertheless, I wonder to what extend parametrization development could rather benefit from ComIn when carried out in Fortran and outside the model, given that the library provide access to input/output parametrization fields and separate program build.

* L459-462: Opening up the possibility of using or developing Python packages (AI, ML, …)  to emulate parametrized processes should be of interest to the ICON community. I think this point should be put forward instead of L438-441.

* L434-437: The purpose of the evaluation and performance analysis referred to here is unclear. Do you employ the mentioned tools (a sentence to describe these tools is missing) to monitor the use of computing resources for the simulation job (computing time, memory usage, …)? Or do you intend to compute relevant metrics to analyze physical phenomena of the simulation (perhaps in the form of timeseries)? Could you also clarify the statement “a well set-up simulation does not need to be restarted after evaluation”?

* L160-167: You could add a statement emphasizing that the interface library approach depends mainly on the model data structure and the model execution flow.

* L185: Could you explain on how the dynamical loading works in ComIn? Does it require usage of specific dependency management tools and other libraries that were not previously part of ICON-NWP?

* L225: The goal of limiting software maintenance effort (ICON, ComIn) is a valuable one and this is mentioned several times. Could you provide an estimate of the number of lines added to ICON in response to the inclusion of ComIn v0.1.0? Or perhaps provide the fraction of lines of code that were modified/added for ComIn into ICON relative to the ICON codebase?

Minor comments:

* L16: host model model -> host model?

* L66: from each of these process -> processes?

* L478: you may want to add a definition or link for CMOR

* L507: adapted -> adopted?

The article details a plugin functionality added to the ICON model, based on a common adaptor library to be used by both the ICON model and the plugins. Entry point hooks are inserted in the ICON model to execute the plugins at various places.

The authors introduce the concepts in a structured manner comparing all possible approaches to extend models with external components. The described code is open-source and readily available to explore, including documentation and examples. Various conceivable scenarios are considered in how plugins operate with the given ICON data fields.

The article fits well in the context of this journal and is of high quality. I therefore recommend it for publication.

One question. Given that it is possible for plugins to share the data pointers with ICON, is there an optional safety mechanism provided (e.g. by checksumming the data)  in order to ensure or verify that no data has been modified inadvertently?