Question
Where should the plugin preserve the fact that the user selected logical ultra after the backend-facing reasoning effort becomes max?
Compare candidate designs—including model-option metadata, resolved chat-parameter state, internal request headers, request-local markers, and session-scoped state—against these requirements:
- proactive delegation is activated before the model sees the turn;
- no unsupported literal
ultra reaches the inference backend;
- retries, account rotation, and catalog-scope changes remain deterministic;
- explicit
max is never mistaken for Ultra;
- compaction and auxiliary requests receive only the semantics they should inherit;
- custom aliases and effort suffixes resolve consistently;
- child work can inherit the intended maximum reasoning without uncontrolled recursive fan-out;
- stale catalog defaults can be removed safely;
- debug and snapshot output can explain the logical and wire states without exposing internal headers upstream.
The resolution should select an ownership boundary, define the state lifecycle, and explain why rejected alternatives fail repository invariants.
Question
Where should the plugin preserve the fact that the user selected logical
ultraafter the backend-facing reasoning effort becomesmax?Compare candidate designs—including model-option metadata, resolved chat-parameter state, internal request headers, request-local markers, and session-scoped state—against these requirements:
ultrareaches the inference backend;maxis never mistaken for Ultra;The resolution should select an ownership boundary, define the state lifecycle, and explain why rejected alternatives fail repository invariants.