Execution Contexts

English · 简体中文

Execution Contexts

An execution context is a place Wisp can run code. Local is always available. You can add WSL distributions and SSH servers, and then send work to a GPU box without leaving the conversation.

Managed from Settings → Environments, which owns adding, importing, removing, configuring and probing. It does not control which server a given conversation may use — that is separate, and deliberately so.

---

The three kinds

Kind	Notes
Local	Always present, never needs configuring.
WSL	Windows Subsystem for Linux distributions, importable as contexts.
SSH	A remote server, reached through a registered alias, user, port and key.

Each context can point at its own Python and R interpreters. local, a WSL distro and each SSH server can all use different environments, with no host environment variables involved. Set them in Settings → Environments, or let the agent do it with set_runtime_interpreter; the Configure path action on a runtime card opens the same settings.

---

Two gates you will meet

Wisp puts two deliberate obstacles between a model and your servers. Both exist because a wrong guess against a real cluster is expensive.

1. A host must be probed before it can be used

Probe runs the bundled probe-compute-environment skill and persists what it finds: hardware, scheduler, runtimes, privileges. An SSH probe does every check over one authenticated connection.

Enabling a host that has no known-good probe opens a dialog asking you to check the server and probe first. This is not a warning you can wave through — the agent cannot use an unprobed host.

2. A server must be selected for the conversation

Registering a server does not grant access to it. Each conversation selects which remote servers it may use, from the composer's Compute menu. The selection is isolated per conversation. Local compute is always available and always listed; the searchable menu only shows configured remote servers.

Selected servers are preferred for suitable work — that is how you steer heavy jobs onto the GPU box without saying so every time.

---

Runs: work that outlives the conversation

run_in_context submits a job as a Run. A Run is a persisted record, not a blocking call:

• It survives a disconnect. Close the laptop; the job keeps going.
• Progress is model-free. monitor_run streams live progress cards without round-tripping through the LLM, so watching a 6-hour job costs no tokens.
• get_run fetches status and captured output; cancel_run stops it.

transfer_between_contexts moves files between local and remote, or between two remotes.

The remote-compute-ssh skill covers submitting recoverable Runs in practice.

---

SSH specifics

Authentication is either an SSH key/agent (recommended) or a password. A password is stored only in the OS keyring — never in the project database.

Batch SSH and SCP always set OpenSSH IdentitiesOnly. If you use a non-default agent key, configure an IdentityFile in Wisp or in your SSH config, or the connection will not use the key you expect.

Free-form ssh and scp inside the shell tool are disabled. Remote work always goes through the registered alias. This means a model cannot improvise a hostname, a user, or a port.

Failures do not auto-retry. When a probe, upload or launch fails, Wisp opens a connectivity gate on that host: further managed attempts fail immediately without contacting the server, and a warning appears. Clearing it requires a manual probe after you have fixed the connection. This is intentional — a retry loop against a server that is down or rejecting auth is how you get locked out.

---

Known boundaries

• Modal is not supported as a compute backend. The remote-compute-modal skill exists to explain the boundary and migrate a Modal workload to a supported SSH Run.
• Managed model endpoints have their own boundary; managed-model-endpoints explains what is and is not integrated before you plan around it.
• Wisp never installs R packages automatically. Python gets a uv venv at .wisp/python/.venv; R uses Rscript from PATH and needs jsonlite present in that environment already.

---

Inspecting a live environment

Clicking a runtime's Python or R label opens an RStudio-style in-memory environment table beside the runtime cards — object names, types, values and shapes, sizes, all bounded. Pin it and the table moves onto the conversation as a draggable window that stays available after the runtime dialog closes.