AutoRest: an OpenAPI client generator that is being retired on July 1, 2026

What AutoRest generates, and who still needs it

AutoRest is a code generator. Its input is a specification that describes a REST API in the OpenAPI Specification format, and its output is a client library for accessing that service. The repository ships a set of language generators covering C#, PowerShell, Go, Java, Node.js, TypeScript, Python and Swift, and the core pipeline lives in packages/extensions/core with the modelerfour stage in packages/extensions/modelerfour.

The audience is narrow and getting narrower. If you maintain a service whose OpenAPI document is already wired into a generation pipeline, AutoRest is the tool that produced the clients your users import. If you are writing a new API today, the README points elsewhere: it states that AutoRest is deprecated, that it will be retired on July 1, 2026, that no new features, language generators or plugins will be added, and that TypeSpec is the recommended successor. The last push to the repository was on 2026-09-13, but the deprecation notice governs how you should read that activity.

A practical consequence: the value of AutoRest to you is now mostly about the code you already have, not the code you are about to write.

How the pipeline turns a spec into a client

The architecture is a pipeline of npm packages rather than a single binary. The autorest package is the command-line entry point. @autorest/core holds the core functionality, and @autorest/modelerfour converts OpenAPI input into a common code model. That model is defined in @autorest/codemodel, and generators consume it to emit source files.

Several internal packages support the stages. @azure-tools/openapi handles OpenAPI reading, @azure-tools/oai2-to-oai3 converts older documents, @azure-tools/datastore stores intermediate artifacts, and @azure-tools/deduplication trims repeated schema definitions. @autorest/configuration and @autorest/extension-base provide the plugin contract, which is how a language generator plugs into the core.

The important design point is that generators are versioned separately from the core. The package table in the README lists @autorest/csharp, @autorest/go, @autorest/java, @autorest/powershell, @autorest/python, @autorest/swift and @autorest/typescript as distinct packages, and the source links for the language generators point at separate repositories such as autorest.csharp and autorest.typescript. Upgrading the core does not automatically upgrade the generator you actually use, and the generator is where most of the generated code's shape is decided.

That separation is also the main source of version skew. A pipeline pinned to an old generator will keep producing old code even after the core moves.

Installing AutoRest and generating a first client

AutoRest is distributed through npm. The README lists the autorest package as the command-line tool, and the monorepo's package.json declares that the workspace requires Node.js 22 or newer and uses pnpm 10.34.1 as its package manager. The monorepo engines field is about building the repository itself; installing the published CLI is a normal npm install.

Install the command-line tool globally so the autorest command is on your path:

npm install -g autorest

Once it is installed, the autorest command is what you invoke. The repository's Samples directory contains input documents to try against, including Samples/openapi-v2 and Samples/openapi-v3, and Samples/readme.md describes the sample layout. The README does not spell out the exact flag names for a generation run, so check the generator package's own documentation for the input and output options it accepts. The README also does not document rollback or a dry-run mode, so generate into a directory you can delete and diff rather than over an existing tree.

Expect a package with models, operations and a client class. The exact file names depend on the generator package version, which is why pinning matters more here than in a single-binary tool.

Where AutoRest is the wrong tool

The clearest failure mode is starting fresh. The README states that AutoRest is no longer under active development and that no new features, language generators or plugins will be added. A team that builds a new generation pipeline on it in 2026 is building on a component with a stated retirement date of July 1, 2026.

The second limitation is version coupling. Because the core and each language generator are separate npm packages with their own release cadence, a working pipeline is a set of pinned versions that must move together. The recent releases listed for the repository are core releases, with autorest-core-2.0.4432 dated 2025-12-17, autorest-core-2.0.4430 dated 2025-06-16, and autorest-core-2.0.4429 dated 2024-03-30. That cadence is slow, and it says nothing about whether the generator package you depend on has moved at all.

The third case is a spec that does not fit the model. AutoRest consumes OpenAPI documents, and the README describes the input as a spec in the OpenAPI Specification format. If your API description is written in TypeSpec, the README's own recommendation is to use TypeSpec's generation platform rather than routing through AutoRest. Choosing AutoRest for a TypeSpec-first workflow is working against the documented direction.

Finally, if you only need a thin HTTP wrapper and not typed models, a generator adds a build step and a dependency surface that a hand-written client would not.

AutoRest compared with OpenAPI Generator and NSwag

The two comparisons people search for most are AutoRest vs OpenAPI Generator and AutoRest vs NSwag, and the difference is mostly in how the generator is structured rather than in what it emits.

OpenAPI Generator is a single project that bundles many language targets behind one release. AutoRest splits the core pipeline from the language generators, which are published as separate npm packages and, for the languages in the README table, developed in separate repositories. The practical difference is upgrade granularity: with AutoRest you can move the core and leave a generator pinned, but you also have to track two version streams. With a bundled generator you move everything at once and inherit any regressions across all targets.

NSwag is aimed at the .NET ecosystem and combines client generation with tooling around ASP.NET. AutoRest's C# support lives in @autorest/csharp, a separate repository, and the core itself is language-neutral. If your work is entirely inside .NET, NSwag keeps generation and the surrounding tooling in one place; if you need the same spec to produce C#, Python and TypeScript clients from one pipeline, AutoRest's modeler-plus-generator split is the reason the project exists.

The comparison that matters most right now is not against either of them. It is against TypeSpec, which the README names as the recommended successor. That is not a like-for-like swap: TypeSpec is an API description language and generation platform, so moving to it can mean rewriting the description, not just changing a command.

Licence, maintenance and upgrade cost

The repository is licensed under MIT, and the monorepo package.json carries the same MIT identifier. MIT is permissive: it allows use, modification and redistribution with the licence text preserved. Generated client code is a separate question from the generator's licence. Whether generated output inherits any notice requirement depends on the generator package and its templates, and the README does not state a policy for generated files, so check the individual generator repository before shipping. This is a description of the licence text, not legal advice.

Maintenance cost has two parts. The first is the deprecation clock: the README states retirement on July 1, 2026, and the tracking issue is listed at github.com/Azure/autorest/issues/5175. The second is the version matrix. Because core, modelerfour and each language generator are separate packages, an upgrade is a coordinated change across pinned versions, and the release history shows core releases spaced months apart. Plan for the migration to TypeSpec as the real upgrade path, not as a later cleanup.

Editorial conclusion

Adopt AutoRest only if you are maintaining existing generated clients or need a language generator from the monorepo, and confirm your target generator is still published before you commit. Do not start a new API surface on it, because the README states no new language generators or plugins will be added and retirement is set for July 1, 2026. Before adopting, check the npm page for the specific generator package you need, since the generators live in separate repositories such as autorest.csharp and autorest.typescript.

Frequently asked questions

Official sources

1. Azure/autorest on GitHub
2. Issues
3. License: MIT
4. README
5. Releases