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

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

• #226 callbacks, webhooks, and links
• #227 vendor-extension inventory and support
• #228 broader OpenAPI 3.1 / JSON Schema support
• #229 path-level and operation-level servers plus runtime selection
• #230 security requirement OR / AND semantics
• #231 remaining official security schemes
• #232 OpenAPI 3.2 parameter/query model and additional operations
• #233 OpenAPI 3.2 sequential media types and itemSchema streaming
• #234 OpenAPI 3.2 metadata fields
• #235 OpenAPI 3.2 OAuth metadata and device flow

SDK DX / runtime parity

• #48 pagination
• #49 retries / resilience
• #236 forward-compatible / open enums
• #237 SDK code snippets from examples
• #238 idempotency header support
• #239 request options / client options
• #240 hooks / middleware
• #241 polling / wait helpers

Language expansion / architecture

• #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.

Start with this issue body, its linked parity issues, and the listed official competitor pricing and documentation sources. Build the living matrix around the named competitors, capability areas, language blockers, and pricing caveats; it is done when focused gaps link back here and the maintenance workflow is explicit.