Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt

Use this file to discover all available pages before exploring further.

A Tensorlake sandbox is not only an execution surface for agents — it is also a real development environment you can SSH into from any machine. Open it in VS Code or any Remote-SSH client, work normally, walk away when you’re done. The sandbox idle-suspends on its own and stops charging. Resume tomorrow under the same name and your shell history, installed packages, in-progress branches, running tmux sessions, and ~/.vscode-server are exactly where you left them. Compared to a long-running VM or a traditional cloud-dev product:
  • Portable identity, not portable hardware. You connect to the same sandbox id from any machine. Which region or host the underlying VM lives on is the platform’s problem.
  • Suspend-on-idle, not always-on. Named sandboxes auto-suspend after timeout_secs of no proxy traffic, so you only pay while you are actively connected.
  • Resume preserves state. Filesystem, memory, and running processes all survive suspend. The sandbox id never changes, so your ~/.ssh/config entry keeps working forever.

​
Prerequisites

  • The tl CLI installed and logged in (tl login).
  • An ed25519 (or RSA) SSH keypair on your laptop. Generate one with ssh-keygen -t ed25519 if you don’t have one.

​
One-time setup: register your SSH key

tl ssh-keys add --name laptop ~/.ssh/id_ed25519.pub
tl ssh-keys ls
The key is associated with your Tensorlake user across every project — you only do this once per laptop. See SSH and PTY Sessions for the TENSORLAKE_API_KEY gotcha and other auth details.

​
Create your sandbox

Create a named sandbox so it can be suspended and resumed: 
tl sbx create my-dev --cpus 2 --memory 4096 --disk_mb 25600
Pick CPUs, memory, and disk that fit your workload — language servers, builds, and test runs are usually the limiter on CPU/memory, while toolchains, container images, and dataset checkouts are what fill the disk. --disk_mb is the root filesystem size in MiB; the allowed range is 10240–102400 (10–100 GiB). The name (my-dev) is how you’ll refer to the sandbox in tl sbx suspend/resume commands. Grab the sandbox id — you’ll need it for SSH: 
tl sbx describe my-dev | grep '^ID:'
# ID:              9flad2bnq74qy24wv66ik
The id is stable across suspend/resume, so you only look it up once.
Already have a project image with your toolchain pre-installed (Node, Python, CUDA, your repo’s apt deps)? Pass --image my-image so every new sandbox starts pre-configured. See Sandbox Images.

​
Pick a timeout

Named sandboxes idle-suspend after timeout_secs of no proxy traffic — default 600 seconds (10 minutes). While you are SSH’d in, that clock is paused, so 10 minutes is usually fine. If you want a longer idle window before suspend — e.g. so a brief network blip doesn’t suspend the sandbox out from under you — bump it: 
tl sbx create my-dev --cpus 2 --memory 4096 --disk_mb 25600 --timeout 3600
--timeout 0 requests the plan maximum (24 hours on On-Demand). See Timeout for precise semantics and plan limits.

​
Add an SSH config entry

Replace <sandbox-id> with the id you grabbed above: 
Host my-dev
  HostName sandbox.tensorlake.ai
  User <sandbox-id>
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3
The Host alias (my-dev) is just a local label — pick whatever you like. The User must be the sandbox id; this is what the gateway routes on. ServerAliveInterval keeps the connection healthy across short network gaps. IdentitiesOnly yes makes sure your client only offers the registered key (important if you have several keys in your agent). Test it: 
ssh my-dev
# tl-user@tl-sbx:~$

​
Open it in VS Code

  1. Install the Remote - SSH extension (ms-vscode-remote.remote-ssh).
  2. Run Remote-SSH: Connect to Host… and pick my-dev.
  3. File → Open Folder → /home/tl-user/workspace. That path is writable by the default tl-user account and persisted across snapshots; /workspace is not tl-user-writable in the default image, and /tmp/* is writable but excluded from snapshots.
  4. First connect takes ~30 seconds while VS Code installs its server inside the sandbox under ~/.vscode-server. That directory lives under /home/tl-user, so it persists across suspend/resume — subsequent connects are much faster.
JetBrains Gateway, Cursor, and any other Remote-SSH client work the same way.

​
Day to day

Work normally — git clone, install deps, run your stack. Two things to keep in mind:
  • Long-running jobs vs. SSH disconnect. When your SSH session ends and no other proxy traffic is in flight, the idle clock starts and the sandbox eventually suspends. Suspend preserves running processes, so a tmux job resumes when you do — but it does not make progress while the sandbox is suspended. For unattended work that needs to keep running, raise --timeout, keep a client connected, or use Sandbox Processes (which is designed for fire-and-forget work).
  • Suspend explicitly when you’re done. tl sbx suspend my-dev stops the meter immediately, rather than waiting for the idle timeout to fire.
Resume tomorrow: 
tl sbx resume my-dev
ssh my-dev
The sandbox id never changes across suspend/resume, so your ~/.ssh/config entry and any VS Code Remote-SSH bookmark keep working — there is nothing to update on your laptop, even after weeks of suspend.

​
Next steps

SSH and PTY Sessions

Port forwarding, scp/rsync, PTY API, and troubleshooting.

Lifecycle

Suspend, resume, timeout semantics, and snapshots.

Sandbox Images

Bake pre-installed dependencies and tools into a reusable image.

Networking

Outbound access controls, exposed ports, and tunnels.