Sub-agents

A sub-agent is a second agent that the agent in your chat starts to do part of the job. Several can run at once, which is how a large task gets done in parallel. The agent decides when to start them; Swarm mode asks it to do so whenever a task splits into independent parts (see Goal, Swarm and Plan).

Sub-agents normally use the same provider as the chat. With one setting you can let them run on other providers too, for example a cheaper model for research and a stronger one for the hard part.

The agents panel

Sub-agents do not appear inline in the chat. While they work, the ticker under the last message says how many are working, for example "2 agents working". Click it to open the Agents panel beside the chat.

The panel lists this session's sub-agents in three groups:

• Waiting for your approval: a sub-agent that is stuck on an approval request. You can answer it right there.
• Running
• Finished

Each card shows the task name, the agent's nickname and role, the provider and model it runs on, how long it has run, its tokens and tool uses, and "failed" or "needs approval" when that applies. View transcript opens a card: you see the prompt it was given (Show more for a long one), its numbers, and either "working…" or its final output. The back arrow returns to the list. Widen the panel and Close sit in the panel's header; closing it loses nothing, and the same click on the ticker brings it back.

Before any sub-agent starts, the panel says "No agents in this turn yet. They appear here the moment the session spawns them."

Sub-agent approvals

A sub-agent follows the permission mode of its session. When one needs approval, the request appears as a normal approval sheet whose title names the sub-agent, and in the panel under Waiting for your approval. The choices are the same: Allow once, Allow for session and Deny. See Permissions and approvals.

Sub-agents on other providers

Off by default. Turn it on in Settings > Providers, in the group Agents on other providers:

1. Turn on Let agents use other providers. The summary reads "Sub-agents run on the providers you check, without asking."
2. Check the providers sub-agents may use. The list shows your connected providers, checked ones first. Four show at first, and "Show N more" reveals the rest.
3. Decide whether the agent may choose on its own with Choose providers automatically.

Turning the switch on is your consent. From then on, a sub-agent can run on a checked provider without asking you each time. The setting covers every chat on this computer, including routines and goals.

Choose providers automatically

Off by default. While it is off, "sub-agents use another provider only when your message names it": say "use DeepSeek to research this" and the agent may send that part to DeepSeek. Only the message that started the turn counts. With it on, "The agent may pick a checked provider on its own", for example a cheaper model for bulk work or a stronger one for hard reasoning.

What each sub-agent may use

• Each one uses your key, subscription or AgenC credits for its provider.
• Each one makes at most 32 model calls.
• It works under the chat's permission mode, so its approval requests come to you like any other.
• If a provider runs out of funds, the sub-agent stops, and every later sub-agent in that chat needs your approval. The agent is told to report what finished and what remains, and to ask before it tries another provider.

Providers that cannot be checked

Some rows say why they are not available:

• the Custom endpoint: "Sub-agents cannot use a custom endpoint."
• a local server set to an address other than its default, for example "Sub-agents use http://localhost:11434, but this server is set to" your address. Sub-agents only use Ollama at http://localhost:11434 and LM Studio at http://localhost:1234/v1.
• AgenC: "Runs each sub-agent through another provider, which must be checked too."

If no provider is connected, the group says "Connect a provider above to use it for sub-agents."

When a change reaches open chats

Saving reloads Core so open chats take the change. If an open chat could not read a change that allows more, the group says so ("Saved. One open chat could not read the change and will use it after a restart."). A change that allows less always applies.

The consent dialog

When a sub-agent on another provider needs your approval, for example after a provider ran out of funds, the app asks with a dialog: "Send this sub-task to (provider) (model)?" When several wait, it counts them ("1 of 3") and asks one at a time.

The dialog leads with:

• Who pays: "Your API key", "Your sign-in or subscription", "AgenC credits" or "Local". For a signed-in ChatGPT or xAI account, a note says the usage counts against that subscription.
• Price per thousand input and output tokens, or "Price unknown".
• Limit: the most model calls it may make.

It also says that later tool results from this sub-agent go to the same provider, browser control and terminal results included. Below that are the details: the endpoint host, whether network access and web search are allowed, the tools it gets (a grouped summary, with Full tool list), the workspace, the sandbox ("Read only", "Can write in the workspace" or "Full access (no sandbox)"), the data it receives ("Task only" or "Forked conversation history"), extra and denied read paths, the task text and the attachments. Consent details holds the identifiers Core records.

Answer with Deny, Allow once or Allow for this session. Deny has the focus, Escape denies, and Enter never approves by accident. A sub-agent that is declined shows as "Sub-agent declined by the user." If nobody can answer, as in a routine that runs while you are away, the sub-agent does not run and shows "Sub-agent could not be asked for consent." In both cases the agent continues the work itself.

Effort and speed of sub-agents

Every sub-agent runs at a limited effort and speed, set per provider. Each connected provider card in Settings > Providers has a Sub-agents line under its models, with an effort menu and, where a model sells one, a speed menu with Standard and Fast.

• By default sub-agents run at the lowest effort the model offers and at standard speed.
• "Sub-agents on (provider) run at this effort and speed. The agent can ask for less, never more."
• The limit covers every sub-agent that runs on that provider: the ones the agent spawns, workers started from a CSV, and the agents of a goal run. A fork that carries the whole conversation keeps its parent's effort and speed.
• A change reloads Core so open chats take it.