Create a competitor parity matrix and multi-language roadmap for AutoSDK

[HavenDV]

Problem

AutoSDK now has multiple focused gap issues, but we still need one living issue that answers the higher-level questions:

• Which competitors are we tracking on purpose?
• Which capability areas matter for parity?
• Which gaps are C#-specific vs generator-core vs multi-language blockers?
• How does competitor pricing change the niche AutoSDK should target?

Without that umbrella, parity work fragments into isolated issues and becomes difficult to review over time.

Why this is an issue, not COMPETITORS.md

Use a GitHub meta-issue first, not a static repo document.

Why:

• issues are assignable, searchable, labelable, and easy to keep alive
• this market changes too often for a static file to stay accurate without an owner
• focused parity issues can be linked directly from here
• pricing and positioning notes are easier to refresh in one issue body than across scattered comments

A repo document may still make sense later, but only after the matrix stabilizes and there is a clear maintenance workflow.

Competitors and benchmarks to track

Direct commercial SDK-generator competitors

• Fern
• Speakeasy
• Stainless
• liblab
• APIMatic
• Konfig

Open-source / ecosystem baselines

• Kiota
• OpenAPI Generator
• NSwag
• Swagger Codegen as a legacy baseline

Benchmark SDKs

• AssemblyAI C# as a polished generated-plus-manual C# SDK benchmark

AssemblyAI note

AssemblyAI C# should not be treated as a separate generator vendor. It looks like a Fern-generated base with manual overlays.

Signals:

• the repo contains .fernignore-related custom props
• tests reference generated files under FernGenerated
• ApiException.cs contains a TODO mentioning the Fern generator
• the SDK includes manual extension layers such as extended client, request options, and service partials

Use AssemblyAI mainly as a benchmark for C# packaging, runtime ergonomics, and what a generated-plus-manual SDK can feel like in practice.

Capability areas to track

• OpenAPI 3.0 / 3.1 / 3.2 coverage
• JSON Schema coverage and normalization behavior
• vendor-extension compatibility
• auth and security schemes
• security requirement OR / AND semantics
• server handling and runtime server selection
• callbacks, webhooks, and links
• pagination
• polling / long-running operations
• retries / idempotency / timeouts
• request options / client options / hooks
• examples, snippets, and docs sync
• packaging and runtime quality per language
• multi-language architecture readiness

Pricing snapshot (as of April 8, 2026)

This section is intentionally high level and should be refreshed from official vendor pricing pages when it becomes stale.

• Fern: pricing shows Hobby at $0/mo, Team at $150/mo, and Enterprise as custom; the page also shows up to 50 endpoints, up to 150 endpoints, and unlimited tiers.
• Stainless: pricing shows Free at $0, Starter at $79, Pro at $499, and Enterprise as custom; the page also exposes endpoint-based overage language such as 50 endpoints incl., 100 endpoints incl., and $5/mo/SDK/addtl.
• APIMatic: pricing shows Starter at $10/mo billed annually or $15/mo billed monthly, while the meaningful SDK tier starts at Basic for $300/mo/language; Business and Enterprise are custom.
• Speakeasy: the official pricing page is public, but numeric plan details were not cleanly extractable when checked on April 8, 2026; first-party Speakeasy content still mentions free up to 250 endpoints per SDK, paid plans starting at $250/month, and a $600/mo Pro tier, but those numbers should be treated as provisional until manually rechecked against the live pricing page.
• liblab: the public pricing page I could verify was mainly MCP-focused, showing FREE 100 MCP calls each month for the first year and then $5 for every 100 calls; I could not verify a separate public SDK-generator price from the accessible page.
• Konfig: I could not find a public pricing page.
• Kiota / OpenAPI Generator / NSwag / Swagger Codegen: effectively free / open source baselines.

What pricing suggests about AutoSDK's niche

The strongest near-term niche does not look like "another opaque enterprise sales-led generator".

The stronger position appears to be:

