Launched this week
ADE
All your coding agents, synced everywhere, free forever
87 followers
All your coding agents, synced everywhere, free forever
87 followers
Use any coding subscription you already pay for, in one synced app that runs on web, desktop, terminal, and mobile. All your chats stay synced between all ade surfaces. Run agents from your laptop, continue the conversation from your phone at dinner, then later finish it off from another computer by simply using the web client. All subs, all in one place. Fully free and open source!
ADE
The multi-device sync model is what caught my attention — having one session carry across web, desktop, and mobile is the hard part of any self-hosted tool, especially when agents are mid-task. Curious about the auth layer: since you can deploy it yourself and chat history syncs across devices, does the self-hosted version keep everything on your infra with no external calls, or is there a relay or cloud component for the mobile sync? Also wondering how the iOS client handles auth token storage given how aggressive iOS background app management is.
ADE
@hi_i_am_mimo Direct self-hosted use stays on your machines. You can pair with QR/PIN and connect over LAN or Tailscale without an account or ADE relay (which I manage and host for free). Without ADE relay you can still easily connect to all of your devices, without using my infra, via Tailscale or simple LAN connections.
On iOS, the pairing secret lives in Keychain, and the device also uses a device bound DPoP key to prove each connection. Account tokens for Relay are refreshed in memory and aren’t saved with the machine profile. iOS backgrounding doesn’t need to keep an agent alive,the agent keeps running on your machine, and the phone reconnects/refreshes when it returns. I would love to hear any feedback you have on using ADE!
ADE
@thys_beesman Great question. Each agent gets its own worktree and branch, so they can work independently without modifying each other’s files. ADE also shows overlap/conflict risk between lanes and uses git’s normal protections like force-with-lease, so a stale force push should fail instead of silently overwriting newer remote history.
It is not trying to magically solve every shared history problem though. If two agents are intentionally operating on the same branch, or both changes need to land in main, that still needs review and a merge/rebase like normal git. ADE helps surface drift and overlapping files before that point, but I still want the human in control of the final merge.
For mobile, you can inspect diffs file by file, stage/unstage, see conflicts, commits, and PR state, but I would not pretend a phone replaces reviewing a large complex PR on desktop. The goal is to make the small but important “agent needs me right now” moments easy from anywhere.
The syncing part is what caught my attention. Most of the agent tooling I've tried assumes one machine, so moving between a laptop and a desktop means rebuilding context from scratch every time.
What actually travels in the sync — just config and sessions, or the accumulated context the agent has built up about a codebase? The second one seems much harder to keep consistent if I have uncommitted local changes on one machine and not the other, so I'm wondering how you draw that boundary.
ADE
@ark_y_k ADE syncs the agent session itself: chat history, messages, running state, approvals, terminal output, lane metadata, and the context the agent has built up through that conversation. So if you leave a session on your laptop and open ADE on your desktop or phone, you are looking at the same live session instead of starting from scratch.
What ADE does not do is silently sync your entire repo or uncommitted working tree between machines. Git is still the source of truth for code. If you have local uncommitted changes on one machine, those stay on that machine, but you can always connect to that machine’s runtime and continue the agent session remotely.
@arul28 That's a much wider sync surface than I assumed — I was picturing config and sessions, not running state and approvals.
Approvals are the piece I keep turning over. If I approve an action on my laptop and the same session is open on my desktop, the approval has effectively travelled to a machine I'm not sitting at. That's exactly what you'd want for continuity, and also the one thing you'd want to be certain about. Is an approval scoped to the session or to the device that granted it? And if both machines are live on the same session at once, does one win, or do they both keep running?
ADE
@ark_y_k The agent only runs in one place. The machine's runtime is the boss, and your laptop, desktop, and phone are all just controllers looking at it. Nothing runs twice, so there's no "both keep running" problem. It's one live session with a few windows into it.
So an approval is tied to the session, not the device you approved from. Approve it from anywhere and it resolves once. The pending state clears everywhere, and the badge on your phone drops even though you tapped Approve on the Mac.
And since there's only one boss, having both machines open at once isn't a race. Neither one wins. They're both just watching the same session, and only the runtime writes state. Let me know if ADE is able to help you with your agentic development.
the "worktrees so agents run in parallel without stepping on each other" part is the piece I'd want to stress test. isolated worktrees solve the during-execution conflict, but eventually those branches have to merge back into the same main. does ADE do anything to flag when two agents touched overlapping files/dependencies across worktrees before you go to merge, or is that still on you to catch in review like any normal set of parallel branches would be?
ADE
@galdayan ADE does flag this before merge. It continuously compares lanes for overlapping changed files and runs a merge-tree conflict check when there is overlap, so you can see low/medium/high conflict risk and which files are involved before trying to land the branches.
It is not pretending it can perfectly understand every dependency level conflict though. Two agents can change different files but still make incompatible product or architectural decisions, and that still needs normal review. The goal is to catch the obvious mechanical conflicts early, make the risky lanes visible, and give you a better place to decide what should merge first.
syncing every coding subscription and chat history through one middle layer is convenient but it's also now holding the keys to all of them at once. if your sync service gets compromised, is the exposure limited to session tokens for each connected tool, or could someone pull full account credentials for the underlying subscriptions?
ADE
@omri_ben_shoham1 Totally fair concern. Your coding provider logins stay on the machine running the agents, usually through the provider’s own CLI/OAuth session. They are not copied into synced chat history or sent to another device as part of normal sync.
The Relay is a transport layer for connecting your devices back to your ADE machine. It does not become a central store of all of your provider credentials or chat history.
Congrats on the launch! Picking the same session back up on a different device is the part I did not know I wanted. When you come back to it on your phone, does it show you what the agent got up to while you were away, or do you scroll back and piece it together yourself?
ADE
@terminal_candy Thank you! When you come back on your phone, you open the same session with the same chat history and current agent state, so you can see the messages, tool output, approvals, and whether it is still running or waiting on you. Basically it's the full thread as it is at that moment on the machine your phone is connected to.