Parlo

Roadmap

Compute mounts (coming soon)

Parlo's planned filesystem interface for servers, GPU jobs, logs, and artifacts.

Parlo already mounts cloud drives and APIs as files. The next direction is compute: servers, GPU workers, jobs, logs, and artifacts exposed through the same filesystem interface.

The goal is not to force provider names into your workspace. The goal is to let humans and agents create named compute workspaces that happen to run on a provider behind the scenes.

bash6 lines
1~/parlo/2  training/          # user-named compute workspace3  gpu-lab/           # user-named compute workspace4  prod-worker/       # user-named server/workload workspace5  datasets/          # cloud drive6  github/            # API connection

A mount can still show its provider metadata:

bash7 lines
1~/parlo/training/2  README.md3  provider.md        # RunPod, Modal, DigitalOcean, Hetzner, Kubernetes, etc.4  machines/5  jobs/6  logs/7  artifacts/

Why user-named mounts

Provider names are implementation details. Most workspaces are named by intent:

  • training
  • evals
  • video-rendering
  • prod-worker
  • gpu-lab
  • scraper-sandbox

Parlo should let the user choose that name, then choose or auto-select the provider based on cost, region, GPU type, reliability, and credentials.

Planned shape

A compute workspace might look like this:

bash18 lines
1~/parlo/training/2  README.md3  status.md4  machines/5    gpu-1/6      status.md7      files/8      logs.txt9  jobs/10    new.yaml11    train-123/12      status.md13      logs.txt14      artifacts/15        model.safetensors16  templates/17    pytorch.yaml18    node-worker.yaml

An agent could then operate with normal file commands:

bash5 lines
1cat ~/parlo/training/README.md2ls ~/parlo/training/templates3cp train.py ~/parlo/training/jobs/train-123/files/4tail -f ~/parlo/training/jobs/train-123/logs.txt5cp ~/parlo/training/jobs/train-123/artifacts/model.safetensors ~/parlo/datasets/models/

Provider choice

Parlo should support both modes:

  1. 1User picks a provider - useful when they already know they want RunPod, Modal, DigitalOcean, Hetzner, AWS, or Kubernetes.
  2. 2Parlo helps pick - useful when the user says “I need a cheap GPU for a training job” or “I need a small Linux box in Europe.”

Either way, the mounted folder should be named for the task, not forced to be the provider name.

bash3 lines
1Good: ~/parlo/training/2Good: ~/parlo/evals/3Also okay: ~/parlo/runpod/ if the user explicitly wants that name

What this unlocks for agents

Agents already know how to inspect folders, read docs, edit files, run shell commands, and follow logs. Compute mounts would let them use that same behavior to:

  • discover available machines or GPU types
  • create a job from a YAML spec
  • upload code or data
  • follow logs
  • collect artifacts
  • move outputs back to a drive
  • coordinate across APIs, storage, and machines

This keeps Parlo's core principle intact: different backends, one filesystem interface.

← Previous

Agent access

Next →

CLI reference