[Feature]: expose remaining vision sidecar controls in Dashboard #1201

Area

Dashboard / vision sidecar configuration

Current status

This request is partially implemented.

The Dashboard now exposes the main Vision sidecar routing controls:

• vision model selection;
• backend-aware model selection;
• model-aware reasoning effort;
• filtering so known text-only models are not offered as vision describers.

The current implementation was completed through the vision-sidecar stack:

• feat(vision): filter sidecar describers by real image-input capability #1326 — image-capability eligibility
• feat(management): publish vision describers and refuse the blind ones #1327 — management API model list and validation
• feat(gui): show only usable vision describers in the delegation card shape #1328 — Dashboard Vision sidecar card

The remaining work is the configuration that still requires editing config.json manually.

Remaining problem

The current Dashboard Vision sidecar card does not expose all of the existing visionSidecar configuration.

In particular, users still cannot manage these settings from the Dashboard:

{
  "visionSidecar": {
    "enabled": true,
    "maxDescriptionsPerTurn": 8,
    "timeoutMs": 45000
  }
}

maxDescriptionsPerTurn is already supported by /api/sidecar-settings, but it is not surfaced in the Dashboard.

enabled and timeoutMs are supported by the runtime/config contract but are not currently exposed by the sidecar management API used by the Dashboard.

The current documentation therefore still requires users to edit config.json to disable the Vision sidecar.

What OpenCodex should do

Complete the existing Dashboard Vision sidecar configuration surface.

1. Enable / disable control

Add an explicit toggle:

Vision sidecar    [ On / Off ]

It should persist:

visionSidecar.enabled

Requirements:

• preserve the current default behavior for existing users;
• disabling must prevent new Vision sidecar descriptions;
• re-enabling must preserve the user's existing model, backend, reasoning, timeout, and limit settings;
• disabling should not delete the configuration.

2. Description limit

Expose:

visionSidecar.maxDescriptionsPerTurn

as a positive-integer control.

The management API already understands this field, so the Dashboard should hydrate, edit, save, and preserve it.

3. Timeout

Expose:

visionSidecar.timeoutMs

through /api/sidecar-settings and the Dashboard.

The UI should validate it using the same runtime/config bounds rather than inventing a second contract.

4. Preserve the existing model controls

Do not regress the already-landed behavior:

• eligible Vision model picker;
• backend provenance;
• OpenAI / Anthropic routing;
• model-aware reasoning effort;
• support for custom/unknown model IDs where the server cannot prove the model is text-only.

Example interface

Vision sidecar                                      [ Enabled ]

Model
[gpt-5.6-luna                         ▾]

Reasoning
[medium                                ▾]

Advanced
Maximum descriptions per turn   [ 8     ]
Timeout                           [ 45000 ] ms

The exact layout can follow the existing Dashboard settings patterns.

Management API

GET /api/sidecar-settings should return enough state for the Dashboard to render the complete configuration, including:

{
  "vision": {
    "enabled": true,
    "model": "gpt-5.6-luna",
    "backend": "openai",
    "reasoning": "medium",
    "maxDescriptionsPerTurn": 8,
    "timeoutMs": 45000
  }
}

PUT /api/sidecar-settings should allow updating the same fields with strict validation.

Partial updates must preserve fields that were not supplied.

Acceptance criteria

• Vision model can be selected from the Dashboard.
• Vision backend/model routing is managed through the Dashboard.
• Vision reasoning effort can be configured from the Dashboard.
• Known text-only describers are filtered/rejected.
• Vision sidecar can be enabled/disabled from the Dashboard.
• maxDescriptionsPerTurn can be configured from the Dashboard.
• timeoutMs can be configured from the Dashboard.
• /api/sidecar-settings round-trips all Dashboard-managed Vision settings.
• Existing settings survive disable/re-enable and unrelated saves.
• GUI and management-API regression coverage exists for the remaining controls.

Relationship to the original request

The original broad request to expose the Vision sidecar in the web UI is mostly complete.

This issue now tracks only the remaining controls that still require manual configuration.

If additional Vision-sidecar features are proposed later, they should be tracked separately rather than expanding this issue again.

Checks

• Existing Dashboard implementation was re-audited.
• Already-delivered model/backend/reasoning work is removed from the remaining scope.
• Remaining config-only controls are explicitly identified.
• Remaining Dashboard controls implemented.