ClearProduct · Architecture
Why the browser workspace does less than the app
A demo that quietly does less than the product is a demo that produces a support conversation. ClearFrame states the delta on the page.
Last updated
Current availability: the web app is coming soon. Join the notification list to hear when it is ready. The design described below is not offered for public execution today.
The browser workspace design runs an agent loop with no installation. Its limitations are listed rather than discovered, and the list is short enough to be worth reading in full.
What it does
A task is described in a prompt. The agent responds, proposes files, and the files appear in an editor beside the conversation, where they can be edited, previewed and downloaded as a workspace. No account is required to try it, and the tasks and edits are saved in the browser.
What it does not do
| Omitted | Consequence |
|---|---|
| Tests and terminal commands | The agent cannot run anything. It proposes files and nothing verifies them. |
| Browser execution | The preview runs locally with network access disabled. |
| Full repository connections | You attach files rather than connecting a repository. |
| Account billing and metering | Anonymous limits apply instead of an account allowance. |
| File recovery | There are no snapshots. The desktop app's recovery layer does not apply. |
The page says so directly: tests and terminal commands are not run in the browser, and the desktop application is where the work is meant to happen. The download link sits immediately below the workspace rather than at the end of a journey.
The preview is the interesting constraint
Running a preview with network access disabled is a deliberate restriction, and it has a visible cost: generated code that fetches an external API will not work in the preview, and the reason is not obvious from the failure.
The workspace states the rule rather than leaving it to be inferred, and offers the alternative in the same sentence — download the files to test external services. A stated restriction is a constraint; the same restriction discovered through a silent failure is a bug report.
What the browser workspace is honest about not being
It is not a smaller version of the desktop application. The desktop application provides the mechanisms the rest of these notes describe: isolated copies of a project per task, checkpoints taken before a task's first tool use, a permission model with three access levels, usage ceilings, and a persistent shell across turns.
Some of those are impossible in a browser tab rather than merely omitted. A persistent shell, a file checkpoint across a project, and an isolated working copy all require a process on the machine that owns the files. The browser workspace's absences follow from where it runs, not from a decision to withhold features.
Why this is worth a note
Embedded demos are usually the least trustworthy surface on a software site. They are tuned to resemble the product within the first moments of use, which is exactly when a visitor has the least ability to tell a worked example from a real one. The cost arrives later, as a user who signed up expecting the thing they were shown.
Listing the omissions up front is not modesty. It is the difference between a visitor who understands what they are trying and one who will be disappointed by a product that never claimed the thing.
Stated limits
- Anonymous usage limits apply. They use temporary hashed network identifiers rather than accounts, and they are limits rather than an allowance.
- Submitted files leave the browser. When you use the workspace, your prompt and attached files are sent to the model provider to generate a response. The site does not store the conversation in its database; it stays in the browser under a signed-in account until site data is cleared.
- The preview is not a test. A preview that renders correctly shows that it renders, not that the code is correct.
What it shares with the desktop application
The browser workspace calls the same provider route, which is why it can be tried without an account and why the model behind it is described as a launch plan rather than a shipped entitlement. The conversation, the proposed files and the model’s responses are the same loop. What differs is everything the loop is permitted to touch.
Tasks and edits are held in the browser rather than on a server. Under a signed-in account they persist until site data is cleared; without one, closing the tab ends the session. The page states this where a reader looks for it rather than in a policy document.
The disclosure sits beside the input
A sentence in the interface carries more weight than a sentence in a table, because it appears where the action is taken. The workspace states beneath the composer that tasks and edits are saved in this browser and that tests and terminal commands are not run there. A visitor reading the composer learns both facts before typing, rather than after wondering why nothing was verified.
That placement is the decision worth recording. Each omission in this note could have been documented on a help page and satisfied a reviewer. Putting it beside the input is what makes it reach the person about to rely on the result.
Related reading
The privacy notice for what the browser workspace sends and where, the documentation for the desktop application’s mechanisms, and file recovery for the capability this surface does not have.