Feature request
Allow model elevation to use an explicitly configured, ordered fallback chain when the preferred model is unavailable.
Current behavior
In Compound Engineering 3.23.4, CE Plan accepts a single model through plan_model. If that model cannot complete the elevated step, the workflow eventually falls back to authoring inline with the session model.
For example, I encountered this sequence:
plan_model: fable selected Fable.- The provider reported that the weekly Fable usage limit had been reached.
- CE Plan followed its current recovery behavior and continued inline.
That fallback keeps the workflow moving, but it removes the independent model judgment that model elevation was intended to provide.
Desired behavior
It would be useful to configure an ordered list of acceptable alternatives, including the reasoning effort for each one.
For example:
- Fable at
high
- Opus at
xhigh
- Sol at
xhigh, launched as a fresh-context subagent
- Stop if none of the configured models is available
The model names should remain aliases such as fable, opus, and sol, allowing the provider or host to resolve the current model generation rather than requiring version-specific IDs.
The exact configuration format is up to the maintainers.
Expected properties
- Fall back only to models the user explicitly configured.
- Advance to the next model for clearly identified availability or capacity failures, such as an exhausted usage allowance.
- Preserve the same read-only evidence and decision bundle across attempts.
- Allow a fallback candidate to require fresh context so its judgment remains independent from the orchestrating session.
- Report which models were attempted, why each fallback occurred, and which model and effort ultimately served the request.
- Allow the user to choose whether total exhaustion falls back inline or stops the workflow.
- Preserve the existing single-model behavior for users who do not configure a fallback chain.
Why this would help
In unattended or pipeline-driven runs, silently dropping from an independent planning model to the orchestrating session model can materially change the strength of the planning gate.
An explicit fallback chain would preserve the current transparent, user-controlled model-selection philosophy while making temporary provider limits less disruptive.
Feature request
Allow model elevation to use an explicitly configured, ordered fallback chain when the preferred model is unavailable.
Current behavior
In Compound Engineering 3.23.4, CE Plan accepts a single model through
plan_model. If that model cannot complete the elevated step, the workflow eventually falls back to authoring inline with the session model.For example, I encountered this sequence:
plan_model: fableselected Fable.That fallback keeps the workflow moving, but it removes the independent model judgment that model elevation was intended to provide.
Desired behavior
It would be useful to configure an ordered list of acceptable alternatives, including the reasoning effort for each one.
For example:
highxhighxhigh, launched as a fresh-context subagentThe model names should remain aliases such as
fable,opus, andsol, allowing the provider or host to resolve the current model generation rather than requiring version-specific IDs.The exact configuration format is up to the maintainers.
Expected properties
Why this would help
In unattended or pipeline-driven runs, silently dropping from an independent planning model to the orchestrating session model can materially change the strength of the planning gate.
An explicit fallback chain would preserve the current transparent, user-controlled model-selection philosophy while making temporary provider limits less disruptive.