Distributed jobs, with a clear trail
Send long scientific runs to the right compute, keep working, and bring every result back.
Levin gives plugin-backed jobs one lifecycle across this Mac, an SSH-connected GPU host, or a pool of equivalent deployments. A launch returns a durable Job ID; scheduling, status observation, cancellation, recovery, and artifact collection continue outside the chat turn. That means a long model run can outlive the message that started it without becoming invisible.
One execution model
A Job keeps the same identity from launch to result
Background-capable plugins declare a launch tool, status tool, cancel tool, compute class, and artifact policy. Levin turns that declaration into one host-owned record instead of asking each model or plugin to invent its own tracking behavior.
- 1
Choose a local runtime or an available remote deployment.
- 2
Track status and progress without holding the conversation open.
- 3
Inspect, filter, cancel, and bring a Job back into Chat.
- 4
Materialize declared results with their execution evidence.
| Lifecycle | What Levin knows | What you see |
|---|---|---|
| Queued / launching | The selected deployment, queue position, capacity class, staged workspace, and Job ID. | A queued Job that can still be cancelled before compute starts. |
| Running | Provider status, elapsed time, progress, logs, and the device bound to the run. | Live progress while Chat remains available for other work. |
| Terminal | Completed, failed, cancelled, interrupted, or timed out, with a recorded end time. | A stable outcome, error detail, and any captured artifacts. |
| Needs attention | Status observation failed, the provider is unreachable, or its report became stale. | An attention state without falsely changing the underlying Job to failed. |
Queue work where it fits
Levin separates execution from conversation. Inputs are staged for the selected runtime, and the Job keeps that route for status checks, cancellation, and result transfer. When several equivalent remote deployments are configured, Levin favors available capacity and rotates work across equally loaded targets.
| Target | Scheduling | Isolation |
|---|---|---|
| This Mac | The plugin runtime supervises a detached process and returns control after launch. | The Job is scoped to its plugin workspace and host-managed output directory. |
| Remote Worker | The authenticated worker accepts the Job into a durable per-capacity queue. | Only the client that submitted a Job can read its status or request cancellation. |
| GPU pool | The worker detects NVIDIA devices and assigns the number of GPUs declared by the tool. | Allocated GPU indices are exclusive to that Job until it reaches a terminal state. |
| CPU class | CPU and network-only tools use their own concurrency-limited queue. | They do not consume GPU slots or wait behind GPU work. |
The scheduler distributes plugin-backed Jobs across configured runtimes; it is not a general container cluster. A plugin must declare the background lifecycle, resource needs, and output contract before Levin can manage it this way.
Let the client watch in the background without spending Agent tokens
After launch, the client calls the declared status tool and writes observations into the execution ledger. Waiting and status refreshes run without model turns, so they do not spend Agent tokens. Goals and subagents can suspend on Job dependencies; only after a Job finishes and reasoning resumes does the Agent use tokens again.
- Launch once. Levin issues the Job ID before calling the provider; a repeated launch with the same ID returns the existing Job instead of duplicating expensive work.
- Let the client observe. Status, progress, elapsed time, errors, and runtime details update in the background without invoking the model or spending Agent tokens.
- Coordinate several Jobs. Waiting work can continue after all tracked Jobs finish, after any one finishes, or stop early on a terminal error.
- Resume with evidence. A waiting Agent checks the status tool and recorded artifacts before reporting the outcome.
Recovery is part of the lifecycle. Levin restores monitors after reconnection or restart. If an MCP status call is unavailable, a remote status snapshot can reconcile the ledger. A known terminal outcome remains authoritative; when no trustworthy outcome survives, the Job is marked interrupted rather than guessed.
Review every run in the Jobs registry
Open Jobs from the Chat toolbar for a project-scoped view of active and historical runs. Search by Job, tool, provider, path, or artifact; filter by running, successful, failed, or cancelled state; then open a row for the user-facing result or the technical record.
| Action | What it does | When to use it |
|---|---|---|
| Inspect | Shows progress, source tool, runtime, timestamps, errors, and recovery details. | Confirm where a run is executing or diagnose a failure. |
| Cancel | Records a cancellation request and delivers it to the declared cancel tool. | Stop queued or running work that is no longer needed. |
| Add to Chat | Adds a structured Job reference without embedding every output file. | Ask Levin to compare, continue, or explain an earlier run. |
| Open result | Previews a file, reveals its folder, or opens a supported structure in Mol*. | Move from execution history to the scientific result. |
Cancellation is cooperative and best effort. The Job remains visible as cancelling until the provider confirms a terminal state.
Bring results home with provenance
A completed Job publishes a manifest of outputs. Levin validates the manifest, materializes remote results into a managed local run directory, and attaches them to the same execution record. The registry separates useful results from original inputs and technical diagnostics, so a report is not buried among logs.
| Artifact | Examples | Recorded context |
|---|---|---|
| Results | Designed sequences, structures, score tables, plots, and reports. | Title, summary, path, type, size, and producing Job. |
| Inputs | Staged PDB or mmCIF files, sequence sets, and parameter files. | The source material used by that exact run. |
| Diagnostics | Logs, checkpoints, manifests, and debug output. | Evidence for verification or failure analysis. |
Owned paths still pass Levin's path authorization checks. Missing or changed files are marked in the registry, and remote transfer directories are released after results are captured without deleting active Job data.
Run a distributed batch from Chat
Example request
Run three ProteinMPNN designs for this structure with different temperatures. Use the connected remote GPU devices, keep the runs parallel where capacity allows, and wait for all three. Then compare the returned FASTA and score reports and add the best result to this project.
- Choose the capability. Use a plugin whose launch tool declares a background Job lifecycle.
- Choose compute when it matters. Select a connected device with
@, or let Levin route an equivalent configured deployment. - Define the batch and finish condition. State the inputs, variants, whether all or any Job must finish, and how to compare results.
- Follow it in Jobs. Continue working while the registry reports queue position, progress, runtime health, and terminal outcomes.
- Use the evidence. Open or cite the captured artifacts, then let the Agent verify them before continuing the workflow.