Onlook

You will love Onlook if you want to visually tweak interfaces while keeping your code in sync. It targets teams working with Next.js and TailwindCSS, letting you adjust styles directly in the browser DOM with an AI assistant while web containers handle live previews. Because it writes back to real files, design changes translate into actual Git changes without messy manual handoffs.

The trade-off is the narrow stack focus. If your project sits outside Next.js and TailwindCSS, the visual editing workflow loses its core appeal. Pick Onlook if you want designers and developers editing the same React markup visually. Pick Cursor instead if you want an editor for general codebases across any stack.

Onlook targets teams where designers modify production interfaces directly. The workflow combines visual DOM manipulation with direct two-way code synchronization. It runs projects inside web containers and relies on OpenRouter models. The constraint is the stack. The visual editor assumes Next.js and TailwindCSS. If your application relies on alternative styling systems or component architectures, this synchronization cannot function.

The trade-off centers on model configuration and governance. While the core codebase is open-source under Apache-2.0, you lack support for local models or custom API keys. Teams requiring strict local-only execution or bespoke model endpoints must evaluate whether this architecture meets internal compliance rules.

Onlook is useful for design-oriented developers who want to modify interface code visually rather than by typing markup. The architecture relies on two-way synchronization between browser DOM modifications and project source code, supported by web container execution. Model interactions route through OpenRouter rather than direct model endpoints, and multi-file editing is documented. The trade-off is architectural lock-in: the workflow is tied to Next.js and TailwindCSS frameworks, offering little utility outside that ecosystem.

Teams using this stack benefit from verified visual feedback loops during component styling. However, without public benchmarks or decoupled abstractions, evaluate whether its rigid stack alignment fits your codebase.

Onlook targets designers and frontend engineers who want to manipulate real Next.js and TailwindCSS code visually in the browser DOM. The open-source client offers two-way synchronization, terminal execution, and Git operations without locking you into proprietary markup. With OpenRouter as the backbone, users pay model providers directly, keeping Onlook's own operating burn low while testing demand across web, macOS, Linux, and Windows.

The trade-off is organizational durability. As a Y Combinator company running a free Apache-2.0 core, Onlook has no established enterprise pricing power yet. A hosted waitlist suggests a commercial SaaS pivot is forming. Position: use the free local editor today, but avoid critical production workflows until the business model clears the waitlist.

Onlook is useful for design-heavy teams shipping directly to Next.js and TailwindCSS codebases. It provides real-time two-way synchronization between browser DOM changes and source files, running in web containers or locally. Model routing flows through OpenRouter without seat charges for the open-source client. It handles terminal execution, Git operations, and multi-file code updates directly.

The trade-off is governance. There is no SSO, SCIM provisioning, or centralized retention tracking for external model usage across sixty seats. Operating sixty isolated configurations without unified telemetry introduces unmanaged risk for our security review. Not yet.

Onlook suits frontend teams targeting Next.js and TailwindCSS who need two-way syncing between rendered DOM nodes and files. The Apache-2.0 codebase gives you a local-first desktop editor on Linux, macOS, and Windows with a real terminal and Docker sandboxes. You inspect components directly in the browser preview while an assistant edits code files across the tree.

The trade-off is AI control. Backbone access relies on OpenRouter with no BYOK flag, no local model support, and no MCP client or server. If the upstream API routing changes, you cannot simply redirect traffic to your own local endpoint without rewriting internals.