openclaw - 💡(How to fix) Fix discord/picker: structural 25-option / 5-row / 100-char limits constrain large wildcard configs

What is the limitation?

Discord caps a string select menu at 25 options and a message at 5 action rows. Every picker surface in the Discord extension is bounded by these limits, and the constraint shows up in non-obvious ways as soon as a config has more than ~25 providers or more than ~25 models per provider — which is the common case for provider/* wildcards (vLLM auto-discovery, OpenRouter, Together, etc.).

Where it bites today

• String select menus (25 options). The model dropdown and the (new) letter-range bucket select both have to fit in 25. With more than ~500 same-prefix items, even letter-range buckets cannot keep the bucket count ≤ 25 without resorting to coarse numeric chunking ("1-50", "51-100", …) that loses the alphabetical hint.
• Action rows (5 per message). A bucketed provider view spends rows on: bucket select (1) + provider buttons (up to 4) + nav prev/next (1 when paginated). That is already at the cap. There is no room for a "Recents" or "Reset" affordance on the same screen without dropping pagination, and a future per-row filter (e.g. by capability) cannot be added without ejecting an existing row.
• customId budget (100 chars). Every state field we need to round-trip through a click — provider id, picked model, runtime, bucket, page indices, user id — has to fit in the customId. Long provider ids (e.g. azure-openai-responses is 22 chars) plus a 20-digit Discord snowflake user id plus bucket fields routinely approach the cap, which is why extensions/discord/src/monitor/model-picker.view.ts had to be refactored in #86181 to derive bucket state from the durable fields rather than encode it on every button.

What #86181 ships and what it does NOT solve

#86181 adds a letter-range bucket select that engages when a provider or model list exceeds 25 items, and a numeric fallback when every item shares a first letter (e.g. all qwen3-*). It also dynamically resizes buckets so the bucket count never itself overruns the 25-option cap.

That is a UX win for the common 25-200 item range. It does not address:

1. Extreme breadth (1000+ items per provider). Numeric fallback produces 25 buckets each of 40+ items, so within-bucket the user is still scrolling a 40-option select that Discord truncates at 25. The user only ever sees the first 25 items of any bucket.
2. Single-message capacity. Even with buckets, the picker has no room for additional affordances (recents-on-screen, capability filters, runtime preview) on the same message without rearchitecting how rows are spent.
3. customId fragility. Every new state field added to the picker has to negotiate the 100-char ceiling. The current "derive on re-render" trick has a finite headroom — combining a long provider id, full snowflake user id, both buckets, a runtime, a pending model index, and a page already approaches the cap.

Possible next steps (not a decision)

• Autocomplete-driven entry for /model. Discord's slash-command autocomplete supports up to 25 hints per keystroke but is not capped on the search space itself. /model qwen could return the top 25 fuzzy matches across all providers, sidestepping the 25-option dropdown entirely. This works for /model <ref> but not for the no-arg /models browse flow.
• Multi-step modal flow. Use Discord's modal API for a provider → search → model sequence, with the modal's text field acting as a freeform filter. Heavier UX but bounded by neither the 25-option cap nor the 5-row budget.
• Server-side ephemeral session state. Instead of round-tripping every field in the customId, store picker state in a short-lived in-memory map keyed by a short session token. The customId would then carry only (session_id, action), freeing the entire 100-char budget. Trade-off: state lives outside the message, so a restart loses in-progress pickers.
• Per-row capability filters. Once the customId budget is solved, the picker could afford a "Filter: reasoning · multimodal · cheap" row that further reduces the within-bucket count below the 25-option ceiling.

Why this is a separate issue from #86181

The 25-item limitation is structural: it bounds every future change to the Discord picker, not just this one. Filing it as its own issue gives maintainers a place to track the constraint and weigh the next-step options against actual user pain rather than rolling a larger fix into a UX patch that already has a clear scope.