stagewise: an agentic IDE that browses, previews and edits in one window

What stagewise is for, and who it fits

stagewise is a desktop agentic IDE. The README describes it as "an open source agentic IDE for developers with a coding agent built right in," and the repository topics list agent, agent-orchestration and ide. The intended user is a developer who already moves between a browser, a preview server and an editor, and who wants those in one window instead of three.

The README lists five things the tool is meant to do: browse and build in the same tool, work with an agent that has access to the current tab's console and debugger, make temporary test changes or connect a codebase for permanent edits, reverse-engineer another site's components, style system and color palette, and view and apply code changes in your existing editor. That last point matters. stagewise is not trying to replace VS Code or JetBrains; it hands changes back to whichever editor you already use.

The reverse-engineering angle is the least common feature in this category. Most coding agents start from a repository. stagewise can start from a rendered page, which is useful when the thing you want to copy exists only as a live site.

How the agent, the browser and your editor fit together

The architecture visible in the repository is a pnpm monorepo driven by Turborepo. The root package.json defines build, dev, typecheck and test scripts that fan out across workspaces, with separate filters for apps, packages, toolbar, plugins, playgrounds and examples. The presence of a toolbar workspace, plus a search phrase people use for "Stagewise toolbar," suggests the in-page piece is its own buildable unit rather than something bundled into the desktop shell.

The .env.example file shows the runtime shape. The desktop app talks to an API_URL, which defaults to https://preview.api.stagewise.io, and to an LLM_PROXY_URL pointing at https://preview.api.stagewise.io/v1/ai. Account management lives at STAGEWISE_CONSOLE_URL, and the app checks UPDATE_SERVER_ORIGIN for updates. OAuth handoff uses a custom scheme derived from RELEASE_CHANNEL: stagewise:// for release, stagewise-prerelease:// for prerelease, stagewise-dev:// for dev. That scheme split is a practical detail: you can keep a dev build and a release build installed side by side without their auth callbacks colliding.

Model access has two paths. If you sign in to a stagewise Account, requests go through the LLM proxy and you get the bundled model list. If you bring your own key, the README says all popular providers are supported and that you can register completely custom providers, including local inference, and define custom models. Those are different trust boundaries: the proxy path sends prompts through stagewise's service, while a custom provider keeps traffic on your own endpoint.

Installing stagewise and connecting a model

The README does not document a package-manager install. It says to download stagewise from stagewise.io and follow the onboarding guide to set up an account. That is the supported path for the desktop app, and there is no npm or Homebrew command given for it.

If you would rather not route through a stagewise Account, the README's Bring Your Own API Key section is the alternative. It lists OpenRouter as the single-key route to models from multiple vendors, and gives provider dashboards for Moonshot AI, Alibaba DashScope, MiniMax, Xiaomi MiMo and Mistral. A key from any of those dashboards goes into the provider settings inside the app. The README does not spell out the exact settings screen names, so treat the provider table below as the source of truth for where to get a key rather than as a click-by-click guide.

# no install command is documented in the README;
# download the desktop build from stagewise.io and run onboarding

For contributors rather than users, the workspace is a standard pnpm and Turborepo setup. The root scripts include a dev task that watches all workspaces with a concurrency of 20, and narrower variants for playgrounds, examples, toolbar and plugins.

pnpm install
pnpm dev

A first real use, based on the README's feature list: open a page in the built-in browser, ask the agent to make a temporary change, confirm it in the preview, then either discard it or connect a codebase so the same edit is written to files. The README frames this as "make temporary test changes or connect a codebase for permanent edits," so the decision point is whether a codebase is attached.

The AGPL-3.0 boundary is the real adoption question

stagewise is licensed AGPL-3.0 and developed by stagewise GmbH. The README points readers to the GNU FAQ on the license and offers a sales contact for "use cases that fall outside the scope permitted by the AGPLv3 license." That sentence is the tell: the company expects some organizations to need a different arrangement, and the README does not describe what that arrangement is or what it costs.

