Model Switching Without Stale Controls in Text-to-Image UIs

Question

A text-to-image control panel usually exposes a model picker, prompt, aspect ratio, and sometimes a resolution selector. The difficult part is not rendering those controls. It is keeping every selected value valid after one upstream choice changes.

Suppose a user chooses a widescreen ratio and a high resolution under Model A, then switches to Model B. If the interface keeps the old values even though Model B does not support them, the next request can fail late or, worse, be silently coerced into a different format. A more reliable design treats model capabilities as a constraint graph and reconciles dependent state before submission.

Keep capabilities as versioned data

Do not spread model-specific conditions across components. Normalize the current server response into one capability record per model:

type ModelCapability = {
  id: string;
  promptLimit: number;
  ratios: string[];
  resolutions: string[];
  requiresLogin: boolean;
  available: boolean;
};

type Selection = {
  modelId: string;
  ratio?: string;
  resolution?: string;
};

The record is a current contract, not an evergreen promise. A cached response should carry a fetched timestamp or version so the client can refresh it and explain when a previously valid option has disappeared.

Reconcile downstream selections

Model is the root of the dependency graph. Ratio depends on model, and resolution may depend on both model and ratio. When the root changes, validate dependent values in order:

function reconcile(
  selection: Selection,
  capability: ModelCapability
): Selection {
  const ratio = capability.ratios.includes(selection.ratio ?? "")
    ? selection.ratio
    : capability.ratios[0];

  const resolution = capability.resolutions.includes(
    selection.resolution ?? ""
  )
    ? selection.resolution
    : capability.resolutions[0];

  return { modelId: capability.id, ratio, resolution };
}

In a real product, the resolution list may also be derived from the chosen ratio. The important behavior is explicit invalidation: reset an incompatible value visibly, tell the user why it changed, and prevent submission until the reconciled selection passes validation.

Avoid copying every derived option into independent component state. Keep the capability map as the source, store only the user's selection, and derive the visible choices. That removes a class of bugs where a dropdown updates but a hidden request payload still carries an older value.

Freeze a request snapshot

The UI may refresh capabilities while an asynchronous generation is running. The result must still be associated with the exact prompt and settings accepted for that task. Create an immutable request snapshot at submission:

type RequestSnapshot = {
  prompt: string;
  modelId: string;
  ratio?: string;
  resolution?: string;
  capabilityVersion: string;
  submittedAt: string;
};

Render task history from this snapshot rather than from the current control state. If the user changes the form while a task is processing, the completed image should not inherit the new labels. This also makes regeneration honest: the product can either repeat the original snapshot or create a clearly identified revised request.

Treat no-sign-up access as a capability

Guest access should not be one global boolean when only some models or operations allow it. Model the execution requirement alongside the selected capability. A supported guest model may offer limited free credits without sign-up, while another model or account feature may require authentication. The client should show the gate before submission instead of presenting a surprise login after the prompt is complete.

This is also why copy such as "all models are free" or "no account is ever needed" becomes fragile. Interface text should describe the current selected path, and the server must remain the final authority.

Separate task success from result approval

A valid request can still produce an image with poor prompt fit, malformed text, unwanted artifacts, or rights concerns. Represent system completion and human acceptance as different states. After a task succeeds, let the user inspect the full composition, zoom into details, compare it with the request snapshot, and then choose download, regenerate, revise, continue editing, or discard.

The public Image to Image Generator text-to-image page is one concrete example of a browser flow with current model-dependent controls, task progress, preview, download, regeneration, and an editor handoff. It is a reference for the workflow, not evidence that any model, limit, credit cost, account gate, result quality, or processing time is permanent.

Test the dependency edges

The highest-value tests exercise transitions, not isolated dropdowns:

• switch from a model with many ratios to one with fewer ratios
• remove the currently selected resolution during a capability refresh
• require login after the user changes models
• refresh capabilities while a task is processing
• restore a recent task while the current catalog differs from its snapshot
• double-click submit while the first request is unresolved

Assert that the outgoing payload is valid against the same capability version displayed to the user, and that the task history retains the submitted snapshot.

Conclusion

A robust text-to-image interface is a small constraint system. Centralize current capabilities, derive dependent options, invalidate stale selections visibly, freeze accepted requests, model guest access at the selected-path level, and keep result approval separate from API success. These patterns make changing model catalogs easier to operate without turning dynamic product facts into permanent UI assumptions.