Kubb: A Plugin-Based Generator for OpenAPI to TypeScript, Zod and TanStack Query

The Handoff Problem Kubb Targets

Most teams already have an OpenAPI document. What they do not have is a reliable path from that document to the TypeScript their application actually imports. Someone writes a client by hand, the spec drifts, and the types stop matching the responses. Kubb's stated purpose is to close that gap: you point it at a schema and it generates types, clients, hooks, validators, mocks and more. The audience is TypeScript teams on Node.js or Bun who treat the spec as the source of truth and want the generated layer to be ordinary source files in the repository, reviewable in a pull request. The README describes Kubb as a meta framework for code generation, which is a fair label: it is not one generator but an engine that runs generators. That distinction matters for adoption, because the value you get depends on which plugins you enable rather than on a fixed feature list.

Plugins, Adapters and Renderers as the Actual Architecture

The pipeline has three visible stages. An adapter reads the schema: the README names @kubb/adapter-oas for OpenAPI 2.0, 3.0 and 3.1, and notes output for Node.js and Bun. Plugins then consume the parsed model and emit artifacts. The named set is plugin-ts, plugin-axios, plugin-fetch, plugin-react-query, plugin-vue-query, plugin-swr, plugin-zod, plugin-faker, plugin-msw, plugin-cypress, plugin-redoc and plugin-mcp. Storage is the third stage: the README says output can be written to disk, to memory, or to a custom storage backend, and that files can be grouped by tag with operations included or excluded. The generator layer is exposed: kubb/kit is documented as an authoring toolkit for custom plugins, generators, adapters and renderers, with a JSX renderer for component-based output. So the data flow is schema in, parsed model, plugin transforms, rendered files out. The practical consequence is that two teams using Kubb can produce very different repositories, and the config file, not the package, is where your architecture lives.

Installing and Running the Generator

Installation is a single dependency: bun add kubb, pnpm add kubb, or npm install kubb. The documented quick start is a wizard. Running npx kubb init creates a kubb.config.ts; the README states the wizard also creates a package.json if needed, guides you through plugin selection, installs packages, and writes the config. Generation is then npx kubb generate. There is a second integration path: unplugin-kubb runs generation inside the bundler for Vite, Nuxt, Astro and webpack, which removes the separate generate step from the developer loop. A third path exists for AI tooling: the README lists a built-in MCP server for Claude and Cursor, and a Claude Code integration documented under the 5.x AI section. Note what the README does not give: it shows no full kubb.config.ts example, so the concrete shape of the plugin array, the input path key and the output options has to come from kubb.dev rather than from the repository front page. Treat the wizard output as the starting reference.

Version 5 and the Cost of a Plugin Ecosystem

The release list shows kubb@5.2.0 on 2026-09-09, kubb@5.1.0 on 2026-09-03, and kubb@5.0.6 on 2026-09-02. Two minor releases inside a week on a 5.x line is a normal cadence for an actively developed generator, and it is also the main maintenance cost. Plugins are published separately from the core package (the README links to a separate kubb-labs/plugins repository), which means a version skew between kubb and, say, plugin-zod is a real failure mode to plan for. Pin every @kubb/plugin-* package alongside the core package and upgrade them together. The upside of the split is that you install only what you generate with, so a project that needs types and a fetch client does not pull in the Cypress or Redoc plugins. The documentation also carries a 5.x path segment in its URLs, which signals that major-version documentation is versioned; check that the page you are reading matches the major you have installed.

Where Kubb Is the Wrong Tool

Kubb assumes a machine-readable schema. If your API is only described in prose, in a Postman collection, or in a hand-written client that nobody has reverse-engineered into OpenAPI, there is nothing for the adapter to read. That is not a limitation Kubb can work around, and it is the first thing to check. The second constraint is that Kubb is a library and a CLI, not a service. There is no hosted generation, no dashboard, and no graphical editing of the spec. Teams that want the schema and the generated client managed in one place, with the generation triggered by a platform rather than by a command in their own pipeline, are outside the intended shape of the project. Third, the plugin model is a surface you must own: choosing plugins, grouping output by tag, and deciding between disk, memory and custom storage are configuration decisions the tool deliberately leaves to you. If your team wants one blessed output layout with no decisions, a single-purpose generator will be less work. Finally, the README documents the MCP and Claude Code integrations as features but gives no detail on their scope, so do not adopt Kubb for the AI path alone; verify it on kubb.dev first.

The Alternative: A Single-Output Generator

The realistic alternative is a generator that emits one thing well, for example an OpenAPI-to-TypeScript client tool that produces a typed SDK and stops there. The difference is architectural rather than cosmetic. A single-output generator decides the output for you: one client, one file layout, one set of conventions, and upgrading means accepting whatever that project's next release changes. Kubb inverts this. It runs an adapter to build an internal model, then hands that model to whichever plugins you listed, then writes the result through a storage layer you can replace. The cost is that you assemble and maintain the pipeline; the benefit is that adding Zod validation or MSW handlers later is a plugin entry rather than a migration to a different tool. If your only need is a typed client and you never expect to generate mocks or validators, the single-output approach has less config to keep correct. If you expect the generated surface to grow, Kubb's plugin boundary is the reason to pick it.

Licence and What the MIT Terms Leave You to Decide

Kubb is MIT licensed. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are included, and it comes with no warranty. Two practical notes, not legal advice. First, generated files are output of the tool rather than the tool itself, but since the generated code is derived from your schema and from plugin templates, confirm with your own counsel how you want licence headers handled in generated directories before you commit thousands of generated lines. Second, the README states that development is funded entirely by sponsors, with GitHub Sponsors and Open Collective links. A sponsor-funded project is not a defect, but it does mean the maintenance model is not a commercial support contract, and you should treat your pinned version as the thing you depend on rather than an implied support relationship. The repository is not archived, and the last push recorded is 2026-09-10, so the project is active as of that date.

Editorial conclusion

Adopt Kubb if your API is described by an OpenAPI document and you want the generated surface (client, hooks, validators, mocks) to live in your repository under your own review. Skip it if you need a hosted generator, a graphical schema editor, or a tool that works without a maintained spec. Before committing, run npx kubb init against your real schema, inspect the generated file tree for one tag group, and confirm that pinning kubb and every @kubb/plugin-* package to the same major keeps npx kubb generate reproducible in CI.

Official sources

1. kubb-labs/kubb on GitHub
2. License: MIT
3. Project website
4. README
5. Releases