Notifications
Clear all
Topic starter
04/06/2026 6:44 pm
TL;DR: Anthropic's acquisition of Stainless is forcing teams to re-evaluate hosted SDK generation, vendor dependency, and whether they need owned pipelines instead of black-box tooling, according to WorkOS. The lock-in question is now operational, not theoretical: if your API is core product infrastructure, the generation path has to survive vendor change.
NHIMG editorial — based on content published by WorkOS: Stainless alternatives and what to use now that the SDK generator is shutting down
Questions worth separating out
Q: How should teams decide whether to keep a hosted SDK generator?
A: Teams should keep a hosted SDK generator only if they can tolerate roadmap dependence, reproduce the output if needed, and accept that the vendor may change ownership or priorities.
Q: Why does SDK generation become a governance issue after an acquisition?
A: An acquisition can change the incentives behind a hosted generator, which turns a technical dependency into an organisational risk.
Q: What breaks when an SDK generator is a black box?
A: Black-box generation breaks reproducibility, makes debugging harder, and increases the chance that output quality drifts across languages.
Practitioner guidance
- Map SDK pipeline ownership Document which parts of your SDK generation flow are hosted, which are reproducible, and which depend on provider-specific behaviour.
- Test vendor exit scenarios Run a short transition exercise that asks how quickly you could replace a hosted generator without rewriting language-specific clients from scratch.
- Separate generation quality from feature count Evaluate whether the SDK output is idiomatic enough to avoid wrappers, custom patches, and forked maintenance.
What's in the full article
WorkOS's full post covers the operational detail this post intentionally leaves for the source:
- A practical comparison of OpenAPI Generator, Speakeasy, Fern, and oagen for teams choosing a new generation path.
- The oagen intermediate representation and emitter model, including how it keeps seven SDKs aligned from one spec.
- The tradeoff between turnkey managed generation and owning the pipeline logic yourself.
- The specific reasons the author sees open-source generation as the more durable path after the acquisition.
👉 Read WorkOS's analysis of Stainless alternatives after the acquisition →
Stainless alternatives after the acquisition: what should teams choose?
Explore further
04/06/2026 6:55 pm
Vendor-controlled SDK generation is a lifecycle problem, not just a tooling choice. Hosted generation platforms create a dependency that teams often treat as interchangeable until ownership changes. Once acquisition enters the picture, the real issue becomes whether the organisation can still govern its own interface lifecycle, not whether the vendor's product was convenient. The practitioner lesson is that SDK generation belongs in the same ownership conversation as other critical machine-facing infrastructure.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Teams also report an average of 6 distinct secrets manager instances, which fragments control and weakens central visibility.
A question worth separating out:
Q: What should platform teams do before switching SDK generation approaches?
A: Platform teams should inventory their OpenAPI pipeline, identify language-specific customisations, and confirm whether they can regenerate every client from a single source of truth. If not, they should expect migration work, release risk, and documentation cleanup.
👉 Read our full editorial: Anthropic's Stainless acquisition and the future of SDK generation
