fix(ui): MiniMax H3 turbo steps follow the LoRA, and either turbo LoRA counts - #169
Merged
Merged
Conversation
…rbo LoRA Two starter LoRAs distill MiniMax H3, at different schedules: the larryvrh repack the bundled templates assume (6 steps) and LightX2V's 8-step release. The Video panel treated the fast path as a single family-wide constant and anchored it on the exact LoRA keys the toggle installed, so the LightX2V LoRA ran at 6 steps, and switching to the other one read as "accelerator broken" — toggle off, steps back to 50. Step counts are now resolved per LoRA: an explicit "N-step" token in the name wins, then a per-release override (lightx2v -> 8), then the family default. The toggle, the help text and metadata recall all quote the count the LoRA actually running was distilled for. The enabled flag now describes what is enabled rather than what the toggle once installed. getAcceleratorLoraChangeResult reconciles it against the Concepts list on every edit: another complete accelerator set re-anchors the fast path onto it at its own step count, enabling one with the toggle off adopts it, and only a list with none left turns the toggle off and restores the model's sampling defaults. The toggle itself now prefers a LoRA the user already has enabled over its own catalog pick. A LoRA only counts as an accelerator when read off the user's own list if it names the model family, so a personal "Turbo ..." LoRA is never adopted and a T2V Lightning pair no longer passes as valid for an I2V main; whatever the catalog itself would install is exempt. The background catalog sync passes adopt: false, so it can only repair a fast path the user turned on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PN1hzSA6oGBNuSPMyNUPWQ
…view Six defects found by a fresh-context review of the previous commit: - getVideoModelPolicy folded the running LoRA's step count into ui.accelerator, and deriveAcceleratorRecallState then fed that object back in as the family fallback. Recalling a 6-step Turbo video while the panel ran the 8-step one resolved the fallback to 8 and dropped the fast path. ui.accelerator is the family config again; the resolved count moved to a separate ui.acceleratorSteps that only the help text reads. - The toggle preferred an accelerator-shaped LoRA already enabled in the Concepts list. For MiniMax H3 the family test is /minimax|h3/, which is how a user names their OWN H3 LoRA, so the toggle could arm on a LoRA with no distillation in it and rewrite its weight to 1. Toggle-on is catalog-only again. - The list reconcile could ARM an off accelerator, so any Concepts edit - adding an unrelated LoRA, nudging a weight - destroyed a hand-tuned step count and CFG whenever an accelerator-shaped LoRA happened to be enabled, and a hand-added Turbo LoRA could never be held with the fast path off. It now only ever repairs a fast path that is already on. - findAcceleratorAmong's catalog-pick fallback laundered a look-alike past the family-name guard whenever no better-named release was installed. Moot once arming is gone: the fallback is now only reachable for a set that was already the recorded accelerator. - findWanLightningLoraPair's requireFamilyName was a no-op for a Wan main with no variant string, accepting any Lightning-named pair. It fails closed and leaves the answer to the catalog. - syncVideoWidgetValuesWithModels kept the flag and its keys when no video main was installed, though it empties `loras` in the same pass - a record isVideoSettings rejects on reload. It clears both, reusing the empty array so the identity guarantee holds. - isRecordedAcceleratorIntact compared a list length against a Set size, so a duplicated LoRA entry made intactness permanently false and returned a fresh array from every no-op sync, defeating the documented identity guarantee. It dedupes by key first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PN1hzSA6oGBNuSPMyNUPWQ
lstein
requested review from
JPPhoto,
Pfannkuchensack and
blessedcoolant
as code owners
August 28, 2026 02:04
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two starter LoRAs distill MiniMax H3, at different schedules: the larryvrh repack the bundled H3 templates assume (6 steps) and LightX2V's 8-step release. The Video panel's Turbo toggle treated the fast path as a single family-wide constant, and anchored it on the exact LoRA keys the toggle installed. Two bugs fell out of that:
Changes
Step counts resolve per LoRA. An explicit
N-steptoken in the name wins (this is how the Wan Lightning LoRAs state it, and how LightX2V's raw filename does), then a per-releasestepOverridesentry (lightx2v→ 8), then the family's reference count. The toggle, the help text under the switch, and metadata recall all quote the count the LoRA actually running was distilled for. Verified against the real installed names instarter_models.py; no Wan value changes.The enabled flag describes what is enabled, not what the toggle once installed.
getAcceleratorLoraChangeResultreconciles it against the Concepts list on every edit:It only ever repairs a fast path that is already on — it never arms one. The name heuristic cannot tell a distillation release from a user's own "… Turbo …" LoRA, and arming on one would silently drop a hand-tuned step count onto a LoRA that does not support it. Toggle-on stays catalog-only for the same reason.
A LoRA read off the user's own list must also name the model family, so a T2V Lightning pair no longer passes as valid for an I2V main. Where there is no family token to check (an unprobed Wan release on the fallback variant) this fails closed and leaves the answer to the catalog.
Behavior notes
Review
The first commit went through an adversarial fresh-context review, which found 8 issues; 6 were confirmed and are fixed in the second commit, with a regression test each. Highlights: recall's step check was contaminated by the panel's current accelerator; the toggle could arm on a user's own H3-named LoRA and rewrite its weight; an unrelated Concepts edit could destroy a hand-tuned step count; and
syncVideoWidgetValuesWithModels' documented identity guarantee was breakable by a duplicated LoRA entry. Full accounting in the commit message.Testing
pnpm run test(6,648 tests) andpnpm run lint(format, oxlint, tsc,architecture:check) pass on the rebased branch. 13 new tests cover the two reported bugs and each confirmed review finding.Related
Follows the Video panel work in #123–#135.
🤖 Generated with Claude Code
https://claude.ai/code/session_01PN1hzSA6oGBNuSPMyNUPWQ