Published by Voxgig, which makes one of the two tools compared here. Facts checked against the first-party sources linked below. Corrections go to info@voxgig.com. Every page in this section follows the same scope and method.
Anthropic announced on 18 May 2026 that it had acquired Stainless and would wind down all hosted Stainless products, including the SDK generator. New signups, projects and SDKs stopped the same day. Stainless says customers keep the SDKs generated to date and full rights to modify and extend them, and points existing customers at a transition page. The announcement gives no end date for existing projects, and none had been published by 28 September 2026.
Stainless was a commercial SDK generation service. Its output is the most widely read generated code in the industry: the official OpenAI, Anthropic and Cloudflare client libraries, Meta's Llama Stack, Groq, Cerebras, LangChain and several hundred other providers. If you have used a modern AI API in Python or TypeScript, you have probably used a Stainless-generated SDK without knowing it.
The targets were TypeScript, Python, Go, Java, Kotlin, Ruby, C#, PHP and Terraform. Generated SDKs were licensed Apache 2.0 to the customer.
The design idea that made it work was a configuration layer sitting between the OpenAPI description and the output. The spec said what the API was. A separate Stainless config said what the library should feel like: resource naming, method names, pagination style, model names, which endpoints were promoted and which were hidden.
What that buys you is the ability to fix an SDK without touching the API description, and to keep the library's shape stable when the spec churns. It is the single most copied idea in this field. Voxgig's semantic model is a different answer to the same problem: rather than a config that adjusts the output, the model is a type-safe description of entities and operations that every surface is generated from.
Two of its best-known customers have since said what they did instead. Google wrote in September 2026 that the provider behind its Gemini SDKs was acquired and abruptly announced its shutdown in May, and co-released Speakeasy's generator as open source. Google's post does not name the provider. Cloudflare, whose public SDKs were generated by Stainless, published Forge, its own Apache 2.0 pipeline, on 28 September 2026. Both are compared on this site.
Capabilities Stainless has that Voxgig does not, in enough detail to evaluate them.
Read the openai or anthropic Python and TypeScript libraries. They read as though a careful person wrote them, although they are generated. Streaming, typed errors, request IDs, automatic pagination, retries with idempotency, per-language conventions honored rather than approximated. Those repositories are public, and they are the most detailed available reference for what generated output can look like.
Keeping library shape out of the API description is the right instinct, and it is why Stainless output looks designed rather than transcribed. It also makes the config an artifact that has to be maintained and understood, and it was proprietary. Both halves are relevant when evaluating any successor.
Stainless did not stop at SDKs. Its plans counted SDKs, documentation sites and Model Context Protocol servers as the same kind of thing, all generated from one API description and one config. It led its own marketing on the MCP output rather than treating it as an add-on. That is the same bet Voxgig makes with its six surfaces, made independently, and it is the part of the product that most deserves to be copied. An MCP server hand-written beside a generated SDK drifts on the next release, but one generated from the same source cannot.
Standardized streaming, cursor and page-based auto-pagination, typed error hierarchies, and retry-with-idempotency across every language target, at a point when most of this field had none of them. A large part of what customers expect from any SDK generator, Voxgig included, was normalized here first.
The stainless.yml that described each customer's library has become an input other tools accept. Scalar's hosted generator reads one directly, carrying resources, method names, pagination and package names across, and stainful, an MIT project from a single maintainer, generates a Python SDK from one unchanged. No other tool on this site has had its configuration adopted by its competitors as a migration format, Voxgig included; the closest Voxgig has is the OpenAPI document itself.
No partial ticks and no asterisks. If a tool has a feature, the table says it has it. Where a row would need a paragraph to be true, it is a paragraph somewhere else on this page instead of a row here.
| Stainless | Voxgig | |
|---|---|---|
| Status | Hosted products winding down since 18 May 2026. No new projects, and no published end date for existing ones | Actively developed |
| License | Generator proprietary. Generated SDKs Apache 2.0 to the customer | Generator MIT. Generated SDKs are yours |
| Language targets | 9, including Terraform | 23 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack |
| MCP server | Yes, while it was sold | Yes |
| Where the shape was decided | A proprietary config layer over the spec | A type-safe semantic model, in your repo |
| Where generation ran | The vendor's platform | Your machine |
| Regeneration after the vendor leaves | Not available | Runs from your repo with no account |
Mux publishes an SDK made with Stainless. Voxgig built one from the same definition, and both were run against a mock of that definition on the same four steps: list, load, create, and remove. Voxgig's features are in the build and stay off until a client switches them on; the rows describe them switched on. Last measured 29 September 2026.
Stainless
@mux/mux-node 15.3.0The Node SDK Mux publishes on npm, generated with Stainless. The same release is also published as @mux/ts.
Voxgig
voxgig-sdk/mux-sdkBuilt on 29 September 2026 from the same definition: eight targets from one run. A repository to build from, not a published package.
The definition: Mux's published definition, www.mux.com/api-spec.json: OpenAPI 3.1.0, 121 paths, 153 operations, Apache-2.0. Its source.
| Stainless | Voxgig | |
|---|---|---|
| Operations callable | 154 methods for the definition's 153 operations | 153 of 153 |
| Mock scenario on assets | 4 of 4 steps right against the definition's examples, 2 of 4 against generated data | 4 of 4 right against the definition's examples. Against generated data the mock's page was empty, so load and remove had no item to use |
| Retries | Two retries on connection errors, timeouts, 408, 409, 429 and 5xx, with backoff to 8 seconds | On 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After |
| Timeouts | 60 seconds per attempt by default, client-wide or per request | 30 seconds per attempt by default |
| Pagination | Auto-pagination with for await, on 21 list methods | Page and cursor state carried between calls in ctrl.paging, with no iterator |
| Idempotency keys | None. The option is declared but never set | Generated for every mutating call, and kept across its retries |
| Rate limits | 429 retried, honoring Retry-After, then a RateLimitError | A client-side token bucket, and Retry-After honored on 429 |
| Logging | Log levels from an option or the MUX_LOG variable, with auth headers redacted | Request and response logging, with auth headers redacted |
| Offline test mode | None | A mock transport seeded with your data, which the generated tests run on |
| Metrics | None | Per-operation counts and timings, with no OpenTelemetry |
| Cancellation | An AbortSignal per request | A signal stops stream() between items. Only the timeout aborts a request in flight |
| Hooks | No hook API. A custom fetch, or a subclass | Custom features that hook every stage of a call |
| Errors | A class per status: 400, 401, 403, 404, 409, 422, 429 and 5xx | One error class per SDK, carrying the HTTP status and a notFound flag |
| Stainless | Voxgig | |
|---|---|---|
| Package | @mux/mux-node on npm | Not published. You build it from the repository |
| TypeScript package size | 4.79 MB in 1,017 files | 3.60 MB in 536 files |
| Runtime dependencies | None | None |
| Languages from this build | TypeScript | TypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server |
| Shape | Resources nested by product, such as mux.video.assets, with list, retrieve, create, update and delete | 73 entities, such as Asset, which lists, loads, creates, updates, and removes assets |
| Types | Typed parameters and responses per method, nested objects included | An interface per entity, from the response schema. The create type has no inputs field and requires id and status |
| Tests | Not run here: the comparison used the published package | 658 generated TypeScript tests pass, as do the generated Go, Python, Ruby, Lua, and PHP suites |
The same calls in each, in TypeScript. Both samples type-check under strict mode against the SDK they name.
import Mux from '@mux/mux-node'
const mux = new Mux({ tokenId: process.env.MUX_TOKEN_ID, tokenSecret: process.env.MUX_TOKEN_SECRET })
for await (const asset of mux.video.assets.list()) console.log(asset.id)
const asset = await mux.video.assets.retrieve('asset_123')
const created = await mux.video.assets.create({
inputs: [{ url: 'https://example.com/video.mp4' }],
playback_policies: ['public'],
})
await mux.video.assets.delete('asset_123')import { MuxSDK } from '@voxgig-sdk/mux-sdk'
const client = new MuxSDK({ apikey: process.env.MUX_APIKEY, secret: process.env.MUX_SECRET })
const assets = await client.Asset().list()
const asset = await client.Asset().load({ id: 'asset_123' })
// AssetCreateData is the Asset response: it has no inputs field, and it
// requires id, status and created_at. Hence the cast.
const created = await client.Asset().create({
inputs: [{ url: 'https://example.com/video.mp4' }],
playback_policies: ['public'],
} as any)
await client.Asset().remove({ id: 'asset_123' })for await. Voxgig carries page state between calls and has no iterator, so walking every asset is a loop you write.Asset lists, loads, creates, updates, and removes assets, as Stainless's assets resource does. Until apidef 8.19.0 the list went through a separate ListAsset entity, named after the list response.inputs field, which is what a create sends, and it requires id and status, which the server assigns, so a TypeScript create needs a cast (voxgig/sdkgen#215)./video/v1/assets/asset_123?id=asset_123. On 4.32.1 a path parameter stays in the path.stainless.yml unchanged and generates a Python SDK from it. It was at version 0.4 on the checked date, covers Python only, and has one maintainer, so read it as a continuation path rather than a vendor. Scalar's hosted generator reads the same file and is compared in the wider field.Corrections go to info@voxgig.com or an issue on the generator repository. A correction changes the page and moves its checked date; corrections from Stainless's own team carry the most weight.
First-party sources for the claims on this page. Where they disagree with it, they are the authority.
The generator is MIT and open, and the catalog holds 600+ generated SDKs readable without installing anything.