• OpenAPI-native, without requiring a proprietary configuration language
• cheaper and more self-serve than Fern / Stainless / Speakeasy for small teams
• less lock-in than the commercial generator vendors
• strongest-in-class C# support first
• best spec coverage, especially OpenAPI 3.1 / 3.2 plus common vendor metadata compatibility
• lower migration friction by understanding common Fern / Speakeasy / Stainless metadata

APIMatic's per-language pricing also suggests a later multi-language opportunity, but only after the core abstractions are stable enough to support more than C# cleanly.

Source quality and caveats

• Use official vendor pricing pages for pricing decisions whenever possible.
• Use competitor comparison blogs mainly for feature framing, not final pricing calls.
• Speakeasy comparison content appears stale on competitor pricing: one first-party comparison cites Fern at $250/mo per SDK, while Fern's own pricing page on April 8, 2026 showed $0/mo Hobby and $150/mo Team.
• The user-provided Stainless Notion link is useful as input, but public Stainless docs should be the long-term citation base.

Sources

Primary sources used so far:

• Fern Cohere case study: https://buildwithfern.com/blog/cohere
• Fern pricing: https://buildwithfern.com/pricing
• Speakeasy C# comparison: https://www.speakeasy.com/docs/sdks/languages/csharp/oss-comparison-csharp
• Speakeasy pricing: https://www.speakeasy.com/pricing
• Speakeasy vendor-selection post: https://www.speakeasy.com/blog/choosing-an-sdk-vendor
• Stainless pricing: https://www.stainless.com/pricing
• liblab release notes / Hub: https://liblab.com/docs/release-notes/august-2024
• liblab pricing: https://liblab.com/pricing
• APIMatic generate product page: https://www.apimatic.io/product/generate
• APIMatic pricing: https://app.apimatic.io/pricing-plans
• Konfig: https://konfigthis.com/
• Kiota overview: https://learn.microsoft.com/en-us/openapi/kiota/overview
• OpenAPI Generator: https://openapi-generator.tech/
• NSwag: https://github.com/RicoSuter/NSwag
• Swagger Codegen: https://swagger.io/tools/swagger-codegen/
• AssemblyAI C# SDK project file: https://github.com/AssemblyAI/assemblyai-csharp-sdk/blob/main/src/AssemblyAI/AssemblyAI.csproj
• Stainless reference provided by user: https://www.notion.so/fd2e000f1c194f6eb934ed5614f63441?pvs=21

Linked parity issues

OpenAPI / spec coverage

• Support OpenAPI callbacks, webhooks, and link objects #226 callbacks, webhooks, and links
• Catalog and support common SDK vendor extensions beyond Fern/OpenAI #227 vendor-extension inventory and support
• Expand OpenAPI 3.1 JSON Schema keyword support beyond current normalization #228 broader OpenAPI 3.1 / JSON Schema support
• Support path-level and operation-level servers plus runtime server selection #229 path-level and operation-level servers plus runtime selection
• Preserve OpenAPI security requirement OR/AND semantics instead of flattening schemes #230 security requirement OR / AND semantics
• Support remaining official OpenAPI security schemes (cookie apiKey, OpenID Connect, mutualTLS) #231 remaining official security schemes
• Support OpenAPI 3.2 parameter/query model and additional operations #232 OpenAPI 3.2 parameter/query model and additional operations
• Support OpenAPI 3.2 sequential media types and itemSchema-based streaming #233 OpenAPI 3.2 sequential media types and itemSchema streaming
• Support OpenAPI 3.2 metadata fields ($self, tag hierarchy, server names, richer examples) #234 OpenAPI 3.2 metadata fields
• Support OpenAPI 3.2 OAuth metadata and device authorization flow #235 OpenAPI 3.2 OAuth metadata and device flow

SDK DX / runtime parity

