Kimi K3 launched on a Wednesday. By Friday, Moonshot AI stopped accepting new subscribers because demand exceeded compute capacity. Existing users kept access; new users got a closed door.
As a product designer, this is the scenario I plan for: the product works, the marketing lands, the demand is real-and the infrastructure cannot keep up. What does the user experience look like on that day?
Most AI product onboarding flows assume unlimited capacity: sign up, get access, start using. When capacity runs out, the flow breaks. Users who signed up expecting immediate access now face a waitlist, a message, or silence.
K3's response was clear: stop new subscriptions, communicate the reason, promise reopening. That is operationally sound. But from a UX perspective, the user who clicked "subscribe" and got "unavailable" had a broken expectation.
An AI product onboarding should have a third state beyond "available" and "full":
| State | User sees | System does |
|---|---|---|
| Available | "Start now" | Grants access immediately |
| Waitlist | "Join the queue" | Records interest, sets expectation |
| Existing-user priority | "Your access is preserved" | Continues service for current users |
The key design principle: never let the user discover capacity limits by failing. Tell them before they start the flow.
If you must new signups, the waitlist page should answer these questions within 10 seconds of reading:
Kimi's announcement covered points 1 and 4. Points 2 and 3 were less defined. For a product you are designing, define them before you need them.
Step 1: Check capacity state (available / waitlist / full)
Step 2: If available -> normal signup
Step 2: If waitlist -> show waitlist contract (why, when, what, who)
Step 3: Set up account in background (so when capacity opens, onboarding is instant)
Step 4: Notify user when access opens (email, push, in-app)
This flow means that even on the worst day, the user has a clear path forward instead of a dead end.
Kimi announced they would split subscriptions into "main product" (Kimi Web, App, Work) and "Kimi Code" to allocate compute more precisely. From a product design perspective, this is capacity-based tiering: instead of one product that needs all the compute, two products that can be scaled independently.
If you are designing an AI product, consider from day one whether your feature set can be split for capacity reasons-not just for pricing or marketing reasons.
I have not designed Kimi's actual onboarding flow. This is a design protocol based on the publicly reported events of K3's launch week, applied to general AI product onboarding principles. It is a framework for planning, not a critique of Kimi's specific UX decisions.
Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project. MonkeyCode is an open-source AI coding platform: https://github.com/chaitin/MonkeyCode