Questions about Aether

Aether is an open-source multiplayer runtime where engineering teams run and jointly steer AI coding agents like Claude Code, Codex and many more on their own servers. Everyone on the server can watch any live run, and teammates take control of a run from each other. Each run works in its own container on your Linux server and ends as a git branch. An Integrator agent can direct worker agents in a swarm, and every run can open a browser the agent drives and the team watches. The quickstart walks through the whole loop.

Startups and small engineering teams that already work with coding agents such as Claude Code, Codex or one of the many others, and want them on one server where everyone can see and steer each other's runs. It fits a team that reviews agent work as branches and pull requests and can run a Linux server. It is not built for anyone who wants a framework for writing their own agents, or for anyone who wants a hosted service. Compare the deployment choices.

Yes. You operate the Linux workspace server and its storage. Connect directly, including over Tailscale, or use the optional edge for sign-in and relay. The publisher-operated edge stores identity and connection metadata, but cannot read end-to-end encrypted session content. Read the privacy policy.

Aether's current workspace server runs on infrastructure you operate, with agents installed and signed in through your server-side member environment. You control that host, its data and its upkeep. Aether is GPL-3.0 software; what you pay for is your agent provider and your own server. Compare the deployment choices.

Direct server access does not require an Aether cloud account. Access through an edge uses GitHub sign-in and an edge account. Server membership, invitations and device approval still depend on the server's access policy; signing in is not permission to join any server. See access and invitations.

There is no hosted Aether workspace today: the protocol reserves a kind for one, but no hosted feature exists. You operate the workspace server yourself. The existing optional edge is a sign-in and relay service, not a hosted workspace: it does not run your agents or store your workspace. Read the documented trust models.

Yes. Aether is published by 3xDevOps under GPL-3.0. Bundled dependencies retain their own licenses. Read the source and license.

On GitHub, at github.com/3xDevOps/aether. Aether is open source under GPL-3.0, so you can read every line of code and run it on your own servers.

Yes. Claude Code is a shipped agent. Set it up from the dashboard's Agents page, which installs it in your environment on the server and opens that terminal for its login, then pick Claude Code when you launch a run. It runs in a container on the server, not on your laptop. See the agents guide.

Yes. Codex is a shipped agent. Set it up from the Agents page, or install the Codex CLI in your environment terminal yourself, and sign in there with its device-code login. Then pick Codex for a run. An OpenAI API key in the server's environment works instead of a login. See the agents guide.

Yes. OpenCode is a shipped agent. Set it up from the Agents page, or install it in your environment terminal yourself, then sign in with its own login command there. Its login stays in your server-side member home and reaches every run on your account. See the agents guide.

Aether ships harnesses for many agent CLIs, like Claude Code, Codex, Gemini CLI and GitHub Copilot CLI. Members can register their own launch definitions for other CLIs, and administrators can pin definitions for everyone with inline JSON through a server flag or environment variable, not a JSON file path. Registering an agent does not install it or sign it in. The agents guide lists every one and what it needs.

When you ask it to. Set up on the dashboard's Agents page runs the vendor's install command in your environment, your persistent container on the server, then opens that terminal with the agent's login command typed for you to finish. You can also install it yourself there. Before a launch, Aether updates a shipped agent installed in your home, except OpenCode, which stays at the version you installed. The Agents page checks for the executable and a login file; the agent verifies its login when it starts. See the agents guide.

Native vendor logins persist in your server-side member home, mounted read-write into your runs; a run on your shared account gets only the agent's login file, or one agent CLI's whole agent directory. Aether does not synchronize those credential files back to clients. For supported Claude Code and Codex subscription quota, the server reads native credentials and calls the vendor's HTTPS usage endpoint. Container processes can access credentials in their mounted home. See the security posture.

Yes, while the server and run remain up. The server supervises the container and owns its terminal session, so closing a client or detaching does not stop the run. Reconnect from the CLI or dashboard to continue watching or steering it. See how a run works.

Each run gets its own container, git worktree and branch on the server. It starts from the launcher's saved environment image, or the standard Ubuntu image, with the launcher's persistent member home mounted alongside the checkout, also on another member's shared account. The home persists across runs; it is not a separate private home for each run. Agents run without permission prompts by default, so a run does not stop to ask before each command. See the environments guide.

Yes. Docker is required on the Linux server, and run and environment terminals execute in containers. This is a container boundary, not an additional agent sandbox: agents run as root by default and can access whatever is mounted into their container. With the optional Sysbox runtime, each run gets its own Docker daemon, so an agent can build and run containers without reaching the host's. See the install guide's requirements.

When an interactive agent reports that it is done, the run reads Ready for review and stays live, so you can read the changes and send follow-ups. Mark complete closes it, and Not yet leaves it open. An agent exiting does not close an interactive run either: it drops to a login shell until someone closes it. Closing commits and publishes the latest work to the run branch and keeps the container, seven days by default, so the run can be reopened. A Background run commits, publishes and finishes by itself when the agent exits. Read the completion and close workflow.

Not for an ordinary run. Publish pushes the run branch without force and can open a pull request, and Pull brings the run branch into your local clone without switching branches or merging it into your base branch. A swarm is the exception you opt into: once its Integrator has verified the combined work, it delivers it to a target branch in the workspace's repository on your server with no further approval, provided the person accountable for the swarm can push there. For a workspace mirrored from an upstream repository, delivery creates a proposal branch instead and leaves upstream for a person to push. Read the integration boundary.

