I recommend steering clear of this project entirely - if you really care use something like gRPC instead. Every time I've used it, it has failed spectacularly t

I recommend steering clear of this project entirely - if you really care use something like gRPC instead. Every time I've used it, it has failed spectacularly to generate models as promised and I've had to write the clients by hand anyway. There are just far too many bugs in the respective language generators and it all seems to fall apart when you start using anyOf, oneOf, etc. It only takes a quick stroll of the issues to find that many features of OpenAPI aren't supported in certain generators, so it's a total waste. I do still like OpenAPI as a design tool and it produces very human readable documentation as well, so it's still useful if you intend to only use it just for that. Just keep your expectations very low when it comes to generation. Edit: I forgot to mention that clients are subject to breakage if you change the names of models - model names are not actually a part of the contract in my opinion - only the protocol aspects should be (path, params, body, etc.). I don't see how they would solve this but it's a major pain. If you imagine writing a client yourself, it would not break if you tweaked a model name, so this is a huge downside. I have a scenario where the model names are only there for branding (a numerical enum that has a human readable model name), but are now being hardcoded into the spec in a way I didn't want. I really didn't want to give the models generic, unreadable names in the docs but that seems to be what OpenAPI wants me to do.