PR #78459: fix(commitments): stop hardcoding fastMode in extraction (#78451)

• Repository: openclaw/openclaw
• Author: MoerAI
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78459

Description (problem / solution / changelog)

Summary

MiniMax Coding Plan operators whose plan owns MiniMax-M2.7 but not the -highspeed variant hit HTTP 500: your current token plan not support model, MiniMax-M2.7-highspeed (2061) on every commitment extraction pass, because the commitments extraction path passed fastMode: true unconditionally to runEmbeddedPiAgent, which caused the MiniMax stream wrapper's createMinimaxFastModeWrapper to rewrite the base model id to MiniMax-M2.7-highspeed.

Root Cause

• src/commitments/runtime.ts:242 (pre-fix): the call to runEmbeddedPiAgent for hidden commitment extraction hardcoded fastMode: true.
• src/agents/pi-embedded-runner/minimax-stream-wrappers.ts:24: the MiniMax stream wrapper accepts a fastMode boolean and, when true, swaps the base model id to its -highspeed variant.
• Result: every commitments extraction request silently flipped MiniMax-M2.7 → MiniMax-M2.7-highspeed, which Coding Plan operators do not own. MiniMax responds with HTTP 500 / error code 2061. Reporter verified the Coding Plan owns the base model but not highspeed.
• The reporter listed three valid fix shapes (drop the hardcode, add a config field, or inherit agent fastMode). This PR uses option 1: dropping the hardcode lets the existing resolveFastModeState helper continue to control fast-mode for the rest of the agent runtime, and commitments extraction inherits the same default-false behavior.

Changes

• src/commitments/runtime.ts: remove fastMode: true from the runEmbeddedPiAgent payload built in the commitments extraction path. Add a comment explaining the reason so this does not regress.
• src/commitments/runtime.test.ts: extend the existing runEmbeddedPiAgentMock assertion to assert fastMode is not in the payload, locking in the regression fix.
• CHANGELOG.md: single-line entry under Unreleased / Fixes.

Real behavior proof

• Behavior or issue addressed: On every commitment extraction pass, MiniMax Coding Plan operators receive HTTP 500: your current token plan not support model, MiniMax-M2.7-highspeed (2061) from the MiniMax server because the agent runtime requested MiniMax-M2.7-highspeed even though their plan only owns MiniMax-M2.7. The reporter (@advaitpaliwal) verified commitments.enabled: true, commitments.maxPerDay: 10 config, then ran a real Coding Plan session, observed extraction always selecting the highspeed variant, and traced the root cause to dist/runtime-CXt7BFiH.js line 386 (fastMode: true hardcoded). Issue: https://github.com/openclaw/openclaw/issues/78451
• Real environment tested: Local OpenClaw checkout on Windows 11 + Node 24, with the patched src/commitments/runtime.ts exercised through the actual production extractCommitmentCandidates → runEmbeddedPiAgent payload path (no stub); the test file uses the same runEmbeddedPiAgentMock harness that mirrors the real call.
• Exact steps or command run after this patch:

  git checkout fix/commitments-no-fastmode-hardcode
  pnpm install
  pnpm test src/commitments/runtime.test.ts --no-coverage

• Evidence after fix (terminal output captured locally on PR head 2d0e44afe0):

  [test] starting test/vitest/vitest.unit.config.ts
  
   RUN  v4.1.5 C:/Users/pss/OneDrive/Documents/github/openclaw-78451
  
   Test Files  1 passed (1)
        Tests  6 passed (6)
     Start at  21:17:44
     Duration  1.38s
  
  [test] passed 1 Vitest shard in 5.23s

• Observed result after fix: The new assertion expect(callArgs).not.toHaveProperty("fastMode") confirms that the actual call to runEmbeddedPiAgent from the commitments extraction path no longer carries fastMode: true in its payload. Per the MiniMax wrapper at src/agents/pi-embedded-runner/minimax-stream-wrappers.ts:24, this is the only signal that flipped MiniMax-M2.7 → MiniMax-M2.7-highspeed; with the field gone the request goes out with the operator's configured base model id, which their Coding Plan owns. Existing 5 tests in the same file still pass, confirming no other behavior regressed.
• What was not tested: A live HTTP roundtrip against the real MiniMax server with a Coding Plan token is not available on the contributor machine, so this is unit-level proof against the production payload-builder, not a live MiniMax 200 response. Maintainers may apply proof: override if a live MiniMax recording is required; the reporter's original issue already contains live HTTP 500 evidence from the real Coding Plan.

Test

• pnpm test src/commitments/runtime.test.ts — 6/6 passed.

Notes

• Scope: smallest complete fix. No new config surface and no provider/wrapper edits — the existing fast-mode resolution chain already covers the right behavior; the hardcode was the only thing forcing true.
• Compatibility: agents that need fast-mode for commitments can still set it via agents.defaults.models.<id>.params.fastMode: true (or per-agent fastModeDefault: true) — the resolveFastModeState chain is unchanged.

Closes #78451

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/commitments/runtime.test.ts (modified, +6/-0)
• src/commitments/runtime.ts (modified, +5/-1)