Yes, in a swarm. You give it one objective, an Integrator agent and the agents its workers may use, for example a Claude Code Integrator with Codex workers. The Integrator asks you questions only if it needs answers, splits the objective into tasks, starts a worker run for each, and combines and delivers the verified result. No one approves the plan or the delivery; you choose the agents at the start and can cancel the swarm while it runs. Workers cannot start workers of their own. Outside a swarm, runs in the same workspace can find each other and exchange messages, and the conflict radar flags runs editing the same files; neither locks anything or grants control. Read about launching a swarm.

Yes. A live run can open its own headless Chromium, which Aether starts in a separate container beside the run and drives with Playwright on the server. It shares the run's network, so localhost is the app the agent started. The agent drives it with shell commands Aether puts in every run. Anyone who can steer the run sees the same page in its Browser tab, can take over, and can annotate an element or pick console errors to send to the agent. Nothing starts until someone opens it; it then reserves one CPU and 1 GiB of memory. Read about the Browser view.

Everyone on a server can open any live run and watch the agent work, and collaborators can steer it. One person controls a run at a time. Take control is immediate when nobody holds it; to take over from a teammate, hold it for a few seconds, and they can accept or deny, with control passing to you after seven seconds if they do neither. A message to the agent from anyone but the controller waits 45 seconds for the controller's decision. Everyone who messages a run is credited as a co-author on the commits Aether makes for it. See multiplayer in practice.

Yes. Multiple people can watch a live run's terminal or Session view at once. Collaborators can steer: take control and type to the agent, or send it a message. Viewers stay read-only. Protecting a run limits messaging, control and killing it to its owner and admins. Notes in a run's Details panel are for people; the agent never sees them. Sending the agent a message or typing into its terminal credits you as a co-author; typing in a separate shell in the run's container does not. See the teams guide.

Yes. A server can host multiple members and their runs. Viewers can inspect work; collaborators can launch and steer within their permissions; admins manage membership and server controls. Invitations and access policies determine how people join. Admin status does not implicitly grant access to another member's agent account. See what a team looks like.

Map is the second tab of the Board. The Board shows a swarm as one card; the Map shows every run on its own, swarm integrators and workers included, grouped by the person who owns it, with arrows from each integrator to its workers. Arrows that cross between owners are dashed, and a worker whose integrator is filtered out stays visible, labelled “integrator not visible”. Read the Board guide.

Yes, with an explicit, directional grant from your Profile. The teammate owns the run, and it runs in the teammate's own environment: their image, home, git identity and GitHub login. The account owner supplies the agent's login file, mounted read-write, plus quota and cost attribution. A root process in that run can copy the login, and revoking does not recall a copy. One agent CLI is an exception and shares the owner's whole agent directory; the security guide names it, so check it before you share that account. Revoking the grant blocks future launches and relaunches, not running containers; stop existing runs to end their access. Runs on a shared account need Docker Engine 26.0 or newer. Read the account-sharing boundary.

A workspace budget can warn before a hard cap and refuse new runs at the cap unless an override is enabled. It does not stop runs already working. Displayed spend is accumulated usage, not a forecast; agents that report no usage make the total a floor, not an exact bill. Deleting a run does not erase its counted cost. See the teams guide.

The server supports Linux on amd64 and arm64. CLI clients support Linux, macOS and Windows. The CLI installs the optional desktop app: it builds the app on your computer on Linux and macOS, and downloads the release's prebuilt app on Windows. Every release includes an Android app, which reaches a server over a tailnet or through the optional edge. See the install guide.

No. macOS and Windows are client platforms: you run the CLI there and point it at a Linux server. The install script refuses to put the server on anything else. See the install guide.

That is the intended setup: a home server, a spare PC, or an old laptop repurposed to stay on all day. The server needs Linux on amd64 or arm64, plus Docker and git. No minimum is documented. The default limits of up to 8 CPU cores and 8 GiB of memory per run are ceilings, not reservations, intended for hosts with 32 GiB or more, and you can lower them. A run's browser, once opened, reserves another CPU and 1 GiB. See the install guide's requirements.

Yes. Tailscale is a direct connection option, separate from the optional edge. Tailnet identity can be used when linking the server, and an optional web port serves the server dashboard over HTTPS on its tailnet addresses. Access still follows the server's membership and approval rules. See the networking guide.

Choose a Linux workspace server and a client for your computer. The install guide covers the shell installer, Windows PowerShell installer, release checksums and server service setup. Install Docker and git on the server, link your client, then set up your chosen agent and sign in to it in your member environment. See the install guide.

Your workspace repository and run data live on the server you operate. The optional edge relays encrypted connections; it is not code hosting or workspace storage. Model providers can still receive prompts and code through the agent CLIs you run, and connecting an upstream repository adds that destination to your workflow. Read the security boundary.

Agents send prompts and code to their chosen model providers. Aether also uses external services for releases, container images, supported vendor quota reads and, if you turn them on, browser push notifications. If you use the publisher-operated edge, it stores identity and connection metadata, but cannot read end-to-end encrypted terminal, agent, file or dashboard content. Self-hosting does not mean nothing leaves the machine. Read the privacy policy, including edge data.