• Feat: Pagination #48 pagination
• Feat: Polly support #49 retries / resilience
• Support forward-compatible/open enums instead of collapsing unknown values to default #236 forward-compatible / open enums
• Generate SDK code snippets from OpenAPI examples and keep docs in sync #237 SDK code snippets from examples
• Add first-class idempotency header support for generated SDKs #238 idempotency header support
• Add first-class RequestOptions / ClientOptions surface for generated SDKs #239 request options / client options
• Add first-class request/response hooks or middleware for generated SDKs #240 hooks / middleware
• Generate polling/wait helpers from vendor metadata such as x-speakeasy-polling #241 polling / wait helpers

Language expansion / architecture

• Refactor: Extract AutoSDK.CSharp package for multi-language support #182 language-agnostic generator architecture extraction

Suggested follow-up workflow

• Keep this issue as the umbrella competitor and positioning tracker.
• Update the issue body when pricing or competitor scope changes, instead of scattering key information in comments when a body update is cleaner.
• Open focused issues for concrete gaps and link them back here.
• When multi-language work becomes active, split language-specific roadmap issues from this umbrella instead of overloading feature issues.

[HavenDV]

Follow-up competitor analysis as of April 8, 2026.

Recommended competitor taxonomy:

1. Direct commercial SDK-generator competitors to track for parity

• Fern
• Speakeasy
• Stainless
• liblab
• APIMatic
• Konfig

Why add APIMatic + Konfig:

• APIMatic explicitly positions around generated SDKs, docs, code samples, and API playgrounds across multiple languages: https://www.apimatic.io/product/generate
• Konfig explicitly positions around generating and republishing SDKs, docs, demos, tutorials, and even SDK test cases from OpenAPI/Postman: https://konfigthis.com/

2. Open-source / ecosystem baselines to track separately

• OpenAPI Generator
• NSwag
• Kiota
• Swagger Codegen (legacy / lower priority)

Why these matter:

• Kiota is Microsoft’s actively positioned multi-language OpenAPI client generator: https://learn.microsoft.com/en-us/openapi/kiota/overview
• OpenAPI Generator remains the broad open-source baseline with wide integrations/customization: https://openapi-generator.tech/
• NSwag remains an important .NET-specific baseline: https://github.com/RicoSuter/NSwag
• Swagger Codegen is still worth remembering historically, but likely lower priority than OpenAPI Generator: https://swagger.io/tools/swagger-codegen/

3. Benchmark SDKs (not generator vendors)

• AssemblyAI C# should be treated as a benchmark SDK, not as a separate competitor company in this matrix.

Evidence from the AssemblyAI repo strongly suggests a Fern-generated base with manual overlays:

• custom props explicitly mention .fernignore: https://github.com/AssemblyAI/assemblyai-csharp-sdk/blob/main/src/AssemblyAI/AssemblyAI.Custom.props
• unit test project links generated files under FernGenerated: https://github.com/AssemblyAI/assemblyai-csharp-sdk/blob/main/src/AssemblyAI.UnitTests/AssemblyAI.UnitTests.csproj
• code comment explicitly references “Fern generator”: https://github.com/AssemblyAI/assemblyai-csharp-sdk/blob/main/src/AssemblyAI/Core/Public/ApiException.cs
• repo structure includes generated base + manual extension-style partials such as ExtendedFilesClient, ExtendedRealtimeClient, ExtendedTranscriptsClient, ExtendedClientOptions, ExtendedRequestOptions

Recommendation:

• keep AssemblyAI in the tracker as a C# DX / packaging / customization benchmark
• do not count it as an additional generator vendor alongside Fern/Speakeasy/Stainless/liblab/APIMatic/Konfig

If we want to keep the matrix manageable, I would treat these as the default watch list:

• Direct commercial: Fern, Speakeasy, Stainless, liblab, APIMatic, Konfig
• Open-source baselines: Kiota, OpenAPI Generator, NSwag
• Legacy reference only: Swagger Codegen
• Benchmark SDKs: AssemblyAI C# and possibly a few other high-quality hand-crafted SDKs later