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.
The control plane. Sees metadata.
- A signed webhook from your tracker
- Which machine takes the job
- Status, progress, cost
Where the work actually happens.
- Your repository and working tree
- Your git and agent credentials
- The agent process itself
Nothing crosses that line except the metadata on the left. There is no code path that moves your repository — the full list is below.
The problem
Coding agents got good.
Running them didn't.
The models write the code now. Directing several of them is a different job — getting work to the right one, keeping it on hardware you control, and knowing what any of them did — and almost nothing exists for doing that job well.
Your code has to go to the agent
Cloud agents need a copy of your repository and somewhere to put your credentials. For regulated, air-gapped, or contractually restricted work that is not a trade-off — it is a wall.
One agent, one terminal, one repo
Nothing routes work across the machines you already own, and nothing keeps two agents from solving the same thing twice. Your workstation idles while the backlog grows, because there is no way to hand a ticket to it.
The tracker never finds out
Work happens in a terminal nobody else can see. Tickets go stale while the branch moves, and status updates stay manual — so they do not happen.
Planning throughput
Your agents are not the bottleneck. You are.
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 assembles live fleet context — which sessions are active, which files are locked in flight, what capacity each repo has — and returns a dependency graph, not a checklist. Independent tasks are grouped into waves that dispatch concurrently.
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 tracks how long your ready queue lasts at current fleet velocity, 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 — model assignments, estimates, constraints.
- 04Ready
Specced, dependency-resolved, staged. One click dispatches it to the fleet.
When every task in a wave finishes, the next wave stages itself — the fleet does not wait for you to notice. Planning runs through Claude Code's plan mode, and the whole engine is MIT licensed in the open source CLI.
devpilot serveHow it works
Three steps once, then you are conducting
Setup is a few minutes. After that, handing work to your fleet is 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. Register as many as you like; each gets its own revocable token.
devpilot bridge connectyour machine - 03
Connect your tracker
one-timeLinear today. 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 PR opens
Your local agent does the job. Progress is commented back as it goes, and the issue closes with the pull request attached.
your machine
Security
The trust boundary, stated plainly
Most tools are vague about this. Here is exactly what crosses the line, what doesn't, and where the edges are.
What the cloud never sees
- Your source code
- Your git credentials
- Your agent's API keys
- Your working tree
What the cloud does see
- Linear issue title and identifier
- Target repository name
- Session status and progress
- PR URL, token count, cost
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. We store a hash of it and nothing more, so we relay bytes we cannot read.
- Session title and who joined
- Message count, size, order, timing
- What any message says
- File paths, diffs, agent reasoning
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
- Runs offline — no network, no account
- Self-host the bridge if you want one
Team
Hosted dispatch, a shared fleet, and shared sessions across machines.
- Tracker dispatch (Linear today)
- Multi-machine routing
- Shared sessions across machines
- Org accounts and revocable tokens
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.
Questions
The things people actually ask
Does my source code ever leave my machine?
DevPilot never uploads it. Agents execute locally, always: the hosted control plane receives the Linear issue title, identifier, target repo name, and status updates — it never clones your repository, holds your git credentials, or sees your working tree. Nothing in the dispatch path moves source. The one thing you can deliberately send 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 Linear dispatch, routing across multiple machines, shared sessions, and a shared team view. It is additive, and the CLI never becomes dependent on it.
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.
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 tracker dispatch, a shared fleet and shared sessions — or never, and it still works.