A BeyDock session stays on one provider. A Claude session is a Claude session until it ends. That is a deliberate rule, because a transcript cannot move between providers. Delegation is how work crosses the line: a session hands a task to a child session on another provider or account, waits, reads the result, and carries on.
We built it because "all your accounts in one window" was only half of the idea. The other half is that those accounts should work together. If one account is close to its limit while another sits idle, the idle one should be able to take a piece of the job.
What it looks like
Say you are refactoring with a Claude session and you want the tests written by Codex. You tell the session so. It lists the available targets, starts a child on a Codex account with the model and effort it picked, keeps working on the refactor, and later collects the result.
Every session gets a built-in MCP server called beydock-session. Its agents group holds the tools: agents_list, agents_start, agents_wait, agents_get, agents_message, agents_stop, agents_apply and agents_run (start and wait in one call). These work the same whichever provider the parent session runs on: Claude, Codex, Antigravity or OpenCode.
One target per task
A child runs on a target: provider, account, model and effort. The parent chooses all four per task. If the model or effort name is unknown, the call fails and lists the valid options. We never substitute a different model silently.
agents_list returns facts only: which accounts exist, which models and effort levels they offer, how much of each usage window is used, and whether a model is free. It does not return a "recommended" field. BeyDock does not steer the agent toward cheaper models, and the server instructions say nothing about which model suits which job. When and where to delegate is up to you, your instructions, or a skill you turn on.
There is one convenience: account: "auto" picks the account with the most headroom for the same provider and model. It never changes the provider or the model.
Every child is a real session
A child is not a hidden background call. It is a session record with its own transcript, permissions and usage. It shows up as a row in the parent's transcript. Open it and you see the full conversation, and you can interrupt it, message it or let it continue. Children stay out of the sidebar by default. The parent's sidebar row shows a badge with the number of running children.
The parent only receives a summary. The result comes back wrapped in an <agent_result> block, and the server instructions tell the model that it is data from another model, not instructions.
Reading is easy, writing is isolated
A read-only child can work in the parent's folder, so several can scan a codebase in parallel. A child that edits files always gets its own git worktree, created from the parent's current HEAD. Uncommitted changes in the parent's folder are carried over, so the child starts from where you actually are.
The child's result is a file list and a diff. To bring the changes into the parent's folder, the parent calls agents_apply, and you see an approval card with every file and its diff. Children run without your git identity, your gh login, GitHub tokens or your SSH agent.
Instructions alone are not the boundary here. Codex children use Codex's own sandbox. Antigravity and OpenCode children run under sandbox-exec on macOS. Claude children use the SDK sandbox for shell commands, and a hook checks edits against the policy. On a Linux SSH host there is no sandbox-exec, so those children rely on BeyDock's command checks. A parent in plan mode or a read-only mode can only start read-only children.
Limits and guardrails
- Delegation is one level deep. Children do not get the
agentstools. - By default a host runs at most four children at once, and one parent at most three. Beyond that the call returns an error instead of queueing, so the parent decides what to do.
- A child that produces no output for 180 seconds after its turn starts is stopped and reported as failed.
- By default, starting a child that edits files asks for approval, and the card shows the whole task, the target, the access level and the workspace. You can make it ask for every child, or never.
- Settings › Agents has a switch to turn the whole thing off, and you choose which accounts and models children may use.
Where it stands
This shipped in 0.3.0 and is still in early access testing.
The Delegation skill, which teaches an agent when to hand work off, ships with the app but is off by default. We did not want a skill quietly pushing work to weaker models to save tokens when you wanted the strong one. You can turn it on in Settings › Agents, or write your own.