Skip to content

fix(session): honor toolChoice on max-mode's final step - #1871

Open
onlyfeng wants to merge 1 commit into
XiaomiMiMo:mainfrom
onlyfeng:fix/maxmode-laststep-toolchoice
Open

fix(session): honor toolChoice on max-mode's final step#1871
onlyfeng wants to merge 1 commit into
XiaomiMiMo:mainfrom
onlyfeng:fix/maxmode-laststep-toolchoice

Conversation

@onlyfeng

Copy link
Copy Markdown
Contributor

Summary

  • On the last step of a run, the main loop sets toolChoice: "none" so the model is forced to wrap up with text instead of proposing more tool calls. When max-mode is active, the step was unconditionally dispatched to MaxMode.runMaxStep instead of handle.process. runMaxStep's toolChoice field is intentionally unused, so a max-mode session could keep proposing and executing tool calls past its configured step budget.
  • Gate the branch so the last step always falls back to handle.process, which does honor toolChoice, regardless of whether max-mode is otherwise enabled.
  • Added a regression test that pins the "max" agent to a single step with 2 candidates and asserts only 1 LLM call (not 3) on the final step.

Test plan

  • bun typecheck passes
  • New test "max mode's last step falls back to a single handle.process call" passes

On the last step of a run, the main loop sets toolChoice: "none" so the
model is forced to wrap up with text instead of proposing more tool
calls. When max-mode is active, though, the step was unconditionally
dispatched to MaxMode.runMaxStep instead of handle.process.
runMaxStep's MaxStepInput.toolChoice field is intentionally unused (its
own comment says so) since propose-only candidates and the judge don't
care about it, and the winning candidate's tool calls are executed
through handle.replay. As a result, a max-mode session could keep
proposing and executing tool calls past its configured step budget.

Gate the branch so the last step always falls back to handle.process,
which does honor toolChoice, regardless of whether max-mode is
otherwise enabled.

Added a regression test that pins the "max" agent to a single step and
enables max-mode with 2 candidates, then asserts only a single LLM
call happens on that step (as handle.process would make) rather than
the 3 calls (2 candidates + judge) max-mode would make if it
incorrectly ran on the last step.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant