Clear the local argument text when resetting the config

When the user enters extra arguments and then clicks Reset, the parent replaces config with DEFAULT_PER_MODEL_CONFIG, but this local state retains its initial text because it never responds to subsequent config.llamaExtraArgs changes. The textarea therefore continues displaying the old arguments while handleRun sends the reset config without them, so the visible command and the command actually loaded disagree; synchronize this state for an explicit reset or clear it from the reset handler.

Useful? React with 👍 / 👎.

The row does respond to later config.llamaExtraArgs changes: the block below the catalogue effect compares the rendered stored text against the box and re-seeds when they diverge, so Reset (config becomes DEFAULT_PER_MODEL_CONFIG, tokens go from ["--top-k","20"] to none) clears the textarea. The one case it deliberately leaves standing is a box filled from a stored override the panel never owned: Reset does not clear the server's copy, the field stays omitted on save, and the load inherits it, so the box and the command still agree.

Preserve launched arguments in the active runtime config

When a user loads from this panel with Remember disabled, these arguments are sent to llama-server but are never committed to the runtime store that useActiveModelConfig uses, while the non-remembered override is removed. Reopening settings for the still-running model therefore shows an empty box even though the active server is using the arguments, unlike the other click-time load settings recorded after success; retain the effective argument list in the active/loaded config as well as the request.

Useful? React with 👍 / 👎.

Leaving this one. With Remember unchecked the user asked for nothing to be stored, and the load stays correct either way: the omission path inherits the resident process's own extras, so a Reload from that empty box relaunches with the same arguments rather than dropping them. Showing values from a config that was explicitly not remembered would also make Reset and the dirty state read against what is actually saved. The durable case, an override set through the API, is what the hydration in eea2da7 covers.

Block managed flags while the catalog is loading

On a cold panel open, catalog remains null while /llama-flags performs its probe, which can take up to ten seconds; during that window this condition treats even denylisted inputs such as --model or --agent as valid and leaves Load enabled, although the backend will always return 400. The same mismatch persists if the catalog request fails, so managed-flag validation should be available independently of the slow capability probe or Load should remain blocked until it is known.

Useful? React with 👍 / 👎.

Leaving this one. The window is the first panel open after an install or an update, the probe now runs off the event loop, and the catalogue is session-cached after that, so it is seconds once per session rather than per open. Blocking Load until it arrives would penalise every cold open to save a 400 that already names the flag, and the backend is the boundary here, not the row. The cases with no probe behind them (a managed flag with a control in this panel, an unclosed quote, the bounds, control characters, a non-numeric value) are all refused without the catalogue.

Match diffusion validation to manual -ngl translation

When a DiffusionGemma request uses Manual GPU Memory and supplies -ngl in llama_extra_args, /load translates that flag into request.gpu_layers before dropping the extra arguments, but /validate drops the list here without performing that translation. For example, gpu_layers: 0 plus -ngl 20 is validated as a zero-VRAM load during active training, then actually launches 20 GPU layers; the inverse combination can incorrectly return 409 for a CPU load. This also affects the UI when diffusion classification was inconclusive while the extra-arguments row was staged, so validation must either apply the same translation or both paths must consistently ignore the flag.

Useful? React with 👍 / 👎.

Correct, and it is the sharper half of the asymmetry: /validate is the call that approves the switch, so it has to judge the command /load will actually run.

/load translates the last-wins -ngl out of the extras into request.gpu_layers when Manual GPU Memory owns the offload flags, then strips them, and the training guard reads _diffusion_manual_ngl(gpu_memory_mode, gpu_layers). /validate skipped both, so with gpu_layers: 0 and ["-ngl", "20"] the guard saw a zero-layer diffusion split, returned before the VRAM check, and the launch then put twenty layers on the GPU during training. The inverse pairing (gpu_layers: 20, -ngl 0) could 409 a load that never leaves the CPU.

It now runs the same translation and the same strip_shadowing_flags(..., strip_offload = True) under the same manual-only condition, before placement, so the guard receives the same layer count and the same list either way. Auto mode is untouched: there the flag is a pass-through the loader honours, and translating it here would invent a first-class value /load never set.

Three tests in test_validate_diffusion_extra_args.py: -ngl 20 over gpu_layers 0 reaches the guard as 20 with the flag stripped, -ngl 0 over gpu_layers 20 reaches it as 0, and an Auto-mode request keeps both the field and the flag as they were.

Guard managed-catalog responses across invalidation

