Skip to content

Anthropic Acquires Stainless: What It Means & How to Adapt

Anthropic just acquired Stainless and is shutting down hosted SDK tools. Here's what changes for developers and the migration path you should take now.

6 min readBeginner

The #1 mistake developers are making right now: treating the Anthropic acquires Stainless news like a press release to skim, then doing nothing. If you generated SDKs through Stainless’s hosted service – even indirectly, through a vendor whose API client came from there – you have a narrow window to export, fork, and decide your next move before the hosted workflow you depended on is gone.

This isn’t a panic post. It’s a checklist. Anthropic announced the acquisition on May 18 and is winding down hosted Stainless products – but customers keep the SDKs they already generated. Below: what actually changed, the exact commands to run this week, and an honest comparison of where to land next.

What Anthropic actually bought (and what got shut off)

The deal: over $300 million, per The Information – roughly double Stainless’s $150 million December 2024 valuation. Stainless was founded in 2022 by Alex Rattray, a former Stripe engineer, and backed by Sequoia and Andreessen Horowitz. The interesting part isn’t the price. It’s the customer list.

TechCrunch confirmed that Stainless’s customers included OpenAI, Google DeepMind, Perplexity, Groq, and Cloudflare. Anthropic just bought the SDK factory its biggest competitors were using. All hosted Stainless products – SDK generator included – are winding down. New signups, projects, and SDKs are already unavailable. Existing customers still own what they generated and can modify it freely.

So three things are true at once: your generated code keeps working, the pipeline that maintained it is closing, and a key piece of Anthropic’s announcement is that the Stainless team will now focus on the Claude Platform.

The core concept: SDKs, MCP, and why this matters for anyone using Claude

Think of an SDK as the wiring between your code and an API. Without it you’re writing raw HTTP calls and handling auth, retries, pagination, and streaming yourself. Rattray built software that turned API specs into production-ready SDKs across Python, TypeScript, Kotlin, Go, and Java – and the platform kept those SDKs current as APIs changed.

97 million monthly SDK downloads by March 2026, 10,000+ public servers – that’s the scale MCP reached before this acquisition closed (per R&D World). Anthropic created MCP in 2024 and later open-sourced it. Stainless was one of the few vendors that could mass-produce MCP server connectors at quality. Absorbing that capability internally makes the acquisition strategic – not just a talent grab.

Worth knowing: If you’re building agents on Claude, the long-term story here is probably good news – tighter SDK-to-API coupling means faster feature rollouts. Building on OpenAI or Google and you were using Stainless? The story runs the other way. Plan accordingly.

Step-by-step: what to do this week if you used Stainless

1. Locate your generated SDK repos

Turns out the stainless-sdks GitHub org is where most of your repos live by default – check there first. Confirm you have admin access, clone everything locally as a backup, and don’t wait. If Anthropic eventually deprecates that org, the fork-and-own window is now.

2. Install the Stainless CLI locally – while it still works

The hosted dashboard is winding down. The CLI (as of May 2026, per the official Stainless CLI docs) is what you’ll use for local regeneration:

brew tap stainless-api/tap
brew install stl
stl auth login
stl init

From there, stl preview builds the project against your local OpenAPI spec and Stainless config, then opens a TUI with build progress, diagnostics, and workflow links. Test it on a non-critical project first.

3. Export your Stainless config to your own repo

Here’s the gotcha tutorials aren’t telling you. Stainless uses two inputs to generate an SDK: your OpenAPI spec and a Stainless config. On first generation, it creates an initial draft of that config using an LLM. Re-init from scratch without exporting your existing config and the regenerated draft may quietly diverge from what’s actually shipping in production. Pull the current config out of the hosted environment before it’s gone.

4. Pin your SDK versions in downstream projects

If your app imports the generated SDK, pin it to a specific version in package.json / pyproject.toml / go.mod today. No surprise updates while you sort out long-term tooling.

Common pitfalls people are already hitting

The CLI is experimental. Full stop. The official quickstart says it plainly: “Please feel free to use it, but do not use it as a part of automated scripts as the structure may change over time.” Docs say experimental – but most coverage points to “use the CLI” without flagging this. Fine for manual regeneration. Risky for CI.

The second trap is governance. Generated MCP servers ship fast, but Forrester analyst Biswajeet Mahapatra warned in InfoWorld about what happens when teams hit a button and ship connectors at volume: auth gaps, no monitoring, unclear who owns the endpoint six months later. If that was your workflow, add a checklist – auth model, rate limiting, ownership – before each release. One leaked endpoint from a mass-generated connector is worse than a week’s delay.

And the cynicism check: Hacker News reactions were mixed. Some developers called it a straightforward, if aggressive, business move. Others weren’t charitable – “Why else sunset the SDK generator service but to hurt any other company who relies on these for their SDKs?” Take that as a signal to diversify your tooling, not an assumption that Anthropic will maintain a free pipeline for its competitors.

Comparison: where Stainless customers should go next

No perfect drop-in exists. The right choice depends on what you actually need.

Option Best for Catch
Keep generated SDKs, freeze them APIs that change infrequently You inherit all maintenance manually
Local Stainless CLI (stl) Solo devs, manual regens Experimental; not for CI
OpenAPI Generator / Speakeasy / Fern Teams needing hosted automation Output quality and language coverage vary; migration work required

Scale check: in 2024, Cloudflare used Stainless to ship over 1,000 endpoints across three language SDKs. If your team is anywhere near that volume, manual maintenance isn’t viable – evaluate a hosted alternative before your next major API release.

One detail that didn’t make most coverage: Rattray named the company after stainless steel pipes – “Quality fittings for your REST API” was the original motto. Whatever vendor you land on, that’s still the bar.

FAQ

Will my existing Stainless-generated SDKs stop working?

No. The code keeps running. What stops is the hosted workflow that regenerates and maintains it.

Should I migrate off Stainless if I’m building specifically for Claude?

Probably not urgently. The Stainless team is now inside Anthropic, which means SDK updates will track the Claude API more closely – for Claude-first teams, that’s a tighter feedback loop, not a weaker one. The higher risk sits with teams building on OpenAI or Google who were relying on Stainless. They lost their vendor with no direct replacement lined up.

Is the local Stainless CLI a long-term answer?

Bridge, not destination. It’s experimental – the docs say so – and not safe to script. Use it to keep moving while you evaluate alternatives. Don’t build a new CI pipeline on top of it.

Your next move: open a terminal, run brew install stl, log in, and pull a test regeneration of one non-critical SDK before the end of the week. Twenty minutes of that beats any amount of reading about it.