[Idea] Optional per-stage model escalation scheduler: auto-retry heavy scenes with a stronger model on timeout/retryable failure

[mediasambb]

Summary

An optional, operator-configurable per-stage model escalation policy for course generation. When a stage's base model (e.g. scene-content:interactive) fails with a retryable error — timeout, empty output, network — the engine re-runs the scene once with an explicitly selected upgrade model, resolved outside MODEL_ROUTES, and records the decision to a durable ledger.

Motivation

Long-running generation stalls when a heavy stage repeatedly times out (observed hours-long sessions lost on a single bad call). Operators currently must edit MODEL_ROUTES and re-trigger the page manually. The feature makes the fallback automatic, observable, and safe.

Design (minimal, disabled by default)

• Config file data/model-schedule.json (optional models / budget / escalation / strictMode)
• Per-stage policy: { base, escalateTo, trigger: onTimeout | onRetryableError, max }
• Hot-reload: read per call (250 ms cache) — saving from the UI needs no restart
• Zero behavior change without the file — missing config ⇒ original pipeline unchanged
• Safety boundary: content-safety style rejections are non-retryable and never escalate
• Budget guard dailyEscalationCap; ledger data/schedule-events.jsonl (stage, scene, base → used, reason)

UI

New Settings section "Model Scheduling": JSON editor, a 3-tier preset template (cheap/standard/premium model tiers), and a viewer of the last 20 ledger entries.

【截图：ledger-with-entry.png】

【截图：settings-panel.png】

Verification done

• pnpm lint 0 errors; prettier pass; check:i18n-keys pass (12 locales); Next.js production build pass
• Engine logic assert script 8/8 (disabled default, policy parsing, budget guard, ledger I/O)
• API A/B: GET null without config / PUT → served immediately (hot) / DELETE → back to null

Open questions for maintainers

1. Is a free-form JSON schema acceptable, or would you prefer a typed/validated schema from the start?
2. Should strictMode (reserved, not enforced) be dropped or kept for a future approvals flow?
3. Any preference on the config file location / naming (data/model-schedule.json)?

I'm available to implement this and open a PR once the design is agreed.

[wyuc]

Thanks @mediasambb for opening this as a Discussion first — that's exactly the right order, and sorry it sat without a reply while the PR went up.

The problem is real: a single timeout or empty response shouldn't cost an hours-long generation session, and recovering by editing routes and re-triggering pages by hand isn't great. We'd like to solve it with a much smaller design, though:

• The fix is "retry once on a different model." On a retryable failure (timeout, empty output, network, quota exhausted), re-run the call once on a fallback model. Content-safety rejections never fall back, as you proposed.
• The fallback model is operator configuration on the server, next to the existing model routes (an optional fallback per route, or a single global one). No browser-editable config, no config API, no files written under data/.
• One mechanism in the shared model-call layer, so every generation step gets it, and it also covers feat(llm): fall back to another model when one is out of quota #1034's out-of-quota case.
• Observability via a log line. No escalation budget, ledger or settings UI for now — we can add more if real usage shows a need.
• Unset means behaviour is unchanged.

I've left the same notes on #1614. If you'd like to build this smaller version, ideally coordinated with #1034, we'd be glad to review it.