How it works
LoadShift splits Claude Code in two. The part that thinks, and holds your login, stays on your computer. The part that does the work moves to a machine with more cores and memory.
What runs where
| On your computer | On your LoadShift machine |
|---|---|
| Claude Code, your subscription and login | Every command Claude runs in its Bash tool |
| Your project files, and Claude's Read, Edit and search tools | A synced copy of your files, without .git |
git and gh, with your own login | node_modules and other dependency and build folders |
Your browser at localhost | Dev servers, Docker, databases, test runners |
| MCP servers you've configured | Nothing of yours: no repo history, no credentials |
Commands
loadshift claude starts Claude with CLAUDE_CODE_SHELL_PREFIX pointing at a small wrapper. loadshift codex adds a Codex hook that rewrites each shell command to go through the same wrapper, and loadshift opencode makes the wrapper OpenCode's shell. When the agent runs a shell command inside your project, the wrapper sends it over SSH to the same folder on your machine, streams the output back and returns the exit code. If Claude changes directory, the new folder is copied back so the next command starts in the same place (Codex and OpenCode pass the folder with each command). Stopping a command stops it on the machine too, along with everything it started.
git and gh commands are the exception: they run on your computer, in your real repository, with your own credentials. Commands outside the project, and the MCP servers Claude launches, keep running on your computer too.
Files
Your project stays on your computer. Mutagen keeps a copy at the same absolute path on the machine, for example /Users/you/code/app (or /home/you/code/app on Linux) on both, so paths in error messages and stack traces work everywhere. Before each command, the wrapper waits until the machine has Claude's latest edits; after it, until your computer has whatever the command wrote. When the sync is idle that takes a few milliseconds.
.git is never copied, so the machine has no repository history and no credentials. Dependency and build folders (node_modules, .venv, target, .next and similar) aren't copied either: they're built on the machine and stay there. Nor is anything your .gitignore leaves out, such as local databases and build output, except .env files, which are always copied. If both sides change the same file at once, your computer's version wins.
The sync travels inside your SSH connection, like everything else.
Ports
A background helper watches for programs listening on the machine. Within about two seconds of a dev server starting on port 3000, localhost:3000 on your computer reaches it, through the same SSH connection. When the server stops, the forward goes away.
Elastic machines
Each machine is a virtual machine (Cloud Hypervisor) on a large dedicated server. It sees its full ceiling of cores and memory at all times:
- CPU: idle cores use nothing on the server, so a quiet machine costs almost nothing and a busy one gets every core up to its ceiling.
- Memory: the machine hands memory it isn't using back to the server (free page reporting), so its footprint shrinks after a big build.
- Fair share: every machine gets an equal share of the server when it's busy, so one person's build can't starve everyone else.
Usage is measured from what each machine actually consumes: CPU time and resident memory, sampled every few seconds.
What Claude notices
Very little. loadshift starts the agent with a short note (nothing is written into your project) saying the shell is Linux, so it uses GNU tools rather than macOS ones (sed -i, not sed -i ''). It also says that git and gh run on your computer, so it runs them as commands of their own rather than chained with a build or test.