mirror of
https://github.com/danny-avila/LibreChat.git
synced 2026-08-28 12:44:28 +00:00
* 🪜 fix: Apply recursion limit config to subagents Subagents ran through the SDK's SubagentExecutor path (recursionLimit = maxTurns * 3, default maxTurns 25 -> 75) which is decoupled from the top-level resolveRecursionLimit path. buildSubagentConfigs never set maxTurns, so subagents ignored the Agent Builder recursion_limit and the YAML recursionLimit/maxRecursionLimit, always capping at 75 steps. Add resolveSubagentMaxTurns (reuses resolveRecursionLimit, then max(25, ceil(limit / 3))) and set maxTurns on each SubagentConfig: self-spawn mirrors the parent, explicit children use their own recursion_limit. Floor at 25 avoids regressing below the historical 75; ceil keeps the effective graph limit within the resolved value and the maxRecursionLimit cap. Fixes #14181 * 🔒 fix: Clamp subagent maxTurns within maxRecursionLimit The default floor and ceil rounding could push a subagent's effective graph limit (maxTurns * 3) above the admin maxRecursionLimit cap while top-level agents are capped exactly (e.g. cap 20 -> 75 steps, cap 200 -> 201). Clamp maxTurns to floor(maxRecursionLimit / 3) so the effective limit never exceeds the cap, keeping a minimum of one turn. * 🎯 fix: Honor lowered recursion limits for subagents Drop the 75-step subagent floor: it kept subagents at 75 even when an admin/user lowered recursionLimit or recursion_limit below it, defeating cost/runaway control. Since resolveRecursionLimit already caps at maxRecursionLimit, deriving maxTurns as floor(limit / 3) keeps the effective graph limit at or below the resolved value, so it both honors lowered limits and never overshoots the admin cap (subsumes the prior explicit clamp). Minimum one turn. * 🧮 fix: Honor sub-3 recursion caps for subagents Drop the max(1, ...) floor on resolved subagent maxTurns. A cap of 1 or 2 previously became 1 turn (3 steps), exceeding the ceiling the top-level path enforces. floor(limit / 3) now yields 0 turns for a sub-3 cap, so the child never gets more steps than the resolved cap; the SDK returns a graceful recursion error, matching a top-level run with recursionLimit below 3. |
||
|---|---|---|
| .. | ||
| api | ||
| client | ||
| data-provider | ||
| data-schemas | ||