If a managed-only request is in flight when a llama.cpp update or backend switch calls invalidateLlamaFlagCatalog, the old request can resume here and repopulate cachedManaged after it was cleared. Unlike the full-catalog request, this path has no generation check or TTL, and its unconditional finally can also clear a newer in-flight request, so the old backend's defaultParallelSlots may remain cached for the rest of the session and incorrectly allow or reject stored --batch-size values. Capture and verify the catalog generation before publishing this response, as the full-catalog path does.

Useful? React with 👍 / 👎.

Agreed. The full catalogue reads the generation before the request and checks it before publishing; this path had neither, and its finally was unconditional, so it could also clear a newer request in flight.

The reason it matters is the field I added: the denylist in this answer is Unsloth own and no binary changes it, but defaultParallelSlots travels beside it and that is the EFFECTIVE count, which depends on whether the probed binary supports --kv-unified. An in-flight managed request resolving after an update therefore put the old build slot floor back into the cache the invalidation had just cleared, where it would sit for the rest of the session, and the hidden hydration check would allow a stored --batch-size 2 on a build now serving four slots.

Same shape as the catalogue now: generation captured before the fetch, checked before cachedManaged is written, and the finally clears the in-flight promise only while it is still ours. Guarded by a source-level test alongside the existing catalogue one.

Preserve quoted leading-hyphen values as values

When a value-taking option is followed by an explicitly quoted value that begins with a hyphen, such as --chat-template '- hello', parseExtraArgs removes the quotes and extraArgFlagName classifies the resulting token as another flag. This call therefore reports the preceding option as missing its value and disables Load, even though the backend validator accepts the token list and forwards it verbatim. Preserve enough quote/token-position information to treat an explicitly quoted flag-shaped token as the pending option's value.

Useful? React with 👍 / 👎.

Real, and a false refusal, which is the worse direction. parseExtraArgs takes the quotes off, extraArgFlagName then reads - hello as flag-shaped, and the row reported --chat-template as missing its value and disabled Load, while validate_extra_args accepts the list and llama.cpp reads it correctly: for a value-taking option it takes the next argv element without looking at what it starts with.

The tokeniser now records which tokens the user quoted (argv has no room for that, so it stays in the editor) and the diagnostics consult it only in value POSITION. That distinction matters both ways:

• --chat-template "- hello" and --grammar "-x" are values, no error, and the value is not reported as an unknown flag either
• "--top-k" 20 is still a flag, because quoting out of habit is common and reading it as a value would refuse a list that runs
• a quoted token with no option in front of it has nothing to be the value of, so it is judged as written: unknown to this build, warned about, still passed, which is the answer the backend gives

Six assertions added, including that the token list itself is unchanged and only the quote marks are new.

Carry remembered arguments through runtime-only load paths

When a remembered GGUF is launched through a path that first calls applyModelLoadConfigToRuntime but does not attach that config to the selection, pendingLoadConfig is undefined here and the saved arguments are omitted. This affects the normal Hub launch in hub-page.tsx:1319-1338 and the training handoff in chat-page.tsx:3203-3216: applyPerModelConfigToRuntime has no field for these arguments, and /load only inherits from the same resident model, so a cold load or switch from another model silently runs without the arguments the user remembered. Pass the resolved config on those selections or otherwise carry its argument list into this load.

Useful? React with 👍 / 👎.

Confirmed on both paths. applyPerModelConfigToRuntime has no field for the launch flags, and /load inherits them only from the SAME resident model, so the Hub launch and the training handoff started cold (or switched from another model) without the arguments the user had remembered.

Both selections now carry the resolved config itself: hub-page.tsx passes rememberedConfig on the selectModel call beside keepSpeculative, and the handoff in chat-page.tsx passes the same object it feeds to applyModelLoadConfigToRuntime. Neither invents one when nothing is remembered, so the field stays absent and a resident model keeps its own flags, which is what the omission path is for.

The settings-page Apply was already fixed this way earlier; these were the two that went through the runtime alone. Guarded by a source-level test next to that one.

Size the batch floor with effective explicit slots

When the installed llama-server lacks --kv-unified and the user explicitly selects multiple Slots, this uses the requested count even though the backend clamps the launch to one slot. For example, Slots 4 with extra arguments --batch-size 2 is rejected in the editor and disables Load, while _effective_parallel_slots returns 1 and the backend accepts that exact command. The catalogue only publishes the effective default, so expose the clamp capability/effective selected count or leave this check to the backend when an explicit slot count may be clamped.

Useful? React with 👍 / 👎.

Right, and it is the same gap the published default had, one level along. The default is effective, but an explicit Slots value is chosen in this panel and never passes through the route, so the editor could not apply the clamp without being told it exists: Slots 4 with --batch-size 2 was refused here while _effective_parallel_slots returns 1 and the backend accepts that exact command.

