Swagger Codegen isn't officially deprecated or archived — swagger-api/swagger-codegen is still maintained, with stable releases (3.0.71 in July 2025, 2.4.46 in June 2025) and 17.8k GitHub stars, verified directly against the repo as of September 2026. But in 2018, a group of core contributors forked it into OpenAPI Generator, which has since grown larger (26.7k stars, 7.7k forks) and more active (a commit as recently as today, vs. Swagger Codegen's most recent push in mid-August). For a new project, use OpenAPI Generator. For an existing Swagger Codegen setup that still works, there's no forced migration, but plan the move before your next major language-runtime bump.
Is Swagger Codegen actually deprecated?
No, not in the formal sense. As of September 2026, verified directly against the GitHub API:
- The repository is not archived.
- It has two independently maintained version lines: 2.X (
io.swaggergroup ID) and 3.X (io.swagger.codegen.v3group ID). OpenAPI 3.0.x is supported only from the 3.X line. - Latest stable releases: 3.0.71 (July 3, 2025) and 2.4.46 (June 30, 2025).
- 17,787 stars, 5,960 forks, and a most-recent push on August 18, 2026.
- The README carries no deprecation banner and no notice redirecting users elsewhere.
So "deprecated" is the wrong word technically. "Slower-moving than its own fork" is the accurate one.
What happened: the 2018 fork
In May 2018, a group of Swagger Codegen's own core contributors forked the project into a new community-governed effort, publicly announced as "OpenAPI Generator" around early June 2018 (forked between Swagger Codegen versions 2.3.1 and 2.4.0). The stated motivation, per the contributors involved, was governance — wanting faster releases and a community-run process rather than one controlled by a single vendor (SmartBear, which owns the Swagger brand). OpenAPI Generator's own README still carries a direct migration guide today: "To migrate from Swagger Codegen to OpenAPI Generator, please refer to the migration guide," confirming it positions itself as the successor path, not merely an alternative.
Swagger Codegen vs. OpenAPI Generator today
| Swagger Codegen | OpenAPI Generator | |
|---|---|---|
| Archived? | No | No |
| Stars | 17,787 | 26,752 |
| Forks | 5,960 | 7,676 |
| Latest stable release | 3.0.71 (Jul 2025), 2.4.46 (Jun 2025) | 7.26.0 (master, as of Sep 2026) |
| Last commit activity | August 18, 2026 | September 21, 2026 |
| Version lines maintained | 2.X and 3.X, separately | Single actively-released line |
| Migration path from the other | — | Documented migration guide from Swagger Codegen |
(All figures pulled directly from the GitHub API for each repo as of September 2026.)
The gap isn't "one is dead." It's that OpenAPI Generator has more contributors, releases more often, and has spent seven years as the destination the community actually built momentum around.
When to move to OpenAPI Generator vs. a hosted service
Move to OpenAPI Generator when:
- You're starting a new SDK from scratch and want a free, self-hosted generator.
- Your team is willing to own the CI pipeline, generator templates, and per-language quirks.
- You need one of the many language targets both tools share, and want the more actively patched implementation.
Consider a hosted service (Sourced, Stainless, Speakeasy, Fern) instead when:
- You want a compatibility report that tells you what changed in the generated SDK's public surface before you publish — none of the open-source generators do this natively.
- Docs,
llms.txt, and MCP server output need to come from the same spec as the SDK, not three separate pipelines. - You'd rather approve a release than maintain a generator upgrade cadence yourself.
Honest scope
If your current Swagger Codegen 3.X setup builds clean SDKs today and nobody on your team is blocked, there's no fire to put out — it's not archived, and the 3.X line still ships stable releases. The real trigger to move is the next time you need something Swagger Codegen's slower cadence doesn't have yet: a newer language target, a fix that's already landed in OpenAPI Generator, or OpenAPI 3.1 support your validator now requires. At that point, treat it as a generator swap against the same OpenAPI spec, not a rewrite — validate the spec first, then diff the generated output against what you publish today.
Try a hosted generation pipeline
Create hosted docs and SDK previews from your GitHub repo using the same OpenAPI spec you'd otherwise point at Swagger Codegen or OpenAPI Generator — free previews, no credit card. Check your OpenAPI diff before switching generators so you can see exactly what would change in the public SDK surface. Start free.
FAQ
Is Swagger Codegen officially deprecated?
No. As of September 2026, the swagger-api/swagger-codegen repository is not archived and both its 2.X and 3.X version lines have had stable releases within the past year.
What's the difference between Swagger Codegen and OpenAPI Generator?
OpenAPI Generator is a 2018 community fork of Swagger Codegen, created by core contributors who wanted a faster, community-governed release process. As of September 2026 it has more stars (26.7k vs. 17.8k), more forks, and more recent commit activity than the original.
Should I use Swagger Codegen or OpenAPI Generator for a new project?
Use OpenAPI Generator. It's the more actively maintained of the two, and its own documentation includes a migration guide specifically for teams moving off Swagger Codegen.
Does Swagger Codegen support OpenAPI 3.1?
The project's README confirms OpenAPI 3.0.x support only from the 3.X version line, with no documented 3.1 support as of September 2026. Confirm current status directly with the project before relying on 3.1 features.
Can I migrate from Swagger Codegen to OpenAPI Generator without changing my API?
Yes. Both tools generate from the same OpenAPI spec format, so migrating is a generator swap, not an API rewrite. Diff the generated SDK's public surface against what you currently publish before switching.
Is a hosted SDK generator better than either open-source option?
It depends on what you need beyond code generation. Open-source tools generate code; hosted services like Sourced add a compatibility report, matching docs and llms.txt output, and release-readiness checks from the same spec. If you only need generated code and can own the pipeline, the open-source path is free and sufficient.