Describe it, then watch it run
A sandboxed Linux workspace with a shell, a file tree and a terminal. Code gets written to files and executed, so what you see is output rather than a description of output.
How it works
Three steps, and none of them is “configure”.
- 01
Say what you want built
Or bring files of your own — drop them anywhere on the page and they land in the workspace.
- 02
It writes files and runs them
Not code in a chat bubble. Real files in a real filesystem, and commands whose output comes back to both of you.
- 03
You keep the workspace
Files, installed packages and shell state are still there the next time you open the session.
What it can do
A real terminal
node, npm, git, curl, python3 with pandas and matplotlib, and the usual coreutils. Anything else installs with pip or npm.
Run a file yourself
Any Python, JavaScript, TypeScript or shell file gets a Run button. It saves first, then runs, and the output appears in a terminal pane under the file that you can minimise or close.
Any model, changed mid-session
The environment does not change when the model does, so you can switch to something stronger for the hard part and back again afterwards.
How it is set up
The mechanics, so you know what you are getting before you sign in.
- Environment
- A Linux container per session, kept warm between your turns. Your workspace is mounted at the directory the shell starts in.
- Tools
- A shell, plus read, write, edit, glob and grep.
- Model
- Any chat model in the catalogue.
- Starting files
- Nothing seeded — it starts empty, because what you build in it is the point.
- What persists
- The workspace is stored per session and survives a reload, a closed tab and a different device.
Things people ask it
- “Write a Python script that finds duplicate files in a folder, then run it on some test files you create.”
- “Set up a small HTTP server in Node with one health endpoint, run it, and show me the response.”
- “Take this CSV and turn it into a JSON file with one object per row.”
- “Benchmark these two functions and tell me which is faster, and by how much.”
What it will not do
Every one of these is a real constraint we have hit, not a roadmap item.
- No long-running servers reachable from outside. A command that needs to keep running is stopped at its timeout.
- The sandbox is reclaimed once a session goes quiet. Your files survive that; a running process does not.
- It is a workspace, not a deploy target. What you build here you take with you.
Which model does this best
Measured over real runs of this agent, per model. A run counts as finished when it produced the answer on its own — nothing failed, nobody was asked to approve anything, and it did not run out of steps. Read all three columns together: a model that finishes fast by giving up scores badly on the first, and one that completes everything by grinding scores badly on the second.
| Model | Completion rate | Median cost | Median time | Runs |
|---|---|---|---|---|
| kimi-latest~moonshotai | 92% | $0.028 | 37s | 12 |
| gemini-3.5-flash-litegoogle | 100% | $0.016 | 19s | 4 |
| gemini-3.6-flashgoogle | 100% | $0.063 | 76s | 4 |
| gpt-5.6-luna-proopenai | 100% | $0.010 | 38s | 4 |
| claude-sonnet-5anthropic | 100% | $0.238 | 88s | 3 |
| gemini-3.7-flashgoogle | 67% | $0.045 | 56s | 3 |
- Completion rate
- Runs that finished the job without you having to step in.
- Median cost
- What a typical run costs, in credits.
- Median time
- Wall clock, from the first message to the answer.
Medians over the runs behind each row. A model appears once it has 3 runs on this agent, and the run count is shown so you can judge how much a figure rests on.