Similar projects

Tomo isn't the first tool to move files between machines, and several of these are excellent. Here's an honest read on where each shines, where it beats Tomo, and where Tomo goes a different way.

Mutagen #

Mutagen is Tomo's closest neighbor, and it's good. It does real-time two-way sync over SSH (and into Docker containers and more), it's mature and battle-tested, it manages many named sessions at once through a background daemon, and it runs on a broader set of platforms than Tomo does today. If you need production-grade continuous sync right now across a fleet of targets, it's the obvious pick.

One practical note before you commit a workflow to it: as of July 2026 Mutagen's most recent release is v0.18.1 from February 2025, and commit activity has slowed noticeably since the project joined Docker. That's a cadence observation, not a verdict — the software remains excellent — but it's worth weighing for a tool that sits in your inner loop.

Where it beats Tomo: maturity, platform coverage, multi-session management, and container-native targets. Tomo is v0 and pair-oriented.

Where Tomo differs, structurally: Mutagen keeps no history. At conflict time its two-way modes make you choose between halting the conflicted file until you intervene ("safe") or auto-resolving by discarding the losing side ("resolved"). Tomo refuses that dilemma: it resolves automatically and keeps everything — every save is a version, every conflict loser is recoverable with tomo restore. Never blocks and never loses bytes is the combination Tomo exists for.

Where Tomo differs, measurably: on our 20,000-file benchmark tree, save→arrival was a median of 6 ms for Tomo and 121 ms for Mutagen 0.18 — and a burst of 100 changed files landed in 0.67 s vs Mutagen's 9.4 s of reconciliation (methodology and raw numbers). Measure your own setup.

Both tools auto-install their remote agent over SSH, so setup friction is comparable — Tomo's twist is that the one static binary you run is the agent it pushes, version-matched on every connect. Tomo is deliberately smaller in scope — a sharp pair-sync tool with memory, not a fleet manager.

Syncthing #

Syncthing solves a different shape of problem, and solves it well: continuous, peer-to-peer sync across many devices with no central server and no SSH, its own encrypted transport, NAT traversal, and optional file versioning. For keeping a folder in sync across your laptop, desktop, and phone, it's excellent and famously reliable.

Where it beats Tomo: true multi-device mesh, no SSH or server needed, discovery and relaying built in, mature cross-platform apps.

Where Tomo differs: Tomo is built around an SSH-connected pair — usually a laptop and one build box — and leans into that (it rides your existing SSH auth and firewalling, and it keeps a real per-save version store rather than folder-level file versioning). Different topology, different priorities: Syncthing is a mesh for your devices; Tomo is a fast link between two dev machines with history.

Unison #

Unison is the careful veteran of two-way reconciliation. It has decades of real use, a well-reasoned model for detecting and merging changes on both sides, and it's rightly trusted for correctness. If you want to reconcile two trees deliberately, on your command, it's a solid choice.

Where it beats Tomo: a long track record and a very thorough interactive reconciliation model.

Where Tomo differs: Unison is batch — you run it and it reconciles once. Tomo is continuous: it watches and propagates the moment you save, resolving concurrent edits deterministically without prompting, and keeps the losing side in history. Tomo also self-bootstraps the remote; Unison expects a compatible binary on both ends.

rsync (and rsync + lsyncd / watchexec) #

rsync is everywhere for good reason: it's fast, ubiquitous, rock-solid, and unbeatable at one-shot mirroring — including the initial seed of a big tree, where it currently beats Tomo outright. For "push this directory to that server, now," reach for rsync.

Where it beats Tomo: raw seeding throughput, universal availability, and a rich set of transfer options.

Where Tomo differs: rsync is one-shot and one-directional. To get continuous, both-way behavior people bolt it to a file watcher (lsyncd, a watchexec loop, a cron job) — and those setups are one-directional, fragile, and blind to conflicts, with each run paying a full tree scan (~350–400 ms on a 20k-file tree in our numbers, growing with tree size and latency). Tomo is that continuous both-way sync as a single process, event-driven (~6 ms per save regardless of tree size), with conflict handling and history built in. Seed with rsync if you like, then hand off to tomo sync.

git push / pull #

Sometimes the right answer is a repo. git gives you real versioned collaboration, branching, review, and a shared source of truth. If what you're moving is source that wants commits, git is the tool, and Tomo happily ignores your .git directory so the two don't fight.

Where it beats Tomo: everything about deliberate, reviewable, multi-author version control. Tomo isn't trying to replace that (yet — a git-alternative is the long-term ambition).

Where Tomo differs: Tomo syncs the uncommitted state you don't want in a repo — the half-finished edit, the scratch file, the multi-gigabyte build artifact or dataset — continuously and without a commit step. It's for the gap between "saved on my laptop" and "committed," and for the outputs a repo shouldn't hold.

SSHFS / NFS mounts #

The simplest mental model of all: mount the remote directory and work on it directly with SSHFS or NFS. Nothing to sync because there's only one copy. For light, occasional remote editing over a fast link, it's hard to beat for setup cost.

Where it beats Tomo: zero conceptual overhead — no sync, no history, no state, just a folder that lives elsewhere.

Where Tomo differs: a mount pays network latency on every file operation (a compiler statting thousands of files over the wire is painful), and there's no local copy, so you're dead in the water offline. Tomo keeps a real local copy that's fast to build against and edit, syncs in the background, and keeps working when the link drops. Different trade: a mount centralizes the files; Tomo keeps two fast local copies in step.

So when is Tomo the right tool? #

Tomo fits when you edit on one machine and build or run on another — a laptop and a Linux GPU box is the canonical case — you want saves to land in milliseconds both ways, you want a real undo history of every file, and you'd rather not install or manage anything on the server. It rides your existing SSH and gets out of the way.

Be clear-eyed about v0: Tomo syncs two machines (not a mesh), there's no Windows yet, symlinks aren't tracked, and the initial bulk seed trails rsync by a few multiples (2.8 s vs 0.75 s on our 20k-file benchmark — no pre-seeding workaround needed since v0.2.3). If you need a device mesh, a fleet of targets, or Windows today, one of the tools above is the better call — and that's fine. For the two-machine, edit-here-build-there loop with history, that's exactly what Tomo is for. The benchmarks and internals have the details.

Built to be forked #

Tomo is open source, and the more useful part of that is it's built to be changed by whoever forks it. Nearly all of it was written by Claude Code, and the repo is laid out so your own coding agent can do the same work in your fork. Point Claude at a clone and it lands on its feet.

The guardrails an agent needs are already checked in. CLAUDE.md spells out nine hard invariants it must not break. docs/SPEC.md is the authoritative design record, so decisions are argued out once instead of re-guessed on every change. Project skills in .claude/skills/ hand it the test harness and the coding standards. The sync core is a pure state-machine crate with no I/O, which is the part an agent can reason about without opening a single SSH connection. And when it changes something, 770+ unit and property tests plus 32 end-to-end scenario tests tell it almost immediately whether it broke anything. Tomo even briefs the agent working inside a live sync: it drops a .tomo/README.md that tells whatever coding agent is resident that files here can change under it in real time and that every save is recoverable, so it re-reads before editing instead of fighting the peer's edits.

So changes that would normally mean a week of reading someone else's code are things you can just ask for. Want symlink support? A three-machine mesh instead of a pair? A conflict policy that parks both copies side by side? Fork it, say what you want, and let the agent work against the guardrails that are already there.