This branch is 0 commits behind main. Forever.

Never click “Update branch” again.

Your team and your agents edit the same code at the same time, and it just merges. No rebase. No merge queue. No little yellow dot. LVCS runs on your laptop or your cloud VM, peer to peer, so the next time githubstatus.com turns orange, you'll find out from Twitter like everyone else.

Quickstart Watch the demo

macOS and Linux

$ curl -fsSL https://lvcs.sh/install.sh | sh

Windows

PS> irm https://lvcs.sh/install.ps1 | iex

> curl.exe -fsSL https://lvcs.sh/install.ps1 | powershell -c -

~/auth-service · src/auth/token.rsillustrative session

use crate::key::Key;
pub fn validate_token(raw: &str, key: &Key) -> Option<Claims> {
let claims: Claims = decode(raw, key).ok()?;
(claims.exp + LEEWAY_SECS > now()).then_some(claims)
}
pub fn refresh(token: &Token, key: &Key) -> String {
encode(&token.renewed(LEEWAY_SECS), key)
}

agent-aannouncelines 3–6: “return the claims from validate_token”others are on the file, so it waits before it edits
agent-bhold“mid-change on the expiry check”agent-a’s edit pauses; a thread opens on lines 3–6
agent-beditmain · line 5finishes its own edit first
agent-banswer“expiry check is in. take it in a workspace.”the hold is released
agent-aws.forkauth-refactor from maina multiplayer fork with its own directory
agent-aeditauth-refactor · validate_tokencopied on write for lines 3–6 only; main does not see it yet
mayaeditmain · refreshoutside agent-a’s lines, so it reaches auth-refactor live
agent-aws.mergeauth-refactor → mainmerged back range by range
runnerattestcargo test -p auth · passtoken.rs changed, so its action runs; the rest are reused
cichannelci → 3f9a0cenough runners signed the same result
mayacheckpointlvcs checkpointan ordinary git commit of main’s frontier

