# Stainless and Voxgig, compared

> 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 aims at. Anthropic acquired it in May 2026 and is winding down the hosted generator. Published by Voxgig, which makes one of the two tools. Facts checked 28 September 2026.

**Status.** 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.

## What it is

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.

## Facts

- Made by: Stainless, acquired by Anthropic in May 2026
- Status: Hosted products winding down
- License: Generator proprietary. Generated SDKs Apache 2.0
- Language targets: 9, including Terraform
- Site: `stainless.com` (https://www.stainless.com)

## What Stainless does that Voxgig does not

### Output quality as the entire product

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.

### The config layer, separated from the spec

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.

### MCP servers and docs from the same config

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.

### It set the conventions the field works to

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.

### A config format that has outlived the service

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.

## Side by side

| | 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 |

## One API, two SDKs

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.0`](https://github.com/muxinc/mux-ts). The Node SDK Mux publishes on npm, generated with Stainless. The same release is also published as `@mux/ts`.
- Voxgig: [`voxgig-sdk/mux-sdk`](https://github.com/voxgig-sdk/mux-sdk). Built 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. Source: https://www.mux.com/api-spec.json

### What each SDK does

| | 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 |

### What the code is

| | 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. `@mux/mux-node 15.3.0`:

```ts
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')
```

`voxgig-sdk/mux-sdk`:

```ts
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' })
```

### What building and running both found

- Both SDKs got all four steps right against the definition's own examples. Against generated data, Stainless's load and remove failed on IDs that made invalid path segments, and the mock gave Voxgig an empty page to list, so each SDK is credited with its better run.
- Stainless auto-paginates 21 list methods with `for await`. Voxgig carries page state between calls and has no iterator, so walking every asset is a loop you write.
- Voxgig's `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.
- Voxgig's create type is the Asset response. It has no `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](https://github.com/voxgig/sdkgen/issues/215)).
- sdkgen sent every match field as a query parameter too until 4.31.0, so a Voxgig load asked for `/video/v1/assets/asset_123?id=asset_123`. On 4.32.1 a path parameter stays in the path.

The full scorecard, with the evidence for every row: https://github.com/voxgig-sdk/mux-sdk/blob/main/COMPARISON.md

## Choose Stainless when

- For new work you cannot: the hosted generator stopped taking projects on 18 May 2026.
- If you are an existing customer, the SDKs you have generated still work and you still own them. Nothing is revoked, nothing phones home, and there is no deadline on the code itself. Read the transition guidance before you do anything drastic.
- If your API is stable and your SDKs are finished, freezing them and maintaining them by hand is a perfectly reasonable plan. It is not the plan a generator vendor would suggest, but for a slow-moving API it is sometimes the cheapest one.
- If the SDK is Python, stainful reads an existing `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.

## Choose Voxgig when

- You want regeneration back, running from your own repository, with no account and no vendor in the path. That is the specific failure mode you have just lived through, and it is the one Voxgig is built to not have.
- You want the generator itself readable and forkable, so a future acquisition is somebody else's problem rather than yours.
- You want an MCP server generated beside the SDK from the same model, which is where a lot of Stainless-shaped API businesses are heading anyway.

## Limits of this comparison

- Every generator makes different naming, module layout and pagination decisions. Moving a published SDK from one to another changes your customers' code. Any move needs a major version and a migration note rather than a patch release. That applies to a move to Voxgig as much as to any other tool.
- This page is published by a vendor whose product competes for the same customers. The primary facts are in Anthropic's and Stainless's own announcements, linked below.
- Anthropic's statements are the authority on what happens next to Stainless customers. Anything here is a summary of them as of 28 September 2026.
- The SDK pair is one API, compared in TypeScript against a mock of its definition. Mux published that SDK on 23 September 2026 and its code still sends Stainless's headers, so at least one existing customer was still shipping Stainless-generated releases four months into the wind-down. How long that lasts is Anthropic's to say.

Corrections go to info@voxgig.com. A correction changes the page and moves its checked date.

## First-party sources

- [Stainless's announcement](https://www.stainless.com/blog/stainless-is-joining-anthropic)
- [stainless.com](https://www.stainless.com)
- [The openai-python library, generated by Stainless](https://github.com/openai/openai-python)

## The other comparisons

- [All SDK generator comparisons](https://voxgig.com/sdk/comparisons): the index, the method, and the wider field.
- [OpenAPI Generator](https://voxgig.com/sdk/comparisons/openapi-generator): The community generator most APIs have shipped an SDK from at least once.
- [Speakeasy](https://voxgig.com/sdk/comparisons/speakeasy): Commercial SDK generation whose generator became AGPL-3.0 open source in September 2026.
- [Fern](https://voxgig.com/sdk/comparisons/fern): SDKs and a documentation site from one definition. Part of Postman since January 2026.
- [Cloudflare Forge](https://voxgig.com/sdk/comparisons/cloudflare-forge): Cloudflare's open-source generation pipeline, published on 28 September 2026.
- [APIMatic](https://voxgig.com/sdk/comparisons/apimatic): The longest-running commercial generator here, and the only one that converts between description formats.
- [liblab](https://voxgig.com/sdk/comparisons/liblab): SDK generation shaped as a release pipeline. Part of Postman since November 2025.
- [Kiota](https://voxgig.com/sdk/comparisons/kiota): Microsoft's client generator, built so you do not need a separate SDK per API.
- [Hey API](https://voxgig.com/sdk/comparisons/hey-api): The TypeScript ecosystem's generator, with a Python generator in early development.
- [Voxgig SDK Generator](https://voxgig.com/sdk)