Who publishes this
Voxgig publishes these pages and makes one of the tools compared on them. The sources are linked on every page so the claims can be checked against the vendors' own documentation.
Scope and method#
Eight generators, one page each, all following the same shape: what the tool is, what it does that Voxgig does not, a side-by-side table, the cases each tool suits, and the limits of the comparison.
The axes are licensing and ownership, language and framework targets, what the tool generates besides an SDK, how customizations survive regeneration, what cross-cutting behavior comes built in, and how it is priced. Those are the differences that tend to decide the choice; the pages state them and leave the weighting to the reader.
Facts on every page were last checked on . Voxgig publishes these pages and makes one of the tools compared. The six rules below describe how they are sourced and corrected.
How these pages are written#
Six rules every page follows. A page that breaks one is a defect; corrections are below.
Capabilities, not verdicts
Each page describes what a tool does and what it does not do. Where the two tools differ, the difference is stated and the reader decides which side of it they are on. No tool is scored, and no overall winner is declared.
No asterisks in the table
If a tool has a feature, the table says it has it. No partial ticks and no footnoted almosts. Where a row would need a paragraph to be accurate, it is a paragraph in the page instead of a row in the table.
Dated facts, first-party sources
Every page carries the date its facts were last checked and links the vendor's own pages, including their comparisons of Voxgig. Pricing and tier limits move fastest, so the pages describe the shape of the pricing and link the vendor for the numbers.
Sources are named, including their limits
Claims come from published documentation, public repositories of generated output, and direct use. Each page's caveats say which, and name what has not been tested. No generator here has been benchmarked against a large specification.
Corrections are made and dated
A correction changes the page and moves its checked date. Corrections from maintainers and other vendors carry the most weight, because they come from the people with the best information about the product.
The field at a glance#
The coarse version. Every row is a page, and the detail that usually decides the choice does not fit in a table.
| Tool | What it is | Licence | Languages | Cost |
|---|---|---|---|---|
| Voxgig | Open-source generator, six output surfaces | MIT | 22 bundled, more from packages | Free |
| OpenAPI Generator | Open source, community governed | Apache 2.0 | 40+ client, 20+ server | Free |
| Speakeasy | Commercial, CLI plus platform | Proprietary | About 10, plus Terraform | Free tier, then paid per language |
| Fern | Open-source CLI, commercial docs platform | Apache 2.0 plus commercial | 9 | Free to generate, paid docs |
| Stainless | Commercial, winding down | Proprietary | 9, including Terraform | No longer sold |
| APIMatic | Commercial platform and portal | Proprietary | 7 | Low entry tier, then paid |
| liblab | Commercial, pipeline focused | Proprietary | 6, plus Terraform | Tiered subscription |
| Kiota | Open source, from Microsoft | MIT | 8, at varying maturity | Free |
| Hey API | Open source, TypeScript only | MIT | TypeScript | Free |
Language counts are targets a tool ships, not a quality measure: a target existing says nothing about how well it is maintained or how idiomatic its output is. Voxgig's 22 is the number of language targets the generator bundles, listed in its README.
The comparisons#
Eight tools, one page each: what it is, what it does that Voxgig does not, a side-by-side table, the cases each tool suits, and the limits of the comparison.
OpenAPI Generator
The community generator most APIs have shipped an SDK from at least once. Apache 2.0, community governed, and broader than everything else here put together: 40+ client languages, 20+ server frameworks, plus docs, Postman collections and Protobuf. Breadth is the whole point, and the cost of it.
OpenAPI Generator and Voxgig, comparedSpeakeasy
Commercial SDK generation with the widest non-SDK output in this comparison. A closed-source generator behind a CLI you run in your own CI, sold per language. Generates Terraform providers and MCP servers as well as SDKs, and expresses customization as OpenAPI Overlays rather than a private config format.
Speakeasy and Voxgig, comparedFern
SDKs and a documentation site from one definition. Part of Postman since January 2026. An Apache 2.0 CLI and generator set with a commercial hosted documentation platform on top. Takes OpenAPI, AsyncAPI, gRPC and OpenRPC, or its own definition format, and is the best integrated docs and SDK story in this comparison.
Fern and Voxgig, comparedStainless
The generator behind many of the best-known AI SDKs. Its hosted product is winding down. Stainless generated the official client libraries for OpenAI, Anthropic, Cloudflare and several hundred other providers, and set the quality bar this whole field now aims at. Anthropic acquired it in May 2026 and is winding down the hosted generator.
Stainless and Voxgig, comparedAPIMatic
The longest-running commercial generator here, and the only one that converts between description formats. SDKs in seven languages, a developer portal, spec validation, and API Transformer, which converts API descriptions between more than fifteen formats. The lowest entry price of the commercial tools on this site.
APIMatic and Voxgig, comparedliblab
SDK generation shaped as a release pipeline. Part of Postman since November 2025. Commercial SDK generation whose centre of gravity is publishing rather than generating: version, changelog and push packages to npm, PyPI, Maven and NuGet on every spec change. Acquired by Postman in November 2025.
liblab and Voxgig, comparedKiota
Microsoft's client generator, built so you do not need a separate SDK per API. MIT, from Microsoft, and pointed at the other side of the API. Kiota is for the team calling somebody else's API, with one shared HTTP stack and fluent request builders across every API you consume.
Kiota and Voxgig, comparedHey API
The TypeScript ecosystem's generator. One language, done properly. MIT, TypeScript only, millions of weekly npm downloads. A plugin architecture that generates exactly what you ask for: types, a client, Zod schemas, TanStack Query hooks. On TypeScript specifically it is the more specialised tool.
Hey API and Voxgig, comparedWhat the decision usually turns on#
Five questions, and only one of them is about generated code.
- Who owns the generator. A vendor tool means a subscription, a roadmap and someone to escalate to. An open-source generator in your repository means maintenance you take on yourself. Both are workable; the failure mode is not noticing the choice was being made.
- How many languages will actually ship. Two makes per-language subscription pricing cheap; seven makes it the largest line on the invoice. The relevant count is what customers will ask for in two years, not what exists today.
- What happens on the fortieth change to your API description. This is where hand-written and AI-written SDKs stop being comparable to generated ones. It is also where a generator that cannot preserve your customizations starts costing more than it saves, because every regeneration becomes a merge you supervise.
- Whether agents need to call your API. An MCP server generated from the same description as the SDK cannot drift from it; a hand-written one drifts on the next release. Of the tools compared here, Speakeasy and Voxgig generate one. Stainless did too, and its hosted generator is winding down.
- What happens when the vendor is bought. In the ten months to May 2026, three of the tools on this page changed hands: liblab to Postman in November 2025, Fern to Postman in January 2026, and Stainless to Anthropic in May 2026, with its hosted generator closing to new projects the day it was announced.
The risk of choosing Voxgig#
Question five applies to Voxgig as well.
Voxgig Ltd is a small independent company trading since 2018, with no external owner and no support contract on offer. If development stopped, the generator is MIT on npm and GitHub and the generated code is already in the consuming repository, so builds continue and regeneration continues. What stops is development: the result is a generator nobody is maintaining, which is a different position from a hosted generator being switched off, and not the same as nothing changing.
A smaller project also means a smaller community: fewer answered questions in public, fewer engineers who have hit a given edge case before, and a lower chance that a new hire has used it. A commercial vendor offers a support contract and an SLA against that.
What Voxgig does not do. No Terraform provider target, which Speakeasy and liblab have. No hosted documentation platform, which Fern has. No package publishing to registries, which liblab does. No server stubs, which OpenAPI Generator generates. 22 language targets against OpenAPI Generator's list of roughly four times that. And a smaller company than every commercial tool compared here.
The wider field#
Tools without a page of their own, with a line each. A tool is here rather than above either because it solves an adjacent problem, or because there is not enough direct experience of it here to compare it in detail.
- Swagger Codegen The ancestor of most of this field, still maintained by SmartBear. OpenAPI Generator forked from it in 2018 and took most of the community. Worth knowing which one you are actually running, because plenty of build files still say this one.
- AutoRest Microsoft's older generator, built around Azure's needs and still used across the Azure SDKs. Superseded by Kiota for general client generation, and a lot of production code depends on it.
- NSwag The .NET ecosystem's long-running toolchain: C# and TypeScript clients, plus server-side specification generation from ASP.NET controllers. Generating the description from the code rather than the other way round is a legitimate workflow that none of the tools above serve.
- openapi-typescript and openapi-fetch Types straight from the specification, plus a tiny typed fetch wrapper. Not really a generator: no client class, no features, almost no output. For a lot of TypeScript projects that is exactly the right amount of tool.
- orval and Kubb Two more TypeScript generators aimed at frontend data layers, with React Query, SWR and MSW mock output. Same territory as Hey API, different opinions about it.
- openapi-python-client A single-language generator for Python that produces markedly more idiomatic output than a general-purpose tool aiming at forty languages. The same argument Hey API makes for TypeScript, made for Python.
- Progenitor Oxide's Rust generator, emitting a client as a procedural macro or a build step. Narrow, sharp, and the reference for what generated Rust should look like.
- Smithy AWS's protocol-agnostic interface definition language, designed for code generation rather than adapted to it, and the model behind the AWS SDKs. The closest thing in the industry to Voxgig's semantic model argument, arrived at independently and at a much larger scale. It converts to OpenAPI, so it can feed the tools above.
- TypeSpec Microsoft's language for describing APIs concisely and emitting OpenAPI, Protobuf and JSON Schema from one definition. Solves the same authoring problem as Fern Definition, in the open, with an emitter model. Increasingly the front end other people's generators are pointed at.
- Sideko and Konfig Smaller commercial entrants in the same shape as Speakeasy and Fern: SDKs plus documentation, per-seat or per-language. For any vendor of this size, including Voxgig, check it is still trading before building a release pipeline on it.
- Buf and Connect If your API is gRPC or Protobuf, generation is already the normal way of life and the toolchain is mature. Worth knowing that the whole argument on this site, that clients should be generated from a machine-readable description, was settled years ago in that world.
A tool missing from this list? Send it.
Corrections#
These pages describe other vendors' products, and those products change.
Prices change, features ship and roadmaps move, so a page accurate on its checked date goes stale on its own. Corrections are the mechanism for that.
Mail the address below, or open an issue if a public record is preferable.
What is useful in a correction: the page, the sentence, what is wrong, and where the correct answer is published. A link to first-party documentation settles it fastest. Objections to the framing rather than the facts are equally welcome.
What happens next: the claim is checked against the published source, the page and its checked date are updated, and the sender gets a reply saying what changed. A correction that is not accepted gets a reply saying why.
Maintainers and vendor teams especially. Corrections from the people who build the product carry the most weight, because they come from the best available information about it.
FAQ#
Who publishes these pages?
Voxgig, which makes one of the tools compared. Every page carries the date its facts were checked and links the vendor's own documentation, including their comparisons of Voxgig, so the claims can be checked at source.
How do you decide which tools get a page?
Any tool a team could reasonably shortlist alongside Voxgig, weighted by how often it comes up. Licence, company size and commercial model do not affect that. Tools solving an adjacent problem, and tools there is not enough direct experience of to describe in detail, get a line in the wider field instead.
A page is wrong about my tool. What happens if I tell you?
Send it to info@voxgig.com or open an issue on the generator repository. The most useful correction names the page, the sentence, what is wrong and where the correct answer is published. A correction changes the page and moves its checked date.
Do you benchmark the generated code?
No. Claims come from published documentation, public repositories of generated output, and direct use, and each page names which of those it is drawing on. No generator here has been run against a large specification and its output diffed against the others.
Why does the Stainless page exist if the product is winding down?
Because a large number of published SDKs were generated by it, and their maintainers need an account of what changed and what the options are. Several conventions the field now works to, including standardised streaming and auto-pagination, were normalised there.
What is the fastest way to decide without reading all of this?
Three questions. How many languages will actually ship, because per-language subscription pricing is cheap at two and expensive at seven. Whether agents need to call the API, because an MCP server generated from the same description as the SDK cannot drift from it. And what happens if the vendor is bought, because three of the tools here changed hands in the ten months to May 2026.
Read the generated code#
The generator is MIT, and the catalog holds 600+ generated SDKs readable without installing anything.