peers 3 · server noneagent-a may edit src/auth/** · no expiryci 3f9a0c

Actions

CI that doesn't check githubstatus.com first.

Your tests run on your machines, sign what they find, and skip anything that didn't change. Yes, that means fixing a README typo no longer reruns the whole integration suite. Already wrote GitHub workflows? Bring them. LVCS runs the jobs. No runner minutes. No “Waiting for a runner to pick up this job.” No “1 workflow awaiting approval.”

Example board
Channel	Version	Agreed	How it got there	Status
CI	3F9A0C	3 / 3	tests, lint, and build passed on 3 of 3 runners	Moved
STAGING	3F9A0C	1 / 1	runs when ci moves	Moved
PROD	1C07E2	1 / 1	runs when you say so: `lvcs run prod`	Waiting

A channel moves when its runners agree. Not before, and not on "probably fine."

Why

The pull request loop wasn't built for agents.

Push. Wait. “Some checks haven't completed yet.” Fail. “This branch is out-of-date with the base branch.” Update branch. Wait. Run it all again. You've done the dance. Your agents do it all day, in parallel, at full price.

1 in 5of CI hours went to re-running checks after merging main into a branch.

8 in 10of those merges conflicted. Mostly on one generated file.

12 minmedian wait for the first reply to a review comment.

One company, one week. Some reruns earn their keep. Others are a very expensive space heater.

Your agents are in line too. Behind you.

We pulled GitHub's own Actions records (we're thorough like that) for 544 merged pull requests from Copilot, Claude Code, Codex, and Devin across 114 open-source repos, plus 496 from people in the same repos. The 90 days to October 27, 2026.

25 minmedian an agent's pull request spends waiting on CI. One in ten waits over 6 hours.

1 in 7of their CI runs re-test a merge from main. Same as people.

2.3×longer CI waits for Copilot's pull requests than people's in the same repos, mostly for a human to click “Approve and run.” The future is here, and it needs a babysitter.

Agents wait about as long as people do. They just never clock out, never complain, and never get bored of it. Merged pull requests only, so this is the optimistic version.

Meanwhile, at githubstatus.com.

68 Actions incidents in 2026, and it's only October. That's 152 hours of “We are investigating reports of degraded performance.” 19 were critical, a label GitHub used twice from 2019 through 2025, so it's really getting into it now. The chart is GitHub's own data. We just added yellow.

GitHub Actions incidents per year, by GitHub's own impact label

Minor
Major
Critical

* 2026 runs through 2026-10-28. Source: GitHub's status page, githubstatus.com: every declared incident, with GitHub's own Actions component filter (history.json?filter=br0l2tvcx85d) plus incidents whose name contains the word Actions. Hours are declared-to-resolved time. Impact is GitHub's own label. 2020 counts are a lower bound: the Actions component was first used on 2020-04-14.

Show the numbers

Year	Actions incidents	Hours	Minor	Major	Critical	All GitHub incidents
2020	9	21.4	9	0	0	70
2021	41	88.6	34	7	0	86
2022	46	86	39	7	0	123
2023	59	111.7	46	12	1	164
2024	33	61.1	25	8	0	124
2025	48	90	37	11	0	199
2026*	68	152.3	33	16	19	254

The idea

How it actually works.

People and agents use the same protocol for presence, edits, and questions. Nobody gets a special lane. Not even you, sorry.

One live main

Everyone edits the same project, live. Edits are Automerge changes, so they merge the same way on every machine. No branches to babysit, no text conflicts to untangle at 6 p.m. on a Friday.
Workspaces, when you want them

Need to go heads-down? Fork a workspace: cheap, multiplayer, its own directory. It copies only the lines you change and merges back range by range. Like a branch, minus the existential dread.
Heads-up before the collision

Before an agent touches your lines, you hear about it. Say hold and it waits. Politely. Unlike some coworkers.
Actions, not CI on every branch

Each action runs once per version, signs its result, and gets reused until its inputs change. ci moves when runners agree. Other actions can follow it.
Agents are participants, not guests

Authority comes from signed grants that trace back to the project owner, not from having a pulse. Grants are long-lived, so agents can work at 3 a.m. Revoking one is an explicit, signed act.
Git stays git

Your project is still a git checkout. lvcs checkpoint writes a normal commit. Uninstall LVCS and you've got a normal repo. No hostage situation.

How it works

Install it. Forget it's there.

One small program runs wherever you or an agent works. Every machine runs the same one. None of them is in charge.

Your tools still work	Your project's still a normal folder and a git checkout. Save from any editor, script, or agent and everyone gets it.
Nothing to host	Machines find each other on the LAN or across the internet. No server to run, pay for, or refresh a status page about.
Offline is fine	Work on a plane. Sync when you land. Everyone ends up with the same code, which is more than you can say for your last merge.
Heads-up, not surprises	Someone's about to change your lines? You hear first, and you can tell them to wait.
Actions next to the code	Your machines run your actions and sign the results. No queue behind strangers' builds.
Your agents included	A Claude Code plugin, an MCP server for every other agent, and a VS Code extension for the humans.

Docs

Two machines editing live in five commands.

The reference is generated from the code, so it can't drift. Unlike the docs you're used to.

Quickstart

Installed? lvcs --version should print lvcs <version>. It lives in ~/.local/bin, or %LOCALAPPDATA%\Programs\lvcs\bin on Windows (LVCS_INSTALL_DIR moves it). On Windows everything works except running actions; runners are Linux-only.

Then, in a git checkout with nothing uncommitted:

$ cd ~/code/my-project

$ lvcs init     # lvcs init owner=<participant> project=<project-id>

$ lvcs daemon   # lvcs daemon ready peer_id=<PeerId>

lvcs init starts from HEAD. On another machine, join from any peer:

$ lvcs join <project-id> --root ~/code/my-project --bootstrap /ip4/<address>/tcp/4001/p2p/<PeerId>

$ lvcs daemon --root ~/code/my-project

Now edit in either directory with whatever you like. The other machine sees it as it lands.

The ones you'll actually use

lvcs status: where you stand. Mirrors, grants, open holds and asks, unread notifications, peers, and the last thing that went wrong.
lvcs explain <value>: what an error code, rule, or notification means, offline. Hand it a path and it tells you how LVCS sees that file.
lvcs key new: a new participant key. Every agent gets one.
lvcs ws fork <name> and lvcs ws merge: go heads-down, then come back.
lvcs ask, answer, hold, and say: talk to whoever is in the same lines.
lvcs checkpoint: write main as a plain git commit.
lvcs run <action>: fire a manual action, like a release.
lvcs audit: check every change's signature and grant. lvcs replay --check: replay the journal and prove it.

Every refusal tells you why and hands you the exact command that fixes it. Stuck anyway? lvcs status.

Actions

CI is just actions plus channels. Each action is an [[actions]] entry in the project's protected lvcs.toml: one argv, one step, no shell.

[[actions]]
name  = "auth"
paths = ["src/auth/**"]
uses  = ["src/token/**"]
run   = ["cargo", "test", "-p", "auth"]

[[actions]]
name  = "staging"
on    = { channel = "ci" }
paths = ["src/**", "scripts/**"]
run   = ["sh", "scripts/push-staging.sh"]
secrets = ["STAGING_TOKEN"]

[[actions]]
name  = "release"
on    = "manual"
run   = ["sh", "scripts/release.sh"]

An action runs on change (every merge into main, the default, and what moves ci), on { channel = "<name>" } (when that channel moves), or on manual (lvcs run <action>). Each action's results move its own channel, named for the action.

Agents

Claude Code: the plugin's hooks call lvcs hook <event>. Before each edit, everyone in that range hears about it, and holds come back.
Everything else: lvcs mcp --as <participant> serves the API as MCP tools.
Notifications are metadata only. Nobody's text lands in an agent's context until it asks for it with lvcs notifications read.

Reference, generated from code

The demo

Seven agents walk into one file.

Seven agents build Pulse, an uptime monitor, from an empty repo and a spec, across four machines and zero servers. The work is picked so they collide in the same lines. Nobody scripted their edits. Pulse's own GitHub workflow runs as LVCS actions, and its own tests keep score. No pull requests were opened in the making of this film.

agents: 7
machines: 4
servers: 0

Git wasn't designed for agent velocity. LVCS in 75 seconds: agents editing one codebase together, CI on machines you already run, and actions that run on conditions. No sound.

In the film

0:00 The problem
0:10 What LVCS is
0:18 Agents edit together
0:31 Hosted CI goes down
0:39 CI on machines you already run
0:52 Actions run on conditions
1:06 Install

Never click “Update branch” again.

Install

macOS and Linux

Windows

CI that doesn't check githubstatus.com first.

The pull request loop wasn't built for agents.

Your agents are in line too. Behind you.

Meanwhile, at githubstatus.com.

How it actually works.

One live main

Workspaces, when you want them

Heads-up before the collision

Actions, not CI on every branch

Agents are participants, not guests

Git stays git

Install it. Forget it's there.

Two machines editing live in five commands.

Quickstart

The ones you'll actually use

Actions

Agents

Reference, generated from code

Seven agents walk into one file.

In the film