Stainless alternatives: What to use now that the SDK generator is shutting down

If you've been following developer tooling news, you've probably seen the reaction on Hacker News to Anthropic's acquisition of Stainless. The comments are telling: teams are asking whether to stay, what the roadmap looks like, and whether now is the time to find something they actually own. Anthropic has already confirmed it will wind down all hosted Stainless products, including the SDK generator.

It's a fair question. SDK generation is infrastructure. You don't want it controlled by a vendor whose incentives may no longer align with yours, let alone a competitor.

This post looks at your options and makes an honest case for why the open-source path is now the most compelling one.

Why SDK generation is hard to get right

An SDK is not a typed wrapper around HTTP calls. At minimum it needs to autopaginate resources, retry with jittered backoffs, exchange auth tokens transparently, surface errors as the language's native exception type, and give callers compile-time confidence that request shapes are correct.

Multiply that across six or seven target languages, each with its own naming conventions, type systems, package managers, and definition of "idiomatic," and you have a genuine maintenance problem. If you're handwriting those SDKs, every new endpoint means updates to seven repositories. Drift is not a risk; it's a guarantee.

That's the problem Stainless was built to solve. It did it well, but it did it as a black box. You accepted their opinion about what your SDKs should look like, and you paid for the privilege.

The alternatives

1. OpenAPI Generator

The original open-source option. Supports dozens of languages and has been around long enough to be battle-tested. The tradeoff is output quality: generated code is functional but rarely idiomatic. If you care about the developer experience of the SDK itself (and you should), OpenAPI Generator usually requires significant post-processing or customization.

Good for: getting something working fast with no budget.Not great for: teams who care about idiomatic output or maintaining a consistent SDK style.

2. Speakeasy

A commercial alternative to Stainless. Strong output quality, good language coverage, and actively developed. If you want a managed, turnkey experience and don't have appetite to maintain your own pipeline, Speakeasy is the most direct like-for-like swap.

Good for: teams that want to stay on a managed platform and switch vendors.Not great for: teams that want to own their generation logic or have strong opinions about output style.

3. Fern

Another managed SDK generation platform with a focus on clean, consistent output. Fern has its own IDL on top of OpenAPI and a strong TypeScript-first approach. Worth evaluating if you're primarily a TypeScript shop.

Good for: TypeScript-heavy teams who want polished output without building their own emitters.Not great for: teams that need deep customization or already have strong SDK conventions.

4. Build your own pipeline with oagen

This is the option that the Hacker News reaction is making more attractive by the day.

oagen is an open-source framework built and used in production by WorkOS for building custom SDK generators from OpenAPI 3.x specs. It is not a turnkey generator. It is a framework for building your own, and that distinction matters.

Here's how it works:

1. oagen parses your OpenAPI spec into a clean, fully-resolved intermediate representation (IR). All the $ref chains, schema composition, and OpenAPI quirks are handled once, centrally.
2. Emitters consume that IR and produce idiomatic code for a target language. You write the emitter; oagen gives you the clean data to work with.
3. When your spec changes, the pipeline reruns and every SDK stays in sync.

The IR is the key insight. Rather than passing raw YAML to a code generator, you get a normalized, typed data model of your API surface. A Python emitter knows an optional query parameter is a keyword argument with a None default. A Go emitter knows it's a pointer field on a struct. Those aren't template substitutions; they're real decisions encoded in the emitter.

WorkOS documents this approach in detail in "Handwritten SDKs Are Dead", written by the engineer who built oagen. The short version: they maintain seven SDKs across Node, Python, Java, .NET, Go, and Ruby from a single OpenAPI spec. Adding an endpoint means updating the spec. Every SDK gets it at once, with consistent behavior, consistent error handling, and consistent docs.

When oagen is the right call

If you want a turnkey generator with batteries included, look at Speakeasy or Fern. If you don't want to maintain emitter code, oagen adds work, not removes it.

But if your API is a core product and not an afterthought, and you care about:

• Owning your generation pipeline with no vendor dependency
• Idiomatic output that matches your SDK conventions exactly
• AI-assisted generation within a tightly scoped, consistent system
• Long-term stability without exposure to pricing changes or acquisition risk

then oagen is for you. The framework is stable, actively developed (v0.21.0 as of this writing), and the .claude/ configuration in the repo gives you a practical template for how to use Claude as a constrained generation partner, not a free-form code generator.

The bottom line

The Stainless acquisition is a good forcing function. If you were relying on a managed SDK platform without thinking hard about the lock-in, now is the time to think hard about it.

The open-source path requires more upfront investment. But it gives you something no vendor can: a generation pipeline that is yours, that encodes your conventions, and that evolves on your timeline.

oagen is on GitHub. The IR is documented, the emitter interface is minimal, and there's a reference emitter to get you started.

If you're evaluating alternatives, it's the most interesting thing in this space right now.