Problem
The escalation router permanently latches a session to the strong tier after escalation. In multi-turn agent workloads, the difficult part may later be resolved, but every remaining turn still uses the strong model. This raises cost and prevents the router from returning routine work to the efficient tier.
Proposed solution
Add an optional de-escalation policy under the existing escalation configuration:
- Hold the strong tier for a configurable minimum number of turns.
- Judge completed strong-tier responses with an explicit strong-phase marker.
- Require consecutive safe-to-release verdicts before returning to the efficient tier.
- Optionally cap a strong-tier run and apply an efficient-tier cooldown to prevent immediate bouncing.
- Retain state through the existing session identity.
- Preserve the current permanent latch and packaged prompt exactly when the option is omitted.
The policy should fail safely: judge failures keep the strong tier, and a strong-target fallback must not be judged as a strong response or preserve a partial release streak.
Alternatives considered
- Keep permanent latching: simple, but it continues paying strong-tier cost after recovery.
- Route every turn independently: can bounce between tiers and lose useful provider cache locality.
- Use the stage router: useful for deterministic tool signals, but it does not replace response-based trajectory judging.
Scope notes
This belongs in the libsy escalation algorithm, with matching deployment-TOML, Rust, PyO3/Python, tests, and routing documentation. It requires no protocol changes or new dependencies. The new behavior is opt-in and backward compatible.
Additional context
The design was calibrated on multi-turn general-agent workloads where escalation rescued difficult phases but permanent latching dominated cost afterward.
Problem
The escalation router permanently latches a session to the strong tier after escalation. In multi-turn agent workloads, the difficult part may later be resolved, but every remaining turn still uses the strong model. This raises cost and prevents the router from returning routine work to the efficient tier.
Proposed solution
Add an optional de-escalation policy under the existing
escalationconfiguration:The policy should fail safely: judge failures keep the strong tier, and a strong-target fallback must not be judged as a strong response or preserve a partial release streak.
Alternatives considered
Scope notes
This belongs in the libsy escalation algorithm, with matching deployment-TOML, Rust, PyO3/Python, tests, and routing documentation. It requires no protocol changes or new dependencies. The new behavior is opt-in and backward compatible.
Additional context
The design was calibrated on multi-turn general-agent workloads where escalation rescued difficult phases but permanent latching dominated cost afterward.