Do you still need an SDK generator?

Do you still need an SDK generator? In January 2025 I picked Speakeasy to generate Apideck's SDKs, after evaluating Speakeasy, Fern and liblab. Twenty months later, two of those belong to Postman, Speakeasy is busy selling an MCP gateway, and Stainless, which I didn't evaluate, was sold to Anthropic. A question I thought was settled is open again: do you still need an SDK generator? I had already answered it once. Before Speakeasy, our SDKs came out of the open-source OpenAPI Generator. We dropped it for high maintenance overhead and non-idiomatic code. My answer today is still yes, for the SDKs your customers import. The harder question is the licence: in 2026 no generator is free, production-ready and yours to ship under MIT. OpenAPI Generator is free and permissive, but you write the gaps yourself. What happened to the generators Postman bought liblab in November 2025, pitched as part of "an integrated platform for building AI-ready and agent-enabled APIs". Eight weeks later, on 8 January, it bought Fern and its 200+ customers, Square, Twilio and ElevenLabs among them. On 18 May, Anthropic acquired Stainless, reportedly for more than $300 million, and wound down every hosted Stainless product, the SDK generator included. Stainless generated the SDKs of OpenAI, Google and Cloudflare. They kept the code they had and lost the service that regenerates it each time their API changes. And Speakeasy, our vendor, is already pivoting. It launched an MCP Gateway, "the control plane between every AI agent and every MCP server". Its pricing page now shows a single Enterprise tier with "Tailored" pricing, lists "code mode efficiency" as a feature, and has no SDK rate card. Four of the companies that defined SDK generation have changed hands or direction. Two now belong to Postman, one was bought by an AI lab and switched off, and the fourth sells agent infrastructure. Commoditize the complement Joel Spolsky explained this in 2002, in Strategy Letter V: "Smart companies try to commoditize their products' complements." IBM published the PC's interfaces so add-in cards got cheap and more people bought PCs. Swap the PC for an API. Google and Cloudflare sell API usage, and the SDK is the complement. Look at what both did after the Stainless shutdown. On 17 September, Google and Speakeasy open-sourced Speakeasy's generator under AGPL-3.0; Google called closed generators "unacceptable platform risk". Eleven days later Cloudflare released Forge under Apache 2.0, with the line "You should own your SDKs, CLIs, and docs". Cloudflare's API has more than 3,500 operations, and the post is blunt about the motive: "We built Forge because we needed it ourselves in order to treat agents as our customers." Speakeasy's version of the play is open-core. The generator is public, the commercial licence and the gateway are what it sells. Stainless is the odd one. $300 million is not a commodity price. Anthropic paid for the team and for control, then took the hosted product away from its competitors. Where the SDK still wins Our own traffic first. Apideck processes hundreds of millions of requests a month, and when I split the traffic we can attribute by client, almost half of it still comes through an SDK. The rest is plain HTTP: axios, Go and Python clients calling the API directly. SDKs kept their users. What I can't see is who wrote that plain HTTP. A coding agent is often in the loop now, and when Claude Code or Cursor writes an integration, in my experience it often writes raw calls against the docs. Our logs can't tell an agent's code from a person's. Cloudflare can: agents were 25% of Wrangler usage in March and 48% by September. The trouble is what agents write. When researchers at TU Darmstadt had LLMs write raw HTTP integrations, GPT-4o got 60% of them fully right and the best open-source model 30%. Between 14% and 39% of the generated URLs were invalid. Constraining the model to the API spec removed every invalid URL and raised correctness by 90% on average. The study had no SDK in it, but a typed client plus a type checker is that kind of constraint. Code that looks right still breaks when it runs. In Ant Group's Alipay-PIBench, coding agents building payment integrations passed 92.79% of static checks on the basic tasks and 73.16% of integration tests. Adeel Ali, who founded the SDK generator APIMatic, put it well on 5 October: an agent writing from the docs "infers the API's behaviour afresh on each run, so its results are probabilistic." A type checker wouldn't have caught those failures. That's the case for an SDK: auth, retries and error handling that were tested before the agent arrived. Google reached the same conclusion and built it into its Gemini Docs MCP server, which "nudges agents toward using the SDKs instead of hallucinating their own integrations". Some of the plain HTTP half of my traffic may be agents writing worse integrations than they could. The options on the table If Stainless dropped you, or you're starting fresh, these are the options in October 2026. Fern, inside Postman. According to Fern's pricing, SDKs are free in Python and TypeScript up to 200 endpoints. Go, Java, C# or any other language, plus custom code, webhooks and WebSockets, means Enterprise: "per SDK, billed annually", no public price. APIMatic, the generator Ali founded. Its pricing page starts at $300 a month per language. All seven languages means the Business tier, quoted on request and capped at 100 endpoints per API. Beyond a 14-day trial there is no free tier, and the page mentions no open-source programme. Speakeasy's open generator. It's free to run, but read the licensing policy before you ship. The generator refuses to run until you elect a licence for its output. Elect AGPL-3.0 and the Speakeasy-authored code inside your SDK is AGPL; what comes only from your OpenAPI document isn't. Elect commercial and you need a token, and then "your generated SDK is yours to use, modify, distribute, and license on your own terms". Those rights are perpetual for every SDK generated while the plan was active, so leaving Speakeasy doesn't relicense what you already shipped. Most public SDKs ship under MIT or Apache, so most teams still pay. It covers eight SDK languages plus MCP servers, CLIs and Terraform providers. Forge. Apache 2.0, no strings. But the README is honest: "It's still early-days for Forge and we're laser focused on the first Forge output, the cf CLI." For now it looks built for Cloudflare first. OpenAPI Generator. Free, and the one we left in 2025. OpenAI generated its Node SDK with it before Stainless, and according to Stainless, customers complained about the "painful experiences". Just build it. An agent will write you a client in an afternoon. Keeping it correct across every API change, in every language, is the actual job, and as Ali says, "an initial working SDK provides only limited evidence" of how big that job is. OpenAI found its hand-built Python SDK "required engineering resources they didn't have". That's worth it for one client, in one language, that only you call. To pick, count the cost of ownership as complexity: the languages you ship, times the runtime features each one needs. The features are where cheap generators fall short. OpenAPI Generator's own feature table for TypeScript has no OAuth2 client-credentials flow and no oneOf or anyOf, and Speakeasy's comparison marks it without retries or pagination either. Every missing feature is code you write and maintain, in every language. The vendor's fee is fixed. Your own maintenance grows with every language, feature and API change. When only you call the client, there's only one of each. Available options - The Weekly Interface Newsletter The gap One option is missing from that list: a free, production-ready, multi-language generator whose output you can license however you want. Open-source maintainers felt it first. On 19 May, the day after the Stainless announcement, someone opened issue #2042 on Speakeasy's repo, asking for a free tier for open-source projects: "This leaves a real gap for open-source maintainers who relied on Stainless for production-quality SDK generation that includes models, types, resources, authentication, async, pagination, errors, and retries without the budget of a commercial API team." On 11 October Speakeasy closed it as completed. One reply: "We've since open sourced so this enables open-source projects to use the generator directly for free, under AGPL." That fixes the price. The licence stays: an SDK generated without a commercial plan carries Speakeasy-authored code under AGPL-3.0, so a maintainer who wants to ship under MIT or Apache, like most public SDKs, still needs the commercial token. The issue also makes a fair business case: Stainless got its brand from every developer who imported an OpenAI or Anthropic SDK and traced it back to the toolchain, and "that flywheel is now unowned". Speakeasy's AGPL answer is its bid for it, and it works against the very thing it wants to win, because that flywheel turned because developers imported those SDKs without thinking twice, into backends, mobile apps and their own libraries. Many companies won't let AGPL code in at all: Google's own policy says it "MUST NOT be used at Google", the same Google that co-released this generator under AGPL. So the free path produces SDKs that people hesitate to import. I understand why the licence is where it is: the token is what Speakeasy's customers, us included, pay for. But Speakeasy has already told us what generation is worth. Releasing the generator itself as open source is an admission that turning an OpenAPI document into a typed client is no longer a moat. What companies still pay for is everything after the first generation: keeping SDKs in step with a changing spec, catching breaking changes before release, and having someone to call when a customer's integration breaks. Charging for the output licence protects the commodity and leaves the service to sell itself. There is a well-worn way out. GNU Bison's generated parsers contain GPL code, and an explicit exception lets anyone release that output under any licence. GCC does the same with its runtime library exception. Speakeasy could add a similar exception to its generated code tomorrow and keep the AGPL on the generator, where it actually protects something. That would make it the default choice for open-source maintainers and hand it the flywheel it is bidding for. Maybe you don't need SDKs at all Resend's Zeno Rocha made the case in 2025: "Agents have the power to write their own SDKs if needed, so SDKs are less important." Agents also use CLIs (that 48% is Wrangler, a CLI), Cloudflare's Code Mode searches the OpenAPI spec directly, and more than half my own traffic is plain HTTP. Forge compiles an SDK, a CLI and an MCP server from the same spec. So maybe the spec is the real contract and the SDK is one output among several. I agree with half of it. The spec matters more than ever, because a bad spec now compiles into a bad SDK, a bad CLI and a bad MCP server at once. Where I disagree is what happens after the agent leaves. An agent can write a typed, tested client in an afternoon, so the expensive part is owning it. A vendor-maintained SDK is a maintenance cost paid once: the spec changes, the vendor regenerates, and every customer picks up the fix with a version bump. An agent-written client is a fork. Each customer owns its own copy, frozen at the moment it was written, so one breaking change in the API turns into a separate incident at every customer, usually found in production and fixed by a team that didn't write the code. Agents made writing the code cheap, but the total cost of ownership didn't go down. It moved from the vendor to every one of its customers. Where I land Your customers still need SDKs. The integrations they run for years should sit on a client you maintain once. Keep a generator for that. Your agents need something different. They don't need more code, they need intent: a clear answer to what each operation is for and when to use it. No generator gives you that for free. It comes from method names an LLM guesses right on the first try, a surface cut down to the operations that matter, descriptions that explain the job rather than the endpoint, and errors that tell the caller what to do next. That was my argument in 2025 for human developers, and agents need it more. For the surfaces agents call directly, that may mean building your own: still a generated client, but one where you control every word the model reads. Hit reply and tell me: are your integrations still using SDKs, or has your coding agent quietly stopped importing them? Unsubscribe | 1 Bd des clubs - CFC, 20200 Casablanca, Morocco