Hello, thinslice
Today we're open-sourcing thinslice — a CLI (slice) that binds any git worktree to its own bag of state: a dedicated Postgres database, a Redis instance, a reserved port range, and per-branch config. Switch branches and your entire data environment switches with you. No Docker. No VMs. Just processes.
The problem: agents stepping on each other
Coding agents have gotten remarkably capable, but the moment you run more than one at a time you hit a wall that has nothing to do with AI quality. Agent A migrates the database schema on feature/payments. Agent B, working on feature/auth, picks up those half-applied migrations and fails its tests. Meanwhile a third agent on main has claimed port 5432 and everything is shouting at each other.
The usual answers — Docker Compose per branch, separate VMs, carefully scheduled agent queues — all add friction that slows the feedback loop that makes agents useful in the first place.
Per-branch state as a first-class concept
thinslice treats the worktree, not the machine, as the unit of isolation. Run slice setup once in a repo and it writes a thinslice.toml describing the services your project needs. From that point on, every worktree gets its own slice of the machine: its own port assignments, its own Postgres cluster, its own Redis socket — all tracked in a manifest so slice up can start exactly what that branch needs and nothing else.
The result: you can run your whole product against any branch, simultaneously, on the same laptop. Agents don't share state unless you tell them to.
What exists today
The initial release ships three commands:
slice setup— initialise a repo: scaffoldthinslice.toml, assign port ranges, create the first Postgres cluster and Redis instance for the current worktree.slice up— start all services declared for the current worktree (or a named one). Idempotent: already-running services are left alone.slice tmp --from current— spin up a throwaway worktree with state cloned from the current branch. Designed for agent sandboxes:slice tmp --from current claude -p "…"hands a fresh, isolated environment to a Claude Code session and cleans up after it exits.
What's next
We're working on deeper agent integrations, automatic service health checks before handoff, and a slice down command for graceful teardown. The project is young and we want to hear what workflows you're trying to automate.
Star the repo, file issues, and — if you're running multiple coding agents today — tell us what's getting in your way.