Skip to content

Contributing to OpenCauldron

OpenCauldron is an open-source project maintained across three public repositories. Contributions of all kinds are welcome — whether you are fixing a bug, adding a new AI provider, improving documentation, or building CLI features.

This section covers everything you need to get started as a contributor.


RepoWhat it isWhere to start
opencauldron/opencauldronThe main Next.js applicationDevelopment setup
opencauldron/opencauldron-websiteThis docs and marketing site (Astro + Starlight)Contributing to docs
opencauldron/create-opencauldronThe create-opencauldron CLI scaffolding toolContributing to the CLI

Each repo has its own setup instructions. Most contributors will spend their time in the main app repo.


The most common code contribution is adding support for a new AI image or video model. The provider system is deliberately small — a new provider is a single TypeScript file implementing one interface, plus a registry entry. See Adding a Provider for the full walkthrough.

Browse open issues on GitHub. Issues tagged good first issue are a good starting point for new contributors. Comment on an issue before starting work on it — this avoids duplicate effort.

If you find a doc that is wrong, incomplete, or hard to follow, the fix belongs in the website repo. See Contributing to Docs for how the site is structured and how to preview changes locally.

The create-opencauldron scaffolding wizard is a separate package. If you want to add a new provider prompt, fix a wizard step, or improve the non-interactive mode, see Contributing to the CLI.

See Issues and Feature Requests for how to write a useful bug report and how feature requests are evaluated.


  1. Find or open an issue — All work should be linked to a GitHub issue. This ensures intent is clear before code is written.
  2. Fork and branch — Fork the relevant repo and create a branch from main. Use descriptive branch names: fix/video-polling-timeout, feat/add-stability-provider.
  3. Make your changes — Follow the code style and linting rules described in Code Style and PR Guidelines.
  4. Verify — Run bun run lint and bun run build before pushing. Both must pass.
  5. Open a pull request — Target main. Fill in the PR description with what changed and why.