You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Settings: the model capability fields the schema already supports are not editable in any UI
#8872
Settings: the model capability fields the schema already supports are not editable in any UI
Summary
The llm-pi-ai provider schema declares per-model capability fields — input (modalities), reasoningEfforts (level → wire value, or false) and compat — and the schema's own
documentation names "what a configuration UI renders" as one of its concerns. But the entry
exposes no volatile fields to the settings service, so no configuration surface offers an
editor for these fields. Today the only way to set them is editing profiles/<profile>/cordis.patch.yml by hand (or by script).
Evidence (0.2.0-rc.2, measured 2026-10-04)
modelFields carries input: z.array(z.union(MODALITIES)) (modalities text/image), reasoningEfforts: z.union([z.const(false), reasoningEfforts]) (levels off/minimal/low/medium/high/xhigh/max) and compat: compatProfile — for both provider models lists and modelOverrides.
The settings import never migrates the llm-pi-ai section: the write path requires a
composed entry with volatile fields and refuses it ("no volatile fields"), so the values
survive only in the renamed legacy document until a hand-run migration writes them into the
patch layer.
A configuration-surface save rewrites the patch entry wholesale. Fields the surface does not
model — for instance per-model input written by a script — do not survive a later GUI edit
of the same entry, so hand-written capability data is not durable against the UI.
Impact
Per-model vision gating and reasoning-level dispatch require hand-edited YAML. On our
deployment that meant writing input: [text, image] for 34 gateway models by script, and
knowing a GUI settings edit can silently drop it again.
Suggested direction
Expose the llm-pi-ai entry — or a dedicated model-capability sub-editor — with volatile
fields for input, reasoningEfforts and compat, or have a capability editor write modelOverrides. The schema already validates and resolves every one of these fields; the
gap is purely the missing surface.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Settings: the model capability fields the schema already supports are not editable in any UI
Summary
The
llm-pi-aiprovider schema declares per-model capability fields —input(modalities),reasoningEfforts(level → wire value, orfalse) andcompat— and the schema's owndocumentation names "what a configuration UI renders" as one of its concerns. But the entry
exposes no volatile fields to the settings service, so no configuration surface offers an
editor for these fields. Today the only way to set them is editing
profiles/<profile>/cordis.patch.ymlby hand (or by script).Evidence (0.2.0-rc.2, measured 2026-10-04)
modelFieldscarriesinput: z.array(z.union(MODALITIES))(modalitiestext/image),reasoningEfforts: z.union([z.const(false), reasoningEfforts])(levelsoff/minimal/low/medium/high/xhigh/max) andcompat: compatProfile— for both providermodelslists andmodelOverrides.llm-pi-aisection: the write path requires acomposed entry with volatile fields and refuses it ("no volatile fields"), so the values
survive only in the renamed legacy document until a hand-run migration writes them into the
patch layer.
model — for instance per-model
inputwritten by a script — do not survive a later GUI editof the same entry, so hand-written capability data is not durable against the UI.
Impact
Per-model vision gating and reasoning-level dispatch require hand-edited YAML. On our
deployment that meant writing
input: [text, image]for 34 gateway models by script, andknowing a GUI settings edit can silently drop it again.
Suggested direction
Expose the
llm-pi-aientry — or a dedicated model-capability sub-editor — with volatilefields for
input,reasoningEffortsandcompat, or have a capability editor writemodelOverrides. The schema already validates and resolves every one of these fields; thegap is purely the missing surface.
All reactions