/api/inference/llama-flags now publishes parallel_slots_clamped, computed by asking the same helper the load uses (_effective_parallel_slots(2) == 1), in the same worker thread as the default so nothing new touches the event loop. An unreadable probe reports False, keeping the ask, as everywhere else here.

The three floor sites (the row, the collapsed revalidation, the hidden hydration check) now share one effectiveBatchFloor() so they cannot drift, and a backend that publishes neither field reads as not clamped, which is exactly the behaviour those builds had before. Tests: the clamp helper against a build with and without --kv-unified and against an unreadable probe, the single-slot default still reporting the clamp off the loop, and a source-level check that one definition backs all three call sites.

Account for embedding slot clamping in the batch check

For an embedding GGUF with a micro-batch below the requested slot count, this checks the extra --batch-size against the pre-clamp slots even though LlamaCppBackend.load_model later reduces embedding slots to the effective micro-batch. For example, n_parallel=4, n_ubatch=2, and extra args --batch-size 2 is rejected with 400 here on a --kv-unified build, while the launcher deterministically clamps to two slots and that command is valid; the equivalent /validate check has the same mismatch. Include the embedding/micro-batch clamp when deriving the floor.

Useful? React with 👍 / 👎.

Confirmed. load_model reduces the slots to the effective micro-batch for an embedding GGUF before it launches, so n_parallel=4, -ub 2 and a pass-through --batch-size 2 launches at two slots where two is the floor, and both /load and /validate were refusing it.

Both floors now consult the same clamp, in _embedding_clamped_slots, layered on top of _effective_parallel_slots. It is asked only after check_batch_floor has already raised, so the GGUF header read is paid on the way to a 400 rather than on every load, and _is_embedding_gguf answers False for a header that cannot be read: the clamp can only ever turn a refusal into an acceptance, never the reverse, and never on a guess. Tests cover the clamped accept, the chat GGUF that is still refused, defaults clamping nothing, the floor of one slot, and -b 1, which stays refused because llama-server aborts on a batch of 1 at any slot count.

Validate manual offload arguments before stripping them

In manual GPU-memory mode, this new translation runs before the later validate_extra_args call, so syntax that /load rejects can be parsed and removed before validation sees it. For example, /validate accepts llama_extra_args=["--gpu-layers=20"] after translating it to gpu_layers=20 and stripping the token, but /load validates the original list first and returns 400 because llama-server does not accept attached values; malformed values such as -ngl bad can also raise an uncaught ValueError here instead of the intended 400. Validate the explicit list before applying the same translation and strip used by the load path.

Useful? React with 👍 / 👎.

Correct, and it also swallowed the malformed case. Reproduced both: /validate accepted ["--gpu-layers=20"] by translating it to gpu_layers=20 and dropping the token, while /load validated the original list and returned 400 ("llama-server does not read an attached value"), and -ngl bad raised an uncaught ValueError out of the parser rather than a 400.

validate_extra_args now runs on the resolved list before the manual -ngl translation and strip_shadowing_flags, so the preflight judges the same list /load does. Covered in test_validate_diffusion_extra_args.py: the attached form is a 400 naming the two-argument spelling, -ngl bad is a 400 rather than a crash, and a well-formed -ngl 20 still passes.

Preserve explicit empty arguments during override hydration

This collapses a resolved llama_extra_args: [] marker into the same return value as an override with no argument field, so callers cannot preserve the distinction the backend stores deliberately. When a quant has an explicit empty marker to suppress a bare-repository fallback while the same model is still resident with the old inherited arguments, ModelConfigPage sees stored.length === 0, leaves llamaExtraArgs undefined, and its next Load omits the field; /load then inherits the resident arguments instead of applying the saved clear. Return the field-presence state as well as its tokens so an explicit empty result hydrates to the explicit-clear state.

Useful? React with 👍 / 👎.

Right, and the tombstone exists precisely so that case is distinguishable. fetchLoadExtraArgs and resolveStoredExtraArgs now return {tokens, explicit}, and all three hydrating callers use it: the panel sets llamaExtraArgs to [] rather than leaving it undefined (only when nothing has been typed into the box in the meantime), and the background auto-load and the compare pane send the explicit empty list instead of omitting the field. Omitting it is what let /load inherit the resident model's arguments, which is the list the user had just cleared.

Covered by new cases in llama-extra-args-override-lookup.test.ts (a row carrying [] is explicit and stops the search; a row that matched on another field but carries no argument list is not explicit, so there is no clear to honour) and by the three call sites in llama-extra-args-panel-hydration.test.ts.