Scion coordinates existing coding agents through a Hub
Scion gives Claude Code, Codex, Antigravity, and OpenCode separate working environments, then lets them delegate tasks and exchange messages. You can put a reviewer in a Git worktree while another agent edits elsewhere, or give agents a shared directory. The useful purchase here is control over who works where. You still choose the underlying models and write the instructions that define a useful team.
Our checkout contained 9,826 files and roughly 3,209,380 source lines, occupying 142.9 MB. Those scan totals describe a substantial repository, without telling us how much is first-party code. That scale fits the project's ambitions: local workstations, shared hosted Hubs, runtime brokers, and several execution backends. I would consider it when coordinating agents has become a recurring job. Running one coding assistant does not create that need.
What happened when we ran it
Our Scion run installed 587 packages in 62 seconds and completed its build in 395 seconds. We cloned commit 18d1bb3 on October 16, 2026, into an unprivileged Debian sandbox with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image. Installation and compilation succeeded. These measurements establish that the source path worked in that environment; they say nothing about how well an agent team solves a task.
The test step failed with exit code 1 after 621 seconds. The supplied go test summary records 96 passed and 9 failed out of 105. The log tail shows successful packages, including asyncwrite, fsutil, logging, and wsprotocol, followed by a final FAIL. It does not name the failing cases or show their exceptions. Missing credentials, system packages, and code defects would all be guesses from that excerpt.
Our scan also found 13 CI workflow files and a Dockerfile, with no directory named tests. The executed test command plainly found checks elsewhere, so that directory signal is not evidence of an untested project. The actionable result is the failed complete test step at this commit. A team adopting Scion should reproduce and inspect those failures before making this revision part of an unattended workflow.
A local server and container runtime are required
The README's quick start runs scion server start before creating an agent. Even a single-user workstation uses a Hub; the local server includes its runtime broker and web interface. Docker, Podman, or Apple Container supplies the execution environment. That is reasonable infrastructure for separate workers, but it is more machinery than opening another terminal tab.
The 395-second build also needs a qualification: a successful repository build does not establish that every distribution path produces the same interface. The installation guide warns that go install omits frontend assets and leaves the web UI blank. Its clone route uses make all to include them. It also requires Git 2.48 or newer for relative worktrees. Check those prerequisites before treating the Go binary as the whole setup.
Credential sharing deserves an explicit decision
Scion's credential guide says workstation agents receive supported harness login files from the user's home directory by default. Exported provider keys can accompany the start request. You can disable host login-file sharing with use_host_credentials: false; hosted brokers instead need explicit credentials through Hub secrets or profile settings. These choices affect which accounts an agent can use, so review them before assigning work on private repositories.
Our 3-CPU sandbox had no secrets, which limits what the successful build proves about authentication or live model access. Scion supplies the coordination system, while the harness still needs a model provider account and repository access where applicable. I would begin with a disposable project and narrowly scoped credentials. Adding more agents before checking their effective access makes a configuration mistake harder to spot.
Hosted collaboration adds database and storage work
The mode guide separates workstation, single-node hosted, and replicated hosted deployments. The README specifies Postgres and shared storage for the replicated Hub. Start locally if you are still learning whether your tasks benefit from separate workers. Moving to shared infrastructure makes sense once other people need access or execution must happen away from your laptop.
Scion's 587-package installation is only the measured repository dependency step. It does not price model usage or establish the cost of operating remote agents. Container images, provider billing, and shared-service administration remain deployment decisions. Likewise, messaging gives agents a way to communicate; it does not guarantee that two agents will resolve conflicting edits or judge each other's work correctly. Someone still owns the final result.
October activity shows maintenance, while interfaces keep changing
The last repository push was October 17, 2026. GitHub reported 1,929 stars and 107 open issues and PRs. The release list included the nightly-20261017 prerelease, while the latest-stable-release endpoint returned no release. Recent PR activity included authorization work and a proposed fix for forced template self-import. That proposal describes files being deleted when source and destination are the same directory; its open status matters.
The README explicitly calls Scion pre-1.0 and warns that APIs and configuration may change. It also says this is not an officially supported Google product. Use it for a controlled agent-collaboration trial if you can inspect failures and own upgrades. For a Python application that defines agent workflows, consider CrewAI; for a coding-agent workspace, consider OpenHands. Choose Scion when separate harnesses, workspaces, and a shared control service are the actual requirement.