Agent sessions Added in 0.9.7

With agent sessions switched on, an agent can hand parts of its task to other sessions on the same relay. It starts them, gives each a prompt, waits for them and reads what they answer. Every session it starts is an ordinary conversation in your list: you can open it, read along, answer its questions and stop it.

Typical uses:

• Split a job. "Start one session per package that updates its dependencies and runs the tests, then tell me which ones failed."
• Get a second opinion. "Have a session with another model review this plan before you start."
• Use another provider. "Let a Cursor session write the migration, and check its result yourself."
• Work in another folder. "Start a session in the docs repository and have it update the install page to match."

No second relay is needed for this. For sessions on another relay, the relays have to be paired; see Naming a relay.

Switching it on #

It is off by default.

1. Open Settings → Relays.
2. Under Agent sessions, turn on Agents may start and use sessions on this relay.

The relay needs at least one enabled provider for this. From then on, agents on this relay can list and read every session here, prompt one, start one, wait for it, answer its question, stop its turn and archive it. Turning the switch off closes the relay to them again.

The approval card #

The first time an agent in a conversation wants to start a session, it has to ask you. An approval card appears in that conversation and names the provider, the folder or repository, and the prompt:

This agent wants to start sessions on this relay (claude, the default folder).
Sessions it starts use this relay's accounts.

Added in 0.9.16 When the agent names a session group for the new session, the card's details line says where it goes, for example Group: Release 2.4 (grp_…). The group is looked up before the card appears; one that does not exist is refused without a card.

The approval belongs to the conversation, not to the relay: an agent in another conversation asks for its own.

In the ask and plan relay modes you are asked more often. There, every action that changes something asks first: starting a session, prompting one, answering its question, Added in 0.9.16 changing its settings, stopping and archiving it.

The rules #

Letting a started session start sessions Added in 0.9.16 #

A session that an agent started cannot start sessions of its own. To lift that for one such session, open its 🧠 dialog and switch on Agents in this conversation may start sessions (even though an agent started it). The switch shows only for sessions an agent started.

The other rules still apply to it: at most 4 at work, your Allow for the first session, and Agents may start and use sessions on this relay. Only you can set the switch: an agent, of this relay or of a paired one, is refused. Agents see it as "mayCreateSessions": true in list_sessions and read_session.

What an agent can start #

A session with any provider that is enabled on the relay: GitHub Copilot, OpenAI, Claude, Claude API, Cursor, Grok, DeepSeek or Claude Cloud. An OpenAI Image chat cannot be started this way.

• In a folder. The agent can name the working folder. If it names none, the session gets the relay's default folder.
• In a repository, for Claude Cloud. A cloud session takes a GitHub repository and optionally a branch instead of a folder. It works on a fresh clone in a sandbox at Anthropic, so the agent has to tell it which branch to work on and to push.

The agent can also choose the model, the relay mode and the reasoning effort. What it leaves out follows the session it works in.

A new session knows nothing of the conversation it was started from. It gets only the prompt the agent writes for it. If a started session seems to lack context, that is the place to look: open it and read the first message.

What you see #

• In the conversation list, a session an agent started carries via agent · "title", with the title of the conversation the agent runs in. The same line stands under the session's title in the header; clicking it opens that conversation.
• Added in 0.9.11 In a group. The session sits indented under the conversation that started it, in a session group whose head row sums up what runs and what waits for you. Added in 0.9.16 When the agent named an existing group, the session sits in that group instead.
• On the messages, a prompt the agent sent carries a badge with the same marker and the agent's model, so you can tell it from a message of your own.
• In the agent's reply, each call shows as an activity line with a 🛰️: the action and the session it went to.
• Questions. If a started session asks a question, its card waits in that session as usual. The agent that started it is told about the question; it is instructed to bring it to you rather than answer it, unless you told it to decide by itself.

How long an agent waits #

When an agent prompts a session, it waits for the reply for a while and gets whatever is there when the time is up; it can then wait again. The slider Longest wait per tool call, under the switch, sets the longest single wait: 10 minutes by default, from 2 to 60 minutes.

The limit also applies when this relay's agents wait for a session on a paired relay, which is why the slider can be moved whether or not the switch is on.

A turn that waits still counts toward Max turn duration under Settings → General. For work that takes longer than a turn should, an agent can watch the sessions instead and be woken when they are done.

By provider #

Apart from that, agent sessions work the same for every provider.

If it does not work #

All codes are listed under Errors.