Gitslice is Git-compatible source infrastructure where agents get a workspace for the task, land changes without stepping on each other, and the server, not the agent, decides what merges. Slices give each one its part of the codebase.
Install the CLI: curl -fsSL https://gitslice.io/install.sh | sh
Are you an agent? Sign yourself up with no browser: gs auth register-agent. Read /llms.txt or the agents guide.
Open source: Gitslice is built on Gitslice. Browse gitslice/gitslice.
$ gs auth register-agent --username build-bot \
--email mira@orbit.dev
Registered build-bot; claim link sent for mira@orbit.dev
$ gs init --lazy orbit/checkout work
mounted orbit:checkout at ~/work (318 files, fetched on first read; edits stay on this machine until gs create)
$ gs create --all --submit \
--message "Tighten authorization"
created 8b4ee46085 patchset 1
view: https://gitslice.io/cs/8b4ee46085
waiting for required check "orbit/unit" to pass...
submitted 8b4ee46085
Why Gitslice
0 retries
16 agents, one codebase
Git moves the branch under every agent that lands, so each one pulls, rebases and pushes again. Gitslice admits a change by the paths it changes, so agents on different files never wait on each other, and edits to the same file are merged on submit.
2.6 s
to mount 4,508 files, cold
Mount a slice and start. Only the files an agent reads are fetched, so the cost follows the task, not the size of the repository; a walk of the whole tree is read ahead of. Checkpoints save the work in progress on the machine, to rewind to or fork.
How lazy workspaces workEnforced
checks and approvals, on the server
An agent can claim anything. What lands is decided where the commit is made: path by path, against the slice's checks and approvals, with every iteration kept as an immutable patchset.
Measured, not claimed
Agents each make a change, then all of them land at once. With Git, every push that loses the race is a retry: 28 at eight agents, 120 at sixteen. With Gitslice there are none, even when they edit the same file. At eight agents on one file, Git is still faster.
Medians of a benchmark you can rerun, on a 2-vCPU VM. The Git remote is a local directory, so its retries are as cheap as they get. Where Git is faster, the full benchmarks say so.
| Scenario | Agents | Git: time | Git: retries | Gitslice: time | Gitslice: retries |
|---|---|---|---|---|---|
| Each agent edits its own file | 8 | 1.4 s | 28 | 1.2 s | 0 |
| Each agent edits its own file | 16 | 5.3 s | 120 | 2.4 s | 0 |
| One file, a block each (merge on submit) | 8 | 1.4 s | 28 | 1.8 s | 0 |
| One file, a block each (merge on submit) | 16 | 5.4 s | 120 | 3.5 s | 0 |
Everything else, built in
Source, policy, review and automation share one graph, so nothing has to be reconciled between tools—and nobody has to carry the whole thing.
When a change's base moved while an agent worked, the server merges it onto the latest base instead of sending the agent back to start over. Overlapping edits are still refused, with the files named.
Repo-like views of one global source graph. Give each agent the part it owns, with its own access and rules, without splitting the history apart.
Mount a slice in seconds and fetch files as they are read, so the cost follows the task, not the repository. Edits stay on the machine, with checkpoints to rewind to or fork, until the agent creates a changeset.
Required checks and approvals are conditions of landing, not habits. CI runs on any machine with Docker, with build images cached between runs.
Agents register themselves with no browser, work through the gs CLI or an MCP server, and leave an audit trail of changesets and patchsets.
Clone and fetch a slice with plain Git, and push to create a changeset. Compatibility stays at the boundary while the native graph is the source of truth.
