Everyone's shipping with Claude now. shiploop gets you more from what you pay.
Every repo in your product.
One terminal.
Setup wraps your existing repo instead of absorbing it. Your code moves into a subfolder
but stays its own git repo with its full history, and the path you cd into
does not change. Add the rest of the product's repos beside it and you drive all of them
from one session.
Everything the harness adds alongside your code is plain text you can read and edit: one config file, one queue, one git-tracked memory file.
Work runs in parallel,
and never on top of itself.
Every piece of work you name gets its own git worktree, cut from an up-to-date main, and a fresh headless session inside it. Workers cannot collide and nothing inherits prior bad state.
the same way
They are never put on the same file
Naming several partitions them into locality groups by measured file overlap first. In-scope sub-repos get a named branch; the rest are checked out detached and read-only, so a worker can look without touching.
A failure leaves the worktree standing
So a retry resumes in it instead of re-cloning and re-exploring. It is removed only after the work lands, and never while it still holds unpushed commits.
Parallel buys throughput, not efficiency
Four groups at a time by default, and more workers cost more, not less. Naming exactly one always collapses to sequential. The savings come from the levers below, not from the fan-out.
Built to spend
fewer tokens.
One goal: minimize tokens per shipped work. These are the levers that materially change that outcome, and every one of them is on the moment a worker starts.
Start on the cheapest capable model
Work starts on the lowest tier that can plausibly do it, and escalates only after a clear failure. Failed attempts are usually far cheaper than successful ones, so a cheap first pass reduces average cost without compromising difficult work.
The worker session is stripped
No slash commands, no personal settings, no MCP servers, and only the tools the work actually needs. Every unused schema is dead weight re-sent across roughly 218 turns. Trimming the tool list alone cuts tool bytes by 66.7% and the whole request by 34.5%. PROOF.md
Routine changes are handled by code, not a model
Flip a default, add a key, bump a version, apply a known rename. Those are detected during the survey shiploop already runs, then applied and verified deterministically. Anything ambiguous or unsafe falls back to a worker automatically.
Successful output never enters the transcript
Everything in a session is re-sent on every turn that follows, and test output is most of what a worker generates. A green run carries no information, so it never enters. Failures come through trimmed to the useful part.
A watchdog cuts sessions that loop or stall
A stuck worker is killed the moment its transcript shows the pattern, and hard budgets cap every worker and every run.
One codebase map, shared by every worker
Plain scripts index the repo before anything is dispatched, so no worker pays to learn the same layout again.
A retry resumes instead of restarting
The worktree survives a failure, so attempt two inherits the first attempt's findings instead of re-exploring.
Memory improves without growing
What a worker learns is written back for the next one, but lessons are length-capped and the file has a budget.
Some work is blocked before it begins
Dependencies, repository health, capacity and duplicate fixes are checked first. Work that cannot succeed never consumes a worker.
Overlapping work explores the area once
One worker takes several pieces whose measured file paths overlap, so it explores that area once instead of once each.
Tokens are the currency. Because the orchestration is deterministic bash, deciding what to do costs nothing at all. Only the work itself spends.
A harness,
not a compressor.
caveman, rtk, and headroom are three good token savers for coding agents, and they share one shape: they shrink the bytes flowing through a session. shiploop works a layer above. It decides which work runs at all, on which model, with which context. Different layer, different math.
| caveman | rtk | headroom | shiploop | |
|---|---|---|---|---|
| what it is | skill + proxy | bash-output proxy | compression proxy | harness |
| what it optimizes | what the model says and reads | command output | everything passing through it | the work itself: model, context, parallelism |
| model choice | yours, unchanged | yours, unchanged | yours, unchanged | cheapest capable, escalates on failure |
| parallel work | no | no | no | default, in isolated worktrees |
| routine changes | a model call | a model call | a model call | handled by code, zero tokens |
rtk and headroom are proxies, so they stack under shiploop if you want both layers. Run them together; the savings compound.
Point it at a product
you already have.
Nothing to configure first and nothing to migrate. Setup wraps your product in place, detects your sub-repos, ports, dev commands and package manager, and asks everything it needs in one batch.
Global. Every Claude Code session gets the commands from then on.
Once per product. An existing repo is wrapped in place; a folder of repos, or an empty one, gets a new scaffold.
Your repo moves into a subfolder but stays a separate git repo, history verified
byte-for-byte, your cd path unchanged. Your README, CLAUDE.md, config and
governor files are never overwritten without --yes, and setup writes .wrap-undo.sh before it wraps anything.