The cockpit for
your coding agents.
Agents finish work faster than anyone can spec it. DevPilot keeps a horizon of ready work in front of them — all executing on machines you own.
npm i -g @devpilot.sh/cliWorks standalone with no account. The hosted platform is additive.
- 01Run the fleetEvery agent session on every machine you own, in one cockpit — with the work planned into waves that can run at once.
- 02Let agents coordinateAn encrypted channel two agents can read and write, so they stop routing through a person with a clipboard.
- 03See what it costAgent time, written work and tokens for every session, so you know what a subscription actually bought.
The problem
Coding agents got good.
Running them didn't.
The models write the code now. Directing several of them is a different job — keeping each one fed, keeping them out of each other's way, and knowing what any of it cost — and almost nothing exists for doing that job well.
Nobody is directing them
Four agents in four terminals, each started by hand. Nothing knows which are working, which went quiet ten minutes ago, and which are about to run out of things to do — except you, and only for the one you happen to be looking at.
They cannot reach each other
One agent has already ruled out what another is about to try. The only channel between them is a person copying terminal output into a chat window, so the same ground gets covered twice and two of them end up in the same file.
You cannot see what the subscription bought
A subscription is a fixed amount of model time. Which sessions spent it, how much of that was re-reading context, and what actually changed in the repository are all on your disk — and nothing adds them up.
Fleet control
Every agent you are running, in one place
Connect a machine and the sessions already running on it appear — the ones you started by hand as well as the ones DevPilot dispatched. There is no project to configure and no tracker to connect first.
See what each one is doing
Which tool it just called, which files it has changed, how long since it last did anything. Worked out on your machine from the session’s own record — the cockpit receives tool names, paths and counts, never the conversation.
Know which one needs you
A run waiting at a review gate is stopped until somebody answers it, so it goes to the top. Approve the plan, send it back with constraints, or stop it — from a browser, without being at the machine it is running on.
Take the wheel
A session you started in a terminal is still yours to pick up. Resume it under DevPilot, hand it to the planner, or give it a ticket so the work has a place on the board. It stays on your machine either way.
One command on each machine you own. It reports which sessions exist and what they are doing, and it claims work that is routed to it. Nothing else is installed, and the agents keep running where they already were.
devpilot bridge connectPlanning throughput
Your agents are not the bottleneck. You are.
Seeing the fleet is the start. Keeping it fed is the job. Agents consume specs faster than anyone can write them: add a second agent and you do not go twice as fast — you find out how quickly one person can produce well-formed work. DevPilot is built to make the conductor faster than the fleet.
Plans that know what can run at once
The planning agent returns a dependency graph, not a checklist. Tasks that do not depend on each other, and do not claim the same files, are grouped into waves that dispatch concurrently — each to its own agent, with its own scope.
A branch per task, a merge per wave
Each task runs in its own git worktree, on its own branch. When a wave finishes its branches are merged, and the next wave starts from the result. Two agents that changed the same lines produce a conflict that names the files, not a silent overwrite. Your own checkout is never touched, and nothing is pushed until you push it.
The critical path, computed
A DAG means the longest chain is calculable rather than guessable. You find out which task is holding the release before you start it, not during the retro.
Runway, before you run out
DevPilot estimates how long your ready queue will last and flags a session heading for idle while there is still time to feed it. An idle agent is the one cost that is entirely avoidable.
The work horizon
Everything you intend to build sits in one queue, and moves left to right as it gets more structured. The job stops being “what should I write next” and becomes “is there enough ready work in front of my fleet”.
- 01Directional
A one-liner. Capture first, structure never — this zone exists so an idea has somewhere to go.
- 02Shaping
Feature-level intent, ready for the planning agent to pick up.
- 03Refining
A plan exists and you are reviewing it — waves, model assignments, task sizes, constraints.
- 04Ready
Specced, dependency-resolved, staged. One click dispatches it to the fleet.
You review the plan before anything runs. Once it is approved, each wave starts when the one before it finishes — the fleet does not wait for you to notice. The whole engine is MIT licensed in the open source CLI.
devpilot serveThe Conductor Score
One number, out of a thousand, for how a stretch of fleet work was run — and it shows its working. Each of six dimensions is computed from what your cockpit recorded. A dimension with no data behind it is marked as not measured and counts for nothing, rather than being handed a default.
- Runway health250
Was work kept queued ahead of the fleet?
- Fleet utilization200
How full was the fleet while it was being worked?
- Plan accuracy200
Did tasks sized the same take about as long?
- Cost efficiency150
What was saved against the most expensive model?
- Velocity trend100
Is throughput rising or falling?
- Parallelization quality100
Was independent work actually run at once?
The weighting is an opinion — keeping the fleet supplied with work is nearly half of it — and the method is published with its weak points listed, so it can be argued with. A score from your own machine is a personal reading: you chose the window and declared the fleet’s size. Scores are only comparable when every dimension was measured under the same version of the method.
Efficiency
Know what your subscription bought
A coding plan is a fixed amount of model time. The only thing that varies is how much work comes out of it. DevPilot measures both sides — on your machine, from the sessions’ own records — and puts them next to each other.
- 01Agent time
How long agents were actually working, with the idle gaps taken out. A session left open overnight does not count the night.
- 02Written work
Tool calls that changed a file, and the files they changed. The nearest thing to output that can be seen without seeing your code.
- 03Tokens, counted once
Fresh input, output, and context served from cache, kept apart. Counted per response — a session’s own log repeats each response’s usage several times, and a plain sum overstates it.
- 04Per change
Tokens for each change that reached a file. Comparable across sessions of any length, and the number that should fall when a fleet is run better.
Where the tokens actually go
Very little of a long session is the code an agent writes. Most of it is the session's own context, read again on every turn. So the lever is not shorter answers. It is smaller, better-scoped tasks that carry less context for fewer turns — which is what planning work into waves is for.
That is a claim you can now check on your own work rather than take from us: run the same kind of task both ways and compare what a change cost.
No multiplier on this page. We would rather show you your number than quote you ours, and we will not print a saving we have not measured.
Counts, percentages and paths, nothing else. A reading is how many, how long, how much of a window and which file. It is not what an agent wrote or what it was asked.
Free at every tier. Seeing what your own agents spent is not something to charge for.
How it works
Two steps to see your fleet, a third to hand it work
Setup is a few minutes. The first two steps put every running session in front of you. The third makes handing work to your fleet the same gesture as handing it to a teammate.
- 01
Install the CLI
one-timeMIT licensed and standalone. It runs locally with no account and no network if that is all you want.
npm i -g @devpilot.sh/cliyour machine - 02
Connect a machine
one-timeMint a token in the dashboard and connect any machine you own. The agent sessions already running on it appear in the cockpit, with what each is doing and what it has spent. Register as many machines as you like; each gets its own revocable token.
devpilot bridge connectyour machine - 03
Connect your tracker
one-time · optionalLinear today, and only if you want tickets to start work. Point your workspace at DevPilot and choose which teams can auto-dispatch. Webhooks are HMAC-verified and your API key is encrypted at rest.
hosted - 04
Hand over the work
Assign a ticket and that is the whole daily interaction. The repo on it decides which of your machines takes the job, and the work is queued durably so nothing is lost if a machine is offline.
hosted - 05
The agent works, the ticket hears about it
Your local agent does the job in your checkout. Progress is reported back to the ticket as it goes, and when the run ends the ticket gets a summary of what changed — with the pull request linked if the agent opened one.
your machine
Security
The trust boundary, stated plainly
Agents run on machines you own, and the hosted plane coordinates them. Most tools are vague about what that second part gets to see. Here is exactly what crosses the line, what doesn't, and where the edges are.
The control plane. Sees what work is happening, not the work.
- Which machine takes which job
- Session titles, plans and file paths
- Tool names, counts, time and tokens
Where the work actually happens.
- Your repository and working tree
- Your git and agent credentials
- The agent process itself
What crosses that line is on the left, and listed in full below. There is no code path that moves your repository or the contents of a file.
What the cloud never sees
- File contents, diffs and your working tree
- The conversation — prompts, replies, tool inputs and tool output
- Command lines, environment variables and secrets
- Your git credentials and your agent's API keys
What the cloud does see
- A one-line title and short summary of each session
- Issue, repository, branch and machine names
- Plans: task descriptions and the file paths they touch
- How each plan was made and how it ran, as counts: planner calls and their tokens, how many times a reviewer sent it back (not what they wrote), how many tasks finished first time, and how many of the files they changed the plan had named
- Which tools ran against which file paths, including a path named in a command
- Counts — tool calls, tokens, time — and cost at API rates
- If you install the status line: how full your subscription windows are and when they reset, an estimate of each session’s share of them, cache-miss counts by cause and what they cost at API rates, peak context use, and how many prompts you sent — the count, not the prompts
- Status, progress and pull request links
One edge worth knowing. A session's title is the one its client gave it, or failing that its first prompt, shortened — so a line of what you asked does cross, along with a short summary. Everything after that stays on the machine. If that is more than you want sent, connect with --no-observe and only work you dispatch is reported.
The code graph: opt-in, and off by default
Everything above is what a connected workspace sends. This is the one thing that is only sent if you ask. When an owner or admin turns on the hosted code graph, your machines can sync the names of functions, classes and files in a repository and how they refer to each other — not signatures, comments or any file contents. Until someone turns it on, none of it is sent.
- The name of each symbol — functions, classes, methods, properties, constants, types, imported modules and routes
- Its kind, file, line range, and whether it is exported
- Which symbol refers to which, and on what line
- Each file's path, language and a hash of its contents
- The repository, branch and commit the graph was built from
- Signatures, parameter names or types
- Docstrings and comments
- Function bodies, file contents, diffs
Names are still yours. A function called applyAcmeDiscount says something about your business, and an imported module's name is its path. That is less than source and more than we hold otherwise, which is why it is a switch and not a default.
The server refuses a sync that carries anything outside the list on the left — refuses it whole, rather than dropping the extra fields — and the tables have no column a signature could go in. Turning the feature off deletes what was synced.
Shared sessions: what we relay
When two engineers share a session, their transcript does pass through us — encrypted end to end. The key lives in the fragment of the join link, after the #, which browsers never transmit. What we store is a hash that can neither join a session nor decrypt one, so we relay bytes we cannot read.
- Session title and who joined
- Why it was started, which repository it is about, when it ends
- Message count, size, order, timing
- What any message says
- File paths, diffs, agent reasoning
The label is visible without the key. A link's page and its preview in a chat app show the session's title, why it was started, the repository's name, how many have joined and when it ends — to anyone who has the link, fragment or not. No names and no messages. Keep secrets out of a title.
Sessions are temporary. Each ends after a day unless its starter chose an hour or a week. After that nothing can be joined, read or posted, and the stored messages are deleted.
Two honest caveats. Message sizes and timing leak activity patterns even though content does not — that is traffic analysis, and we would rather say so than imply perfect privacy.
And when a session's agent budget runs out, we post a short notice saying so. We wrote it and we hold no key, so that one line is readable by us. Everything a participant writes is not.
Anyone holding a join link can read that session. That is what lets someone outside your company take part with no setup — and it means a link belongs in a DM, not a public channel.
Per-workspace Linear credentials are encrypted at rest with AES-256-GCM and are not readable by any browser client — the database grant excludes those columns entirely. Machine tokens are stored only as SHA-256 hashes. Row-level security is enabled on every table, and the whole thing is open source, so you can check rather than take our word for it.
Built for work you can trust
The boring parts, done properly
A cockpit is only worth flying if the instruments are honest. This sits between your tracker, your machines and your source — when it is wrong, work vanishes quietly, so the unglamorous guarantees are the ones that matter.
Nothing is lost between systems
Work is committed to the queue in the same transaction as the session record, so a dispatch cannot exist without the work to do it — and an offline machine picks up where it left off rather than dropping the job.
Every webhook is verified
Linear webhooks are HMAC-SHA256 checked with a replay guard. A missing signature is a rejection, never a fallback.
Credentials you can take back
Each machine holds its own token, stored only as a SHA-256 hash. Revoke it and that machine is disconnected on its next request — no cache, no window.
An open wire contract
The protocol ships as @devpilot.sh/bridge-protocol under MIT. Point the CLI at our bridge, or run your own and never depend on us at all.
Pricing
Free where it should be, paid where it costs us
The open source path is complete and permanent. The hosted platform is what you pay for — once there is something to pay for.
Open source
The CLI and local cockpit. No account required.
- Full CLI, MIT licensed
- Local orchestration and dashboard
- The planner and the session tools
- Self-host the bridge if you want one
Team
One cockpit for every machine, the efficiency readings, and the tower.
- Every session on every machine, live
- Efficiency readings for each one
- Shared sessions across machines
- Tracker dispatch (Linear today)
- Hosted code graph — opt-in, early access
Enterprise
For teams with their own compliance constraints.
- Self-hosted control plane
- SSO and audit requirements
- Custom agent adapters
- Direct support
The hosted platform is in active development and not yet billed. Create an account and you will be using it before there is anything to pay. Seeing what your own agents spent stays free whatever else is charged for.
Questions
The things people actually ask
Does my source code ever leave my machine?
DevPilot never uploads it. Agents execute locally, always, and the hosted control plane never clones your repository, holds your git credentials, or sees your working tree. What it does receive is a description of the work rather than the work: a one-line title and short summary for each session, repository and branch names, plans (task descriptions and the file paths they touch), how each plan was made and how it ran as counts (planner calls and their tokens, how many times a reviewer sent it back, how many tasks finished first time and how many of the files they changed the plan had named — the counts, not the planner’s prompt or a reviewer’s words), which tools ran against which file paths, and counts such as tool calls, tokens and time. If you install the DevPilot status line it also receives how full your subscription windows are and when they reset, an estimate of each session’s share of them, cache-miss counts by cause with what they cost at API rates, peak context use and how many prompts you sent — the count, not the prompts. No file contents, no diffs, no command lines, and nothing an agent wrote back. There are two things you can deliberately send. One is the hosted code graph, which is opt-in and off by default: if an owner or admin turns it on, your machines can sync the names of functions, classes and files and how they refer to each other — not signatures, comments or any file contents. The other is a shared session message: if you or your agent paste a snippet into a shared transcript, that text is relayed through us — end-to-end encrypted, with the key in the join link, so we cannot read it. That is a choice you make per message, not something DevPilot does for you.
Do I need an account to use DevPilot?
No. The CLI is MIT licensed and runs standalone with no network and no account, including a local dashboard. The hosted platform adds one cockpit across all your machines, the efficiency readings, shared sessions, and Linear dispatch. It is additive, and the CLI never becomes dependent on it.
What does DevPilot measure about my sessions?
Four things per session: agent time (how long an agent was actually working, with idle gaps removed), written work (tool calls that changed a file, and which files), tokens (fresh input, output, and context served from cache, counted once per model response), and tokens per written change. They are computed on your machine from the session record your coding agent already keeps, and what is sent is the counts and the file paths — not the conversation. If you install the DevPilot status line on a machine, it also reports where your 5-hour and 7-day subscription windows stand (on Pro and Max plans) and an estimate of each session’s share of them — an estimate because the window is your whole account’s, so the machine apportions what it saw move among the sessions it metered, and use from other devices is outside it. It reports prompt-cache misses too, with the cause Claude Code gave for each and what re-writing that context cost at API rates, how full the context got, and how many prompts were sent. Sessions without it show a dash for those, never a zero. An estimate of what the tokens would cost at API rates is shown alongside, labelled as an estimate; on a subscription nobody was billed that amount.
Will DevPilot reduce my token usage?
It will show you what you are using and where it goes, which is the part nobody had. We do not publish a savings figure, because we have not measured one we would stand behind. What the readings do show is where the lever is: on a long session most of the tokens are the session’s own context re-read on every turn, so smaller, well-scoped tasks spend less than one long session doing the same work. Planning work into waves produces tasks of that shape, and tokens per change is how you check whether it paid off on your own code.
When several agents work on one plan, where does the work end up?
On a local branch, and nowhere else. Each task of a planned run gets its own git worktree and its own branch, so agents working at the same time cannot write over each other. When a wave finishes, its task branches are merged into one run branch and the next wave starts from the result; if two tasks changed the same lines, that is reported as a conflict naming the files, and the task is run again on top of the work it collided with. Your own checkout is never touched: no checkout, stash or reset. Nothing is pushed and no pull request is opened. When the run is done you merge, push or delete the run branch yourself. One thing to know: a worktree holds the tracked files only, so if your tests need installed dependencies you tell the runner how to install them.
What is the Conductor Score?
A number out of a thousand for how a stretch of fleet work was run, built from six dimensions: whether work was kept queued ahead of the fleet, how full the fleet was while it was being worked, how consistently the plan sized its tasks, what was saved against the most expensive model, whether throughput is rising, and whether independent work was actually run at once. Each is computed from events your local cockpit recorded. A dimension without enough data is shown as not measured and counts for nothing, so a new install has no score rather than a starting one. The method is published with its weak points listed. It measures how work was run, not whether the code is any good, and a score from your own machine is a personal reading, not a ranking.
What is the hosted code graph, and does it send my code?
It is an opt-in feature, off by default, and it does not send code. If an owner or admin of a workspace turns it on, machines connected to that workspace can sync a graph of a repository: the names of its functions, classes, methods, constants, imported modules, routes and files, where each one is, and which refers to which. Signatures, comments, docstrings and file contents are never sent, and the server refuses a sync that includes anything outside that list rather than quietly dropping it. What it is for is the view only the hosted side has, every machine at once: the cockpit can warn that two agents on different machines are changing connected code, and you can look up what refers to a symbol. That warning is based on a graph as of a particular commit; it is not a detected conflict. It is a premium feature that is free during early access, and turning it off deletes what was synced. We make no claim that it saves tokens or time, because we have not measured that.
Can I connect Claude to DevPilot?
Yes. DevPilot is an MCP server at devpilot.sh/api/mcp. Claude Code connects with a token you mint under Settings → Connect; Claude on the web connects as a custom connector and has you sign in and choose a workspace. A connected assistant can read what that workspace already holds here — machines, sessions, what they cost, and any shared code graph — and nothing else: there is no source code on our side for it to read. An owner or admin can also let it ask a machine to share a repository’s code graph. That is a request, not an action: the machine carries it out only if it has the repository checked out and its bridge was started with --allow-remote-config, which is off by default. Every connection is listed and can be revoked on its own.
Can two agents talk to each other?
Yes, through a shared session. One agent starts it and the other joins by link; both read and write the same ordered, end-to-end encrypted transcript. By default a human stays in the loop — agents read and post when asked. You can let them answer each other for a session, bounded by a message budget and a time limit that the server enforces, after which it drops back to asking first.
Do I have to use Linear?
To use hosted dispatch today, yes — Linear is the tracker that is wired, and we would rather say so than list integrations that do not exist. Jira and GitLab are planned. Nothing else about DevPilot depends on it: the CLI runs standalone, and the bridge protocol is open, so a different tracker is a connector rather than a rewrite.
Which coding agent does it run?
Claude Code today, executed by the orchestrator on your machine. The orchestrator has adapter modes, so other agents can be added — that work happens in the open source repo.
What happens if my machine is offline when an issue is assigned?
The work waits. Dispatches are committed to a durable queue in the same transaction as the session record, so the job is not lost — your machine claims it when it reconnects.
Can I run the bridge myself instead of using yours?
Yes. The wire contract is published as @devpilot.sh/bridge-protocol under MIT. Point DEVPILOT_BRIDGE_URL at any service that honours those shapes and the CLI neither knows nor cares that it is not ours.
How are my Linear credentials stored?
Encrypted at rest with AES-256-GCM. The columns holding them are excluded from the database grant a browser client reads through, so there is no "reveal" control in the dashboard — there is nothing there to reveal.
Who can read a shared session?
Anyone holding the full join link, and nobody else — including us. The key sits in the link fragment, which browsers never transmit, so we store only a hash of it. That is what lets a collaborator at another company join with no setup, and it is also why a link belongs in a DM rather than a public channel. Re-keying a session cuts off the old link, but cannot retract what someone already read. Two things to know. The session’s label — its title, why it was started, the repository’s name, how many have joined and when it ends — shows on the link’s page and in chat-app previews without the key, so keep secrets out of a title. And sessions are temporary: each ends after a day by default (an hour or a week if its starter chose), after which nothing can be read or posted and the stored messages are deleted.
Is this production ready?
The CLI is stable and MIT licensed. The hosted platform is in active development and not yet billed — usable today, and we would rather you tried it and told us what broke than waited for a version number.
Take the controls
The cockpit is open source and runs locally in about two minutes. Connect the hosted plane when you want every machine in one place, a reading of what each session cost, and a channel your agents can share — or never, and it still works.