[Feature Request] In-Project Model Hot-Swapping & Migration Wizard for Workspaces with Deprecated Models

Problem Description

When foundational models undergo deprecation or backend sunsetting (e.g., glm-5-turbo transitioning to glm-5.3 / glm-5.3-Flash), existing user projects in chat.z.ai / zcode.z.ai enter a hard-locked failure state:

1. Unresponsive Model Selector: The in-project model dropdown locks or fails to populate active models because the project container metadata is tightly coupled to the invalid legacy model identifier.
2. Project Stranding: Large, complex projects (such as multi-tool workspaces with 300MB+ of dependencies, configurations, and tool scripts) cannot switch execution engines in-place, risking total developer lock-out or forcing painful manual recreation.

Community Case Reference

• Author: mdshhaahinali_15364 (Discord: md shhaahin ali)
• Discord Thread: https://discord.com/channels/1346756824233148527/1547966393797050498
• Affected Project: "Blogypass Multitool" (300MB+ multi-tool project stranded on deprecated glm-5-turbo)

Technical Analysis & Failure Points

1. Tight Coupling of Container Metadata: Project runtime sandboxes currently bind model selection at workspace creation time. When the backend inference gateway decommissions the model tag, the UI fails to populate alternative active models.
2. Lack of In-Project Hot-Swapping: Developers cannot dynamically switch the underlying engine between flagship (GLM-5.3) and lightweight (GLM-5.3-Flash) within the same persistent container without abandoning project history.
3. Absence of Server-Side Project Cloning: When an environment breaks, users must manually download massive zip archives (often hundreds of megabytes) and attempt to re-hydrate a new session through conversational chat prompts.

Recommended Solutions & Feature Requests

1. Frontend: Graceful Fallback & In-Place Model Re-Binding (High Priority)

• Interactive Recovery Banner: If a project's configured model is decommissioned or returns a 404/410/deprecated status, display:

  "Your current model [Model Name] has been retired. Please select an active model to continue."

• Always-Active Dropdown: Never disable or freeze the dropdown. Always populate all currently active and entitled models (GLM-5.3, GLM-5.3-Flash).
• In-Place Model Re-Binding: Allow the user to select an active model, updating the container runtime configuration and triggering an environment re-connect without wiping /home/z/workspace.

2. Gateway: Dynamic Alias Forwarding for Deprecated Models

• Implement server-side alias forwarding for grandfathered projects:
  • glm-5-turbo -> automatically forward to glm-5.3-flash (or glm-5.3) with a non-breaking deprecation warning header (X-Model-Deprecated: true).
  • Prevents existing workspaces from abruptly freezing when model names are updated in public documentation.

3. Workspace: Native "Clone / Migrate Project to New Model" Workflow

• Add a 1-click button under Project Settings: "Clone Project with New Model".
• This spawns a fresh container, duplicates the persistent volume/tree server-side, and binds the newly selected model.
• Benefits: Eliminates the need for users to download and re-upload 300MB+ archives over consumer connections, saving both client bandwidth and cluster ingress overhead.

Regards,
Roman M.

• Contributor / Ambassador at Z.ai
• Brain Backup: https://github.com/romangalaxys10-spec/Antigravity-Brain-Backup

No repository files, tests, or implementation entry points are named. Start by locating the model-selection UI, workspace configuration, and inference gateway components, then check any existing persistence or cloning flows. Done would require an agreed and tested design covering fallback, rebinding, aliasing, and project migration.