Documentation

Everything on this page describes shipped behavior -- if a command is listed here, it works today.

Install

npm install -g @osmundus/cli

The CLI runs entirely on your machine -- generation never calls a hosted service. Node 22+ required. TypeScript and Python are the two supported targets, on purpose: two languages at hand-written quality before spreading thin across seven.

Generate an SDK

osmundus generate --spec ./openapi.yaml --target all
# → generated/typescript-sdk/
# → generated/python-sdk/

From an OpenAPI 3.0/3.1 spec, each target gets a typed client class, typed request params and response models, typed errors, auth handling, retries with backoff, and pagination helpers where the spec makes the pattern detectable. Output is deterministic: the same spec and config produce a byte-identical SDK on every run.

Osmundus fails loudly on spec constructs it can't type correctly -- an undiscriminated oneOf/anyOf union, or a pagination style the generators don't support yet -- rather than silently emitting broken code. The error names the schema and what to change.

Start from scratch

osmundus init --spec ./openapi.yaml

Creates a starter osmundus.config.json pointing at your spec, with method naming and resource mounting drafted from the spec itself. The config controls naming, mounting, model renames, and targets -- edit it and re-generate.

Migrate from Stainless

osmundus import --stainless ./stainless.yml --spec ./openapi.yaml
osmundus generate --config ./osmundus.config.json

The importer reads your existing Stainless config and preserves your SDK's resource and method names, so the public surface your users already call doesn't change. Anything it can't translate is reported as an explicit warning -- never silently dropped.

Preview a surface

osmundus preview --spec ./openapi.yaml

Prints the exact client.resource.method() surface a generate run would produce, plus SDK-shape diagnostics (naming consistency, pagination detection, schema issues) -- without writing any files. The same engine powers the Studio's live preview pane, so the two can't disagree.

The Studio

The hosted Studio adds continuous generation on top of the CLI: install the Osmundus GitHub App on your spec repo, and every push to your default branch generates fresh SDKs and opens release PRs on your SDK repos -- with a browser editor, live surface preview, release history, and team access. Sign in with GitHub to set it up.

Self-hosting

The generator and CLI are MIT-licensed and run anywhere Node runs -- your laptop, your CI. There is no hosted dependency in the generation path, so if Osmundus-the-company disappeared tomorrow, your SDK pipeline keeps working. The hosted Studio is the optional convenience layer, not the product's foundation.