This manuscript introduces a new microwave forward model implemented in Python, PyRTlib. The tool has a relatively narrow scope compared to some existing radiative transfer programs and is brought forward as an educational tool. On the other hand, it has some unique features that are of scientific interest.

As a start, I would suggest putting less emphasis on “educational” (is an educational tool even inside the scope of GMD?). If having education as the main aim, it should be shown that the tool has pedagogical advantages, i.e. how it facilitates learning compared to what can be achieved with other software. As far as I can see, educational is here more or less equal to the second aim of being user-friendly (page 7).

There are two possible target audiences: the students and younger scientists, the “newbies” expected to be the users of PyRTlib, or the teachers and advisers of those users (and there could even be old scientists that master Python and would use PyRTlib in their work!). The manuscript in its present form seems to have both audiences in mind but is not meeting the full expectations of any of them. It could be possible to handle both audiences in parallel, but it is probably best to target one of them. The most reasonable choice seems to prioritise teachers, advisers and scientific use. Targeting newbies would likely result in a too low scientific level for a journal article, and they will primarily look for information in the user guide. However, I fully understand that it is not possible, or even preferred, to have a strict separation between “science” and documentation. Here, a pragmatic approach must be allowed. To be useful, the journal article must contain aspects of documentation, but it should be on a relatively high level, such as the general principles of the software’s design.

The choice of units is an example of general principles. The only way to determine the chosen units is if the example codes clarify them. Please add a table or explain if they are found in the user guide. If the units are selected according to some guidelines (using the ones typically found in atmospheric models?), that would be helpful to know. Further, is there a strategy when importing data? Are the units kept from the original data source or converted to standard units? Taking the function IGRAUpperAir as an example, where do I find out what variables it returns and their unit? The example codes show that the user must employ unit conversions. This is error-prone, and I question whether this aligns with a user-friendly tool.

It would be helpful to explain the organisation of the documentation. Where do I look for different types of documentation? The existence of a user guide should be mentioned in the introduction and referred to in the text.

Another missing piece of information is how altitude and observation angle are specified. Please note that it needed to specify an altitude for satellite observations if Eq. 7 is applied. It is the radius of the instrument that sets the constant.

I suggest using some tables for better clarity. It is mentioned that “intermediate RT variables” can be accessed, but the exact set is unclear. This information would be suitable for a table, then including units of these variables. A table would also help get a quick overview of the absorption models. Here, I recommend including the reference matching the implementation to avoid confusion.

The results in Figure 7 give confidence in PyRTlib, at least for the two absorption models used. Has there been any comparison between PyRTlib and other forward models? Or internally, comparing the different absorption models? This provides no validation against reality but is the fastest way to detect possible bugs.

Section 5 outlines extensions. This brings up the issue of the software version. The manuscript must be linked to a specific version. This likely requires a plan to “versionify” the software and document changes between each version.

Exploring the modelling uncertainty is novel and highly useful and should be better covered by the manuscript. Some open questions here:

• Is there an uncertainty estimate for exactly all parameters affecting absorption cross-sections? If not, what parameters are covered?
• Is it possible to extract these uncertainties and their covariance?
• How are the parameter uncertainties mapped to Tb uncertainty? Just perturbations or a more advanced approach? Can the full covariance matrix of Tb uncertainty (the information required for OEM retrievals) be obtained?

I have not tried to install and run PyRTlib. Neither have I cared about minor language issues in detail.

Various comments:

• Why is radiative transfer written with capital R and T in the title? Even if alluding to PyRTlib, this causes more confusion than help.
• The review of forward models is nice but makes the Introduction long. Place in an appendix?
• Line 152: AMSUTRAN is only used for the microwave region, not all fast parameterisations.
• Line 156: Geer et al (2017) not the best reference here; better is gmd.copernicus.org/articles/14/7497/2021/gmd-14-7497-2021.html
• Line 194: Not all observation geometries are handled by a plane-parallel model; limb sounding can not be represented.
• Line 231: As Eq 2 is written, s is the distance from the observation point, not the propagation distance.
• Eq 4: Not correct to use = here. Consider this also for Eq 5.
• Line 268: The value 99% is irrelevant (with this thinking, nitrogen should be the dominating absorber).
• Line 291: It is not very clear what has actually been implemented.
• Lines 291-292: Why is this model optional? This implies that the other models are mandatory. Is this model just applied at freezing temperatures?
• Eq. 7: Does including refraction for a plane-parallel model make sense? Is it not more important to include the Earth’s curvature than refraction? Is including Eq. 7 actually an improvement when applied in a plane-parallel model?
• Eqs 8-12: Why this level of detail here? Sticks out compared to other parts. And refraction is of relatively minor concern for the model.
• Sec 3.1: Are there any issues with quality and missing data when reading from the Wyoming archive?
• Around here, it becomes clear that the radiative transfer part takes RH as input. Is this a good choice? For freezing temperatures, RH can also be defined with respect to ice. There is a lack of agreement between parameterisations of RH with respect to liquid for freezing temperatures. A user can think that if she/he imports data in RH all is fine, but there is an uncertainty in the mapping from RH to absolute humidity due to two points raised above.
• Example codes: One or two example codes are motivated to exemplify how the program is used in practice. The extra examples contribute relatively little (basic things such as the import of packages and plotting get repeated, taking unnecessary space). For the rest, refer to the user documentation.
• Line 556: “Nicely” is vague, and not really true (there are apparent deviations from the 1-1 line).
• Fig. 7: PyRTlib does not apply any bandpass. Can this not be relevant for this comparison?

The manuscript is relevant for GMD but requires revision before publication. The text needs better to introduce the actual forward model and its documentation. On the other hand, the background and overall motivation for developing PyRTlib could be shortened (not to extend the length of the manuscript). Some of my comments question design choices. Take these comments as input for discussion and reflection, and not as a demand for making changes to the code at this point.

This paper documents a new, Python-based radiative transfer model. This is a welcome addition to the radiation modelling toolkit that is indispensable for weather/climate modelling and remote sensing applications. I would recommend the authors address the following issues, mostly minor, in revision.

A main comment is that as the model is advertised for education, the model package and the paper can be configured to present more diverse and illuminating examples. Currently it’s focused/limited to radiance (brightness temperature). Instead of (or in addition to) the input processing, which the paper has talked much about, it would be of more pedagogic value to have examples of computation and diagnosis of different quantities, such as Jacobians, optical depth, weighting function, etc. One heuristic case to showcase the ability of the model may be the logarithmic dependence of monochromatic radiance (Huang & Bani, https://doi.org/10.1002/2014JD022466), which would involve radiance simulation and differencing to verify the phenomenon (log dependence) and involve optical depth and weighting function to understand/explain the phenomenon.

Eq 2-5: better to formulate and explain the equations for a slant path, to disclose more fully the parameters that need to be set for the model to run. It would also be better to include necessary description for limb view cases, which the model is said to handle too.

Eq. 6: this concerns the treatment of path inhomogeneity, which is a very general problem in radiative modelling. Better to have some reference and discussion of the rationale of the weighting choice made, i.e., based on transmission, optical depth, or mass.

Line 277: parameterization of absorption is core to any radiation model, which is probably covered too briefly here. For education in particular, such essence as state (temperature, pressure, etc.) dependences of line strength and broadening should be reviewed for the concepts as well as for related computing modules.

Line 286: this is another place where I find the information is too brief. It would also be good to outline plans for cloud property parameterization and multiple scattering radiative transfer solver.

The paper can use some editing assistance for English, e.g., Line 56: “allow to” => allows consideration of …; “dishomogeneity” => inhomogeneity