Repository navigation
Pi Dreamer ignores configured fallback_models and timeout_minutes #784
Description
Short description
Pi Dreamer ignores configured fallback_models and timeout_minutes
What happened?
### Describe the Bug
In `@cortexkit/pi-magic-context`, `buildDreamTaskRuntimeConfigs` correctly resolves per-task `fallbackModels` and `timeoutMinutes` from the user configuration.
However, in `createPiDreamerClient`, when invoking `runner.run(...)`, both fields are hardcoded instead of forwarding the resolved task configuration:
- `fallbackModels: undefined`
- `timeoutMs: 30 * 60 * 1000`
### Impact & Evidence
1. **Timeouts ignored:** Even if a task is configured with `timeout_minutes: 120`, the subagent run is forcibly terminated at exactly 30 minutes:pi subagent timed out after 1800000ms — saw 112 events ... (model was emitting events but no terminal stopReason reached)
2. **Fallbacks never trigger:** If the primary model fails due to transient connection issues, 429 rate limits, or empty text responses:
Diagnostics
Plugin version
0.49.23
OpenCode version
No response
Platform
macos
Client
Pi
Activity
[-][Bug]: Pi Dreamer ignores configured fallback_models and timeout_minutes[/-][+]Pi Dreamer ignores configured fallback_models and timeout_minutes[/+]magic-alfonso commentedon Oct 26, 2026
Thanks for the report. I checked both halves against the code (
packages/pi-plugin/src/dreamer/index.ts,createPiDreamerClient).Timeout: confirmed. The per-task timeout reaches the shared executor as an abort signal, but the Pi subprocess also gets a fixed
timeoutMs: 30 * 60 * 1000ceiling. That ceiling was meant to sit above every task timeout, so the signal would decide. Withtimeout_minutesset above 30, the subprocess ceiling fires first, and the run ends at 30 minutes, as you saw. The fix is for the ceiling to follow the task's own timeout instead of being fixed.Fallbacks: probably not what it looks like.
fallbackModels: undefinedis deliberate there. The shared executor walks the per-task fallback chain itself: it rewrites the model for each attempt and calls the Pi runner once per attempt. Forwarding the chain to the runner as well would make the two iterate on top of each other. If you've seen a configured fallback never get tried, please paste the dreamer log lines for that run (the task, the primary's error, and what happened next). That would tell us whether the executor's rule for which errors advance the chain missed your case.This is queued, and we'll post here when the timeout fix lands. PR 783 covers this too; we'll take the timeout part from there or fix it directly.