For an individual developer or an open source project, AGPL-3.0 is usually a non-issue. For a company that wants to embed this code in a product it distributes under a closed license, or that runs a modified version as a network service, the copyleft terms are the first thing a lawyer will look at. The repository also carries a THIRD-PARTY-NOTICES.md file, which is where dependency licensing details live. I am not giving legal advice here; the point is that the license, not the feature list, is what will slow down procurement.

There is a second cost dimension. The stagewise Account tiers are listed at $0, $20 and $200 per month, with the free tier limited to three standard models and Ultra described as having 15x higher limits than Pro. If you bring your own key, you pay the provider directly instead. The README does not give token or request quotas for any tier, so the only concrete limit stated is the free tier's three-model restriction.

Where stagewise is the wrong tool

The README documents no headless or CI mode. Everything described is interactive: a browser, a preview, a tab console, an onboarding guide, an editor handoff. If your workflow is an agent running in a pipeline against a repository with no human watching, stagewise is not aimed at that, and nothing in the repository layout suggests a batch entry point.

Second, the documented install path is a desktop download from stagewise.io. The README gives no Docker image, no standalone CLI package and no server deployment instructions, even though "Stagewise cli" appears in the search data. Anyone who needs this on a remote box or inside a container should assume that path is undocumented until they find otherwise.

Third, the model story depends on external providers. The README's own examples are subscription and API-key based, and the bundled list is delivered through the stagewise proxy. If a provider changes its terms or an endpoint moves, that is outside stagewise's control. The .env.example even defaults API_URL and LLM_PROXY_URL to preview endpoints, which is a reminder that the hosted side of this product is a moving target that the desktop app depends on.

Finally, the repository is large and multi-workspace. Building it yourself means pnpm, Turborepo, Biome, commitlint and lefthook, plus a typecheck pass over the release scripts. That is a normal modern TypeScript monorepo, but it is not a five-minute clone-and-run.

How it differs from an editor-embedded assistant

The closest comparison is an AI assistant embedded in an existing editor, such as a VS Code extension that edits files in the open workspace. The difference in approach is what the agent can see. An editor-embedded assistant sees your files and your terminal. stagewise, per the README, gives the agent access to the current tab's console and debugger, and it can work against a live page before any codebase is connected.

That inverts the usual starting point. With an editor assistant you begin from source. With stagewise you can begin from a rendered result, make a temporary change, look at it, and only then decide to attach a repository. The README's reverse-engineering feature is the clearest expression of this: pulling components, style systems and color palettes out of a site you did not write.

The trade-off is scope. An editor extension inherits your editor's full language tooling and never asks you to leave. stagewise is a separate application with its own account, its own update channel and its own model configuration. If your work is mostly refactoring across a large codebase, the browser-side capabilities add little. If your work is mostly making a running interface behave differently, they add a lot.

Maintenance, releases and what to watch

The repository is not archived and the last push was on 2026-09-10, a week before this was written, so the codebase is moving. Release cadence is visible in the tags: [email protected] landed on 2026-08-15, alongside nightly builds such as [email protected] and [email protected] published the same day. Nightly tags in the release feed mean the project ships continuously, which is good for fixes and bad for anyone who wants a slow, predictable upgrade path.

The root package.json exposes versioning scripts per channel: version:stagewise:alpha, version:stagewise:beta and version:stagewise:release, plus a version:karton target for a second package. That is a deliberate channel structure, and it tells you which build you are on matters. The .env.example derives the OAuth callback scheme from RELEASE_CHANNEL, so a prerelease build and a release build behave differently at login.

Upgrade cost is mostly the desktop app's own update mechanism, which points at UPDATE_SERVER_ORIGIN. If you build from source instead, you inherit the monorepo toolchain and its typecheck and test tasks. Either way, read .release-notes.md and the .release-notes directory before upgrading, since there is no separate changelog file listed at the top level.

Editorial conclusion

Adopt stagewise if you want an agent that can read a tab's console and debugger while you edit, and if AGPL-3.0 fits how you ship. Do not adopt it if you need a permissively licensed codebase you can close, or if you want a terminal-first agent. Before committing, verify the onboarding flow at stagewise.io, confirm which providers your key actually reaches, and read the AGPLv3 FAQ the README links to.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. stagewise-io/stagewise on GitHub