The model choice is also a UX choice
You don't pick a backbone in a vacuum. The paradigm you pick determines which UX patterns are possible, which are wasteful, and which are required.
Dense models — predictable UI
- Predictable per-token latency makes streaming UIs simple. You can show a typewriter effect with confidence.
- Cost is roughly linear in user activity, so you can size your billing tiers cleanly.
- Capacity planning is multiplication. No magic.
MoE models — different infra story
- Lower per-token compute means you can serve more tokens per dollar at scale.
- But total memory cost dominates. You need GPUs proportional to total params, not active.
- Throughput is batch-size sensitive — uneven expert load can cause tail-latency surprises. Production teams need to account for this in capacity planning.
Reasoning models — the UX changes
- Variable response time means you need streaming UIs with progress indicators ("Thinking..." for some duration), not just a typewriter effect.
- Higher per-request costs require usage caps, tiered pricing, or thinking-budget controls in the user-facing settings.
- Visible-CoT designs need a UI surface for the thinking text — collapsible, summarized, or styled differently from the answer.
- Latency budgets must explicitly include thinking time. A "30 second answer" might be 25 seconds of thinking and 5 of output.
The product-architecture loop
Most well-designed AI products commit to one paradigm and design the UX around it. Cursor's autocomplete is dense and fast because anything else feels broken. ChatGPT's "thinking..." indicator is a UX accommodation for reasoning latency. Claude.ai's collapsible thinking blocks are a deliberate visibility design. Each of these is a downstream consequence of an architectural choice.
If you are building
Pick the paradigm first, design the UX next. Designing UX first and then trying to retrofit a reasoning model into a low-latency surface is how you end up with a chatbot that feels broken when thinking is on.