Sol Browser

The product formerly called Inspector now redirects to and identifies itself as Sol Browser. The current site says, “we made the browser the IDE,” replacing Inspector's original visual front-end editing focus with a broader workspace for parallel coding agents.¹ The company identity remains continuous: the former Inspector LinkedIn page is now branded Sol Browser, and the Y Combinator-backed founders are the same team.²³

Sol's core primitive is the tab. Coding agents, terminals, diff viewers, documentation, pull requests, dashboards and ordinary web pages can sit in the same tabbed workspace. Tabs can be split, reordered and grouped; a new git worktree can create its own group with an agent/chat tab anchored to that worktree.¹ This is a different proposition from simply embedding a browser preview in an editor: Sol treats browser organization itself as the orchestration layer for concurrent development work.

Users connect existing Claude Code, Codex or Cursor subscriptions rather than buying a proprietary model bundle.¹ Sol also exposes programmable primitives through its SDK so developers can script how tabs, projects and worktrees are arranged when they open.¹ The current product therefore competes more directly with agent orchestration/IDE workflows than with Figma.

Inspector history still matters, but only as lineage. In February 2026 Inspector launched as a visual editor that let users click UI elements, change styles visually and write changes back to the codebase through Claude Code, Codex or Cursor.⁴ The team reported an internal 89-case visual benchmark where Inspector failed 4 cases versus Cursor's browser editor failing 43.⁴ That was a vendor-run comparison of the old visual-editor surface; it should not be treated as a benchmark for current Sol.

Sol is currently free. The official site explicitly says users can download the browser and connect their existing Claude Code, Codex or Cursor subscription without another Sol subscription.¹ A current secondary listing likewise finds no advertised paid tier.⁵ The August privacy notice nevertheless covers transaction/subscription data and “purchase of a paid service,” so the company has left room for future paid services.⁶

There is no conventional public cloud API to score as a developer API. The more relevant extensibility surface is the Sol SDK plus integration with external coding-agent subscriptions.¹ That distinction matters: Sol is a local developer environment/orchestrator, not an API service that exposes its own foundation model.

Sol's privacy architecture is one of its stronger current signals. The August 15, 2026 privacy notice says projects, source code, worktrees, browser state, terminal sessions and chat history are stored locally by default and that the company does not routinely upload or maintain hosted copies merely because the browser is used.⁶ That is well aligned with a developer tool handling proprietary source code.

Local-first does not mean no data leaves the device. When a user invokes an AI agent, integration or cloud-backed feature, Sol may transmit the content needed for the request—including prompts, page context, file excerpts or tool results—to the selected provider or another service acting on Sol's behalf.⁶ The policy names providers that may include Anthropic, OpenAI and Cerebras, and says their own terms/privacy practices also govern processing.⁶

The current privacy notice also documents product telemetry and service providers including WorkOS, Stripe, Autumn, PostHog, Vercel, Sentry and Context Company.⁶ Session replay is not enabled by default and is described as something that may be activated specifically for troubleshooting/testing.⁶ This is materially more precise than vague “we respect privacy” language.

The main evidence gap is maturity rather than an identified security failure. Sol's present identity is new enough that most public third-party material still refers to Inspector. A current AISO Tools listing describes the present tab/worktree architecture but has no meaningful review population.⁵ The old Inspector Product Hunt launch had strong interest and detailed workflow discussion, but those reactions belong to a materially different surface.⁴ Current claims about Sol's stability, resource use, browser compatibility, extension behavior and multi-agent performance therefore remain lightly tested in public.

Sol is best for developers already using terminal-based coding agents heavily. If a workflow routinely has Claude Code in one terminal, Codex in another worktree, a PR in the browser, documentation in several tabs and a diff viewer elsewhere, grouping those objects around the worktree is a plausible reduction in context switching.¹

It is especially relevant to developers comfortable with git worktrees and parallel agents. The product's architecture assumes that multiple concurrent tasks are normal rather than exceptional, and its programmability lets advanced users define workspace conventions rather than accept a fixed IDE layout.¹

It is a weaker fit for teams that depend on Windows today, organizations that require long-established IDE extension ecosystems, or developers who primarily use one agent in one repository and do not suffer from tab/worktree sprawl. Teams considering a full migration should also test debugging, language tooling, accessibility, browser compatibility and large-project resource use rather than inferring them from the product concept.