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?
The onboarding failure mode
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.
Designing for the capacity-overflow day
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.
The waitlist contract
If you must pause new signups, the waitlist page should answer these questions within 10 seconds of reading:
- Why is access paused? (Be specific: "demand exceeded our compute capacity")
- When will it reopen? (Give a range, not "soon")
- What happens to my account in the meantime? (Nothing? A limited tier?)
- Will existing users be affected? (Explicitly: no)
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.
The onboarding flow that survives
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.
What Kimi's split tells us
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.
What I have not designed
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.
Sources
- K3 launch: Moonshot AI, 2026-07-16
- Subscription suspension: Moonshot AI announcement, 2026-07-19
- Subscription split plan: announced in the same suspension notice
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
