[Feature Request] Model capacity indicator & queue system for chat.z.ai

Feature Description

Add a real-time capacity indicator to the chat.z.ai web application that shows users whether the AI model is currently at full capacity, and optionally implement an automatic queue system for messages.

Problem Statement

Currently, users have no way of knowing if the model is at maximum capacity before sending a message. The workflow is:

1. User types a message
2. User presses Send
3. User waits (hoping the model isn't overloaded)
4. Either: Message processes successfully OR user gets an error/timeout

This creates:

• ⏱️ Wasted time waiting for responses that may never come
• 😤 Poor UX — users feel like they're "gambling" on each message
• 📉 Frustration — especially for longer prompts where the wait time is significant

Proposed Solution

Part A: Capacity Status Indicator

A visual UI element in the chat interface that shows real-time model capacity status:

Visual Design Options:

┌─────────────────────────────────────┐
│ 🟢 Model Available    [Send Enabled] │  ← Normal operation
│ 🟡 High Load         [Send Enabled] │  ← Warning: may be slower
│ 🔴 At Capacity       [Send Disabled]│  ← Cannot process now
│ ⚡ Queue: 3 ahead    [Queued]       │  ← In queue (Part B)
└─────────────────────────────────────┘

Placement Suggestions:

• Near the input box — Bottom of chat window, adjacent to Send button
• Header area — Top of chat interface, always visible
• Status bar — Thin bar above or below input area

Behavior:

• Green (Available): Model has capacity, normal operation
• Yellow (High Load): Model busy but accepting requests, expect delays
• Red (At Capacity):
  • Show warning message
  • Disable Send button (prevent failed submissions)
  • Display estimated wait time if available
• Polling: Update status every 5-10 seconds via WebSocket or REST ping

---

Part B: Automatic Queue System (Enhanced)

When the model is at capacity, instead of blocking the user entirely:

How It Works:

1. User types message and presses Send (or presses "Queue")
2. If model is at capacity, message enters queue position
3. UI shows: "You're #3 in queue. Estimated wait: ~2 minutes"
4. When capacity opens, message automatically submits
5. User receives notification/response normally

Queue Features:

• ✅ Position indicator: Shows current queue position
• ⏱️ ETA display: Estimated time based on average processing
• ❌ Cancel option: User can remove themselves from queue
• 🔔 Notification: Alert when message is being processed
• 💾 Persistence: Queue survives page refreshes (session-based)

Edge Cases:

• Queue limit: Max 10-20 messages per user/session to prevent abuse
• Timeout: Auto-remove from queue after 10 minutes if not processed
• Session expiry: Clear queue when session ends

Technical Implementation Suggestions

Backend Changes:

1. New Endpoint: GET /api/v1/model/status
   Response: {
     "status": "available" | "high_load" | "at_capacity",
     "current_load": 85,
     "max_capacity": 100,
     "queue_position": null | number,
     "estimated_wait_seconds": null | number
   }

2. New Endpoint: POST /api/v1/messages/queue
   Response: {
     "queued": true,
     "position": 3,
     "estimated_wait_seconds": 120,
     "queue_id": "uuid-here"
   }

3. WebSocket Event: model:status:update
   Push real-time capacity changes to connected clients

Frontend Changes:

// Pseudocode for capacity check
const checkCapacity = async () => {
  const status = await fetch(/api/v1/model/status);
  updateUI(status);
  
  if (status.status === at_capacity) {
    disableSendButton();
    showQueueOption();
  }
};

// Poll every 8 seconds
setInterval(checkCapacity, 8000);

User Experience Flow

Before (Current):

User types → Sends → Waits blindly → Error? → Retry? → Frustrated 😩

After (Proposed):

User sees 🟢 → Types → Sends → Works! ✅
                    ↓
User sees 🔴 → Sees warning → Queues or waits → Auto-sends → Happy 😊

Benefits

Benefit	Impact
Reduced frustration	Users know what to expect before waiting
Better resource management	Server doesn't process doomed requests
Professional feel	Competitors like ChatGPT/Claude show status indicators
Trust building	Transparency about system status
Lower support load	Fewer "is it broken?" complaints

Priority Assessment

• Effort: Medium (backend endpoint + frontend component)
• Value: High (affects every user during peak times)
• Urgency: High (peak-time UX is currently poor)

Reporter Information

• Source: Discord (#feedback channel)
• Reporter: Rousev [PEAK]
• Timestamp: 2026-07-27 ~6:31 PM - 6:34 PM
• Original Context: https://discordapp.com/channels/1346756824233148527/1531306147104161802

---

This feature request was submitted on behalf of user feedback from Discord.

No repository files, tests, or existing entry points are named. Start by reviewing the proposed model-status and message-queue API contracts and the chat input/send UI scope, then clarify whether both parts are required; done should include an agreed design, implementation scope, and validation for status updates, queue behavior, cancellation, persistence, and failure cases.