Four parts, with distinct jobs
Open WebUI
Hosts the conversation, model connection, and Lathe tool code. Open WebUI 0.12+ also coordinates native subagents when enabled.
Lathe
Connects tools to the user's sandbox, manages its lifecycle, and returns results. It does not delegate tasks or manage agents.
Daytona
Hosts the Linux sandbox, filesystem, network policy, and service previews.
Your model
Plans the work and calls tools. Choose a tool-capable model; inspecting images also requires vision support, but showing them to you does not.
This arrangement puts a coding-agent workspace behind a chat interface. It does not make the workspace local or provider-free: Open WebUI, the selected model runtime, and Daytona remain part of the trust boundary.
Native foreground subagents return a result before the parent continues; background subagents let it keep working and return their result later. Open WebUI owns that orchestration. With Lathe, parent and child work in the same user's filesystem, while their Python sessions stay separate.
Watch a real conversation
Lathe v1, captured October 20, 2026: give GLM 5.3 Flash raw repair-café records, start with quick Python analytics, build an HTML infographic from the findings, then say “Serve it up, private.” The sandbox's outbound Internet is blocked. This is real model output, not a scripted answer; review its conclusions before relying on them. Capture evidence · Capture source
Files persist; processes do not
A user returns to the same sandbox across conversations. Files, repositories, and installed packages on its filesystem survive ordinary stops and archives. A new tool call starts the sandbox again when needed.
Running servers, shell processes, and in-memory Python state are lost when the sandbox stops or archives. The default configuration stops an idle sandbox after about 15 minutes and archives it 60 minutes later. Administrators can change these intervals.
Conversation context is separate from sandbox state. Open WebUI handles conversation continuation and compaction; save important project context in workspace files so a new conversation can discover it.
Local file work, Python calculations, and self-contained reports remain useful when sandbox Internet access is restricted. Cloning repositories, fetching data, and installing packages need permitted sources. Open WebUI's model connection is separate from the sandbox's outbound network policy.
A small interface to the sandbox
bash
Run non-interactive shell commands. Long commands continue in the background.
read · write · edit
Inspect numbered line ranges and make explicit file changes.
glob · grep
Find relevant files and search their contents without reading the whole workspace. These tools need ripgrep, supplied locally or from a reachable source.
view
Inspect sandbox images with a vision-capable model: screenshots, charts, and rendered pages.
show
Put images or interactive HTML reports directly in the chat for you, without sending them through the model's context. Tooltips and filters work; the page cannot reach the network.
interpret
Run Python in a chat-scoped REPL whose variables survive between calls.
peek · poke
Observe and operate a shared Linux desktop. Open it yourself to log in, then tell the agent when to resume. Screenshots need a vision-capable model and become part of the conversation.
expose
Open a running service or the shared desktop with explicit private or public access. Prefer private for desktops and logged-in sessions. The agent starts and checks it first.
onboard · lathe
Load project instructions and consult the model-facing manual.
destroy
With confirmation, permanently remove the sandbox and its workspace.
You log in, the agent does the clicking
Some browser chores are tedious but sit behind a login: downloading a year of statements, filling the same form fifty times, checking a dashboard that has no API. The sandbox has a desktop that both of you can reach. The model sees it through screenshots and sends mouse and keyboard input. You see it in a browser tab and use it like any remote desktop.
- Ask for the task and say you will handle the login.
- The model starts the desktop and a browser, goes to the login page, and sends you a private desktop link.
- It stops clicking and taking screenshots. You open the link, confirm your identity if the deployment asks, then sign in to the site.
- Reply “ready” in chat. The model takes a fresh screenshot and carries on.
Your password stays out of the chat, but the logged-in session does not stay out of the agent's reach: anything running in the sandbox can use it. Log in only to accounts you would let the agent act in, and log out or ask the model to close the browser when you are done. The pause during your login is an agreement, not a lock, so watch for unexpected input.
What to ask for
Users describe the outcome. The model decides which tools to call.
- Understand existing work “Read the project already in my sandbox and explain its first failing test.”
- Make a local report “Turn this CSV into an interactive chart with hover details and show it to me here.”
- Share a service “Start the dashboard and send me a private link.”
- Check in parallel “Have one native background subagent audit the local data while you build the report. Read its saved result before finalizing.”
- Learn a working procedure “Walk me through starting and checking this service. Once we've tested it together, ask before saving a reusable skill.”
- Hand off a login “Open the library's site on the desktop and send me a private link. Wait while I sign in, then export my loan history.”
- Continue elsewhere “Save a project summary in the workspace for our next conversation.”
Editors, terminals, and file browsers are optional applications, not bundled Lathe services. They need an existing installation or an approved, reachable source. An administrator may supply an optional public or intranet agent handbook; none is configured by default. This website is the user overview, not that handbook.
With your approval, a proven procedure can become a skill in the sandbox. Fresh conversations can discover and reuse those saved skills alongside project instructions. Lathe discovers existing skills; it does not install an app catalog or automatically save, regenerate, or overwrite procedures.
Know where the work goes
- Sandbox data lives in Daytona. Lathe labels each sandbox with the Open WebUI user's email. Files survive normal stops and archives without an additional persistent volume.
- User environment variables are credentials entrusted to the agent. Lathe injects them into model-directed shell commands. The model can print them, inspect process environments, or read generated command wrappers. Use scoped, revocable credentials.
- Choose the preview's access mode. Every HTTP exposure is explicitly public or private. Private previews require the deployment's authentication wrapper and never downgrade to public. Public previews may use a direct signed bearer URL when wrapping is unavailable, where the request permits it. Upstream access defaults to 24 hours; the tool reports wrapper expiry separately. Sharing access does not keep a stopped service or sandbox running.
- Shown images and reports stay in the chat. Open WebUI saves them with the conversation, and an HTML report runs again each time you open it, isolated from your account and the network.
- Desktop screenshots stay in the chat. Each screenshot the model takes is saved with the conversation in Open WebUI, along with whatever was on screen. A public desktop link lets anyone who has it control the desktop and the accounts logged in there; ask for private.
- Deletion destroys the workspace. Automatic sandbox deletion is disabled by default, but an admin can change that policy. Export important results or commit them to a remote repository before sandbox destruction.
- Updates are manual. Open WebUI stores the uploaded copy of
lathe.py. An installed deployment does not receive fixes merely because the GitHub repository changed, and Lathe has no built-in update or notification mechanism.
Install deliberately
Lathe is a single Python file installed as an
Open WebUI Tool.
It runs inside Open WebUI and receives an account-wide Daytona API key, so
administrators should review the source and record the installed version.
The installed copy reports it through lathe(manpage="version");
administrators can also inspect the source frontmatter's version: field.
The administrator README covers installation, manual updates, valves, security, and verification. The security policy defines support and explains how to obtain security fixes.