Synergy installs from main while dev is the default branch

The install script is fetched from main while dev is the default branch

The default branch of this repository is `dev`, and the documented install pulls its script from a different branch:

curl -fsSL https://raw.githubusercontent.com/SII-Holos/synergy/main/install | bash

So the one command that puts code on your machine comes from `main`, which is not the branch under active development, and the release tags are cut from somewhere else again. That is a three-way split: the branch people develop on, the branch the installer serves, and the tags that produce the desktop and CLI artefacts. Nothing on the page says how they are kept in step, and the consequence is concrete for anyone reproducing a version, because a lock on the install script does not tell you which release you just installed. The rest of the quick start is conventional and well laid out: a config wizard, then `synergy start` to bring up the background runtime, `synergy web` for the client, `synergy send "summarize this repository"` to run one task from a terminal, and `status`, `logs`, `doctor` and `stop` for the runtime itself.

Costs are computed before a price increase, and the leaderboard was fetched after it

The benchmark section is the most careful thing on the page, and the care cuts against the headline. The DeepSWE v1.1 numbers are 113 real repository engineering tasks, with deepseek-v4-flash under the synergy-max agent lifting Pass@1 from 53 percent to 67.3 percent, which the page also expresses as a 14.3 point gain and 1.27 times, at 0.54 dollars per task. Then the methodology line: the official leaderboard numbers come from the benchmark site at version 1.1, fetched on 22 August 2026, while the Synergy numbers come from local full-benchmark runs, and all costs are computed at the API prices in effect before 17 August 2026 at midnight Beijing time, explicitly prior to DeepSeek's across-the-board price increase and its peak and off-peak pricing. So the pass rates and the cost figures describe different pricing worlds, five days apart on one side of a change and five after on the other. Nothing else in the comparison is suspect, and the disclosure is voluntary, but a reader budgeting from 0.54 dollars a task is budgeting from a price that no longer applies.

The page quotes 0.54 dollars per task and 0.60 dollars per passed task

Two per-task numbers appear on the same page and they are not the same measurement. The headline says the run lands at 0.54 dollars per task, and the resource profile says passed tasks average 0.60 dollars over roughly 2.3 hours. The second is per passed task and the first is per task across the run, so the two differ by exactly what you would expect when some tasks fail before spending much, and neither number is wrong. What a reader has to do is decide which one they meant, because a cost figure quoted without that distinction moves depending on the pass rate. The efficiency claim beside them is 7 to 40 times cheaper than the top five official models and the cheapest baseline, which is a range spanning two different comparison sets, and the token and step counts behind it are aggregated across subagents, so a single subagent's cost is lower than the total. The failure anatomy is at least self-consistent: 76 of 113 tasks fully passed, which is the 67.3 percent, and 24 of the 37 remaining miss by only one or two tests.

synergy doctor fails when two channels both claim the synergy command

The install story is the messiest part of an otherwise careful product, and the tool admits it. Four channels can each hold an installation: the standalone CLI installed by the script, a package-manager install through npm, yarn, pnpm or bun, and the desktop app. You may keep one per channel, but only one should be the `synergy` command your shell resolves, and `synergy doctor` exists to list every detected installation channel and exit nonzero when they conflict. That sentence is the last thing on the page, cut off mid-word at the word starting with c, so the rest of the conflict rule is not written down. The mechanics are documented elsewhere: the CLI installer places the launcher and what it calls a sealed module graph under `~/.synergy/`, the `SYNERGY_HOME` variable moves that root, and the installer does not install the Electron desktop app. The desktop side has its own gaps: macOS gets a `.pkg`, Windows an NSIS `.exe` and Linux a `.deb`, portable artifacts are published but do not configure a system CLI, and Windows desktop and CLI releases support x64 only.

Saved website logins sit in the same workspace as your files

The feature list pairs two capabilities that are usually separate. Files and Browser stay in context, so you can browse, edit, create, copy, move and delete workspace files alongside desktop browser pages with saved website logins, without moving the task into a separate tool or a disposable environment. Changes are reviewable and restorable against the original workspace, which is a real safety property for file edits. The other half is the credential store: the desktop application holds logins for websites, in a local workspace, next to the projects and the history. Nothing in the visible text says how those logins are protected, whether they are per-project or shared, or what happens to them when a workspace is deleted. That is not a reason to avoid the tool, since every browser profile does the same job, but it is the question to answer before you browse anything authenticated while an agent is driving, and it belongs in the same review as the file restore history rather than in a separate policy.

Files live in a store you choose, compute is disposable

The resource model is the part of the design that generalises beyond this product. Execution is selected independently of your files, as native or Docker, and the rule that matters is that API-only work allocates no container at all. When compute is used and then reclaimed, the files survive because they are not in the container: local, S3 and object storage service backends all preserve them across reclamation. That is the same discipline as treating an agent session as disposable and the workspace as the durable artefact, and it is why the product can claim recoverable sessions with complete history even after older model context is compacted. Knowledge is handled the same way, with reusable memory and learned experience in the Library while notes and blueprints are authored as durable documents. The Library is also where the vocabulary gets interesting: it reports reward-signal analytics per behavioural dimension, so experiences are scored, and the page does not say who or what assigns those scores.

Nine separate tools guard the repository

The top level of this repository is mostly guardrails. Linting is oxlint with warnings denied, formatting is prettier with a content-addressed cache and an ignore for the artifacts directory, dead code is checked by a script backed by a knip configuration, dependency rules come from a dependency-cruiser config with a committed dependency snapshot, tasks are orchestrated with turbo, git hooks run through husky, secrets are scanned with gitleaks and its own ignore file, GitHub Actions are scanned with zizmor, and web performance runs through a Lighthouse configuration. Monorepo dependency consistency is checked with a pinned sherif invocation, and there are dedicated checks for workflows, skills, package guides, test layout and localisation sources. Two details are worth noting. Several test scripts pass `--config /dev/null` to bun, which deliberately bypasses the project's own test configuration for those runs. And a `patches/` directory at the root means dependencies are patched in place, which is normal and also means an update to a patched package is not a version bump.

The manifest description is the npm placeholder and the source build is Bun-only

The package manifest is private, declares the module type, and pins `[email protected]` as its package manager, with a `bun.lock` and a `bunfig.toml` at the root. Its description field is `AI-powered development tool`, which is the placeholder npm generates for `npm init`, so the published metadata for the workspace says nothing about what it is. Every script in it assumes Bun: development runs a TypeScript file through bun, the performance and layout checks call `bun test` and `bunx`, and the format script is invoked as `./script/format.ts` rather than through a runner, so it carries its own shebang. That is a narrower constraint than the four package managers the distributed artefact supports, which means the source tree is developed on one runtime and shipped to users on four. A workspace directory named `.synergy/` is checked in at the root as well, so the project's own agent configuration is version controlled alongside the code.

Editorial conclusion

Synergy is worth reading for two things regardless of whether you install it. The first is the durability model, where files live in a store you choose, local or S3 or OSS, compute is disposable, and API-only work allocates no container at all, so a reclaimed sandbox does not lose your work. The second is that its benchmark page discloses its own methodology against its own interest, stating that the official numbers were fetched on a date after a price increase while all costs are computed at prices from before it. That disclosure is why the cost figures should be read as a relative claim rather than a number to budget from. Two things to check before you install. The install script is fetched from the `main` branch while `dev` is the default branch, so the artefact you run may not be the branch being developed. And the desktop app keeps saved website logins next to your workspace files, which is the feature to think hardest about before pointing it at anything with credentials in it. The newest release is v3.0.22 from 2 September 2026 and the last commit on the default branch is dated 1 October 2026.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes