openapi-to-rust is not affiliated with Oxide Computer Company or Progenitor. Progenitor is named here to help Rust teams choose by use case, not to imply that one project should serve every OpenAPI workflow.
The short answer
Start with Progenitor when your API is produced by Dropshot, you want its procedural-macro or build-script integration,
or its pagination streams, generated CLI, and typed httpmock helpers match your workflow. Oxide describes Dropshot-generated APIs as Progenitor’s primary target.
Start with openapi-to-rust when you consume modern third-party specifications, need OpenAPI 3.1 schema forms, generate SSE clients or selected Axum operations, or want checked-in source generation outside the downstream Cargo build.
Neither recommendation replaces a compile test. Run both against the unions, parameters, authentication, and response bodies that make your document difficult.
Different centers of gravity
This table compares documented project scope as reviewed on July 28, 2026. “Not a documented project goal” is intentionally different from “unsupported.”
On narrower screens, scroll horizontally to compare both generators.
| Dimension | openapi-to-rust | Progenitor |
|---|---|---|
| Primary scope | Rust models, Reqwest clients, SSE clients, Axum servers, and operation registries | Opinionated async Rust client generation |
| Primary API environment | Large third-party and service-provider specifications | Dropshot-generated APIs, while accepting other compatible documents |
| Documented OpenAPI input | 3.0 and 3.1; experimental 3.2 parsing | 3.0.x |
| Client interface | Flat typed methods; opt-in builders above a configurable threshold | Positional or builder style |
| Generation workflow | CLI, Rust library, or browser; normal CLI flow writes ordinary Rust before compilation | Procedural macro, build.rs, or a generated static crate |
| Generated server | Selected Axum operations with shared models, routing, typed responses, and request validation | Not a documented project goal; Progenitor describes itself as a client generator |
| Streaming focus | SSE parsing, typed events, reconnection, and Axum SSE responses | Streams for paginated interfaces; WebSocket channel support is also documented |
| Generated support tools | Operation registry and browser-downloadable crate; no equivalent generated Clap or httpmock surface | Generated Clap CLI and strongly typed httpmock helpers through the generator API |
| Schema adaptation | Overlay files, type strategies, aliases, extensible-enum settings, and per-format mapping | Type patches, replacements, conversions, additional derives, and x-rust-type crate policies |
| Project posture | Pre-1.0, Rust-only generator tested against a maintained real-world corpus | Established pre-1.0 generator maintained by Oxide and used for its API ecosystem |
What the build benchmark actually shows
We measured each project’s normal client workflow against the same synthetic OpenAPI 3.0.3 document with 120 operations and 120 models. Results below are median wall times on an Apple M4 Max using Rust and Cargo 1.97.0. Dependencies were downloaded before timing.
| Scenario | Ahead-of-time source | Progenitor macro | Observed result |
|---|---|---|---|
Clean cargo check | 5.91 s | 8.04 s | 26.5% lower in this run |
No-op cargo check | 0.08 s | 0.08 s | No meaningful difference |
| Rust source touched | 0.445 s | 0.58 s | 23.3% lower in this run |
| Schema changed + checked | 0.54 s | 0.64 s | 15.6% lower in this run |
The clean result includes each client’s current dependency graph—Reqwest 0.12 for openapi-to-rust and 0.13 for Progenitor—so it does not isolate procedural-macro overhead. The fixture is synthetic, and the generated clients are not feature-equivalent. Treat these numbers as evidence that ahead-of-time generation can reduce build overhead in this setup, not as a universal speed guarantee.
Review the reproducible harness, raw samples, and full methodology before quoting the result.
Where each project is particularly compelling
Progenitor’s strengths
- Established alignment with Dropshot and Oxide’s API conventions.
- Macro, build-script, and static-crate integration choices.
- First-class pagination streams and request/response hooks.
- Generated CLI and typed mocking helpers.
- Fine-grained generated-type replacement and patching.
openapi-to-rust’s strengths
- OpenAPI 3.1 forms found in modern third-party documents.
- One shared model surface for selected clients and Axum servers.
- SSE-specific clients, reconnection, and server responses.
- Operation selection, model pruning, and overlay-based repair.
- Inspectable, checkable source generated before downstream builds.
Which should you choose?
Choose based on your specification and delivery model. Progenitor is a strong default for a Dropshot-centered client ecosystem and for teams that value compile-integrated generation or its testing tools. openapi-to-rust is aimed at teams consuming varied external contracts or generating both sides of a Rust boundary.
Pin both versions, generate against the same document, and compile the result. Then inspect the five hardest operations rather than counting table rows. A minimized fixture is stronger evidence than either project’s marketing copy.
Primary sources
- Progenitor README: scope and primary Dropshot target
- Progenitor README: macro, build.rs, and static-crate workflows
- Progenitor 0.14.0 macro options
- Progenitor 0.14.0 generator API
- openapi-to-rust README and feature documentation
- Build benchmark harness and raw result
Last source review: July 28, 2026. If a claim is stale or incomplete, please report it with a primary source or minimized fixture.