Each argument is a peter() call; it is evaluated with deferral on, so it builds its session
without running it, and all members then run together on one reactor, at most max_active at
a time. The result is a team session: team$text joins the members' answers under
### <name> (<model>) headings, team$value is the named list of their values, and
team$<name> (or team[[i]]) is a member's session. Piping the team into peter() continues
it.
Usage
gptr_parallel(
...,
.list = NULL,
max_active = NULL,
on_error = c("return", "stop")
)Arguments
- ...
Named
peter()calls (or sessions created with.run = FALSE).- .list
A named list of sessions created with
.run = FALSE.- max_active
The number of members that run at once;
NULLuses the optiongptr.subagents.max_active(8).- on_error
"return"keeps failed members with their status;"stop"signals the first failed member's condition once every member settled.
Details
Members evaluate R code in their own environment (envir =) with their own random-number
stream, and share one budget, as one peter() call does. A member's tools =, budget = and
the run options in its .opts (such as max_turns) are not applied.
Use peter(..., agents = list(...)) for named roles on one task, or parallel = for one
task per input element. Those routes start new foreground children and cannot be deferred
as members here. A team report is model-generated output; inspect child statuses and
workspace results before continuing the team with a synthesis prompt.
Examples
fake = gptr_fake_provider(list("ok"))
session = gptr_parallel(planner = peter("Plan it", model = fake),
review = peter("Review it", model = fake))
names(session$children)
#> [1] "planner" "review"