The fastest way to look synthetic is to add two hundred viewers at once. Humans arrive in ones and twos. Kick's public count smooths over a window, and an audience reads a room the same way: a burst that appears from nowhere is a farm; a climb that takes a minute is a trickle of people opening the tab. We stage every ramp at twenty new workers per tick and refill as hosts free up, not because twenty is a magic number, but because it is slow enough to look human and fast enough that the deck still feels like it is doing something.
Twenty per tick is a spawn cap, not a marketing slogan. Each hunter takes its own semaphore slot and unique host inside the worker. A dead hunter is reaped so leftover hosts can be walked. Without a cap, spawn, refill, and the viewer poll all fight over the same resources, and the count freezes — which, from the audience's side, looks exactly like a drop. The cap is how the control loop keeps answering while the room fills.
Kick's count is eventually consistent. The number you care about is not how many sockets we opened this tick; it is the number Kick chooses to show on https://kick.com/api/v2/channels/<slug>. That number lags a poll or two behind a real fill, and it punishes a spike harder than a ramp. A sawtooth of connects and disconnects is a fingerprint. A flat hold after a staged climb is the curve a real room makes when people stay.
Presets encode the curve so you are not dialing it live. Steady Growth is a slow climb with flat retention — the default when you want the room to look occupied without announcing a launch. Launch Spike is faster but still staged: more of the twenty-per-tick budget, still no thundering herd. Chat Warmup pairs viewers with chatters so the room has voices before the count peaks. Each preset is a different host and chat behaviour, not just a number on a slider.
Save a preset and replay it. The point is not to invent a new curve every stream but to reuse one that already moved Kick's public count on your channel. Host hygiene travels with the preset: one unique host per session, a spare for the viewer poll, no shared IPs, no direct-connect fallback. Replaying a curve without that hygiene is replaying the shape and throwing away the reason it worked.
A spike is not only an audience tell. It is also how you saturate the token endpoint. Before a socket can hold, it has to ask Kick for a token, fail-fast, three seconds, no homepage warmup. Two hundred of those at once is a queue; twenty at a time is a line that moves. The token is the X-CLIENT-TOKEN header and nothing else — cookies and pretend-human sleeps are not what Kick uses to recognize a viewer. Cutting the warmup means a dead proxy fails in three seconds instead of dragging hunters for minutes while the curve you wanted never starts.
Retention smoothing is the other half of not looking spiky. We hold sockets until you stop them or the host dies — no short-lived ping cap. A viewer that arrives and leaves in eight seconds is worse than a viewer that never arrived: Kick's window saw the join and the leave, and the public count saws. Holding until death, then reaping and refilling from the pool, is how a dip of one host gets absorbed instead of printed as a cliff.
The pool is the ceiling, not the ops deck slider. You can ask for four hundred, but you will only get as many viewers as you have surviving unique hosts. If you need more than the free pool will honestly hold, bring your own ISP list. Dedicated ISP addresses stay put for the life of a session; rotating residential or mobile gateways collapse to one host and make the ramp look like a single person with many tabs. The list you control is the one that decides whether a preset is a curve or a wish.
Watch the fill the way an audience would. Start on a live low-viewer channel, note Kick's viewer_count before you hit Start, then watch it through the ramp. Active Bots climbing is not the pass criterion. Kick moving is. If Active is full and Kick has not moved after sockets are up, that is a failed run — diagnose, do not call the dashboard done because the slider looks busy.
Two numbers on the deck look alike and mean different things. Active Bots counts live websockets. Live Viewers counts Kick's public viewer_count, fetched through a reserved unique host every few seconds on a background thread. They diverge whenever a socket holds but never converts, which happens. A ramp that only reports Active is a ramp that is lying to you about the curve your audience sees.
The honesty note belongs on a growth post as much as on an engineering one. Inflating viewer numbers violates most platforms' terms of service, and Kick is no exception. Staging a ramp at twenty per tick does not make a hold compliant. What it does is make the run look less like a block of identical viewers arriving at once. That is a realism question, not a safety question. Anyone who tells you a slower curve is 'allowed' is selling you something.
Chat changes the shape of a launch even when the viewer ramp is the same. A Launch Spike with a silent room is a count with no voices; Chat Warmup spends a few minutes establishing personas before the count peaks, on a separate Socket.IO surface with its own hosts, so chatters and viewers never share an address. Shared IPs are the fastest way for two systems to fingerprint each other. If you run chat, budget hosts for both, plus a spare for each.
What a good fill looks like in the log: sockets come up over a minute or two, Active climbs toward the requested count as unique hosts allow, and Kick's public number follows a poll or two behind. The gap between 'Active is full' and 'Kick agrees' is measured in polls, not minutes. A spike compresses that whole story into one tick, which is why it reads as a farm even when every host is real.
Drops during a ramp are not something you eliminate — they are something the twenty-per-tick refill is designed to absorb. A host dies, its hunter is reaped, its slot frees, the next tick takes up to twenty new workers from the pool, and the count dips for a poll or two before it recovers. The difference between a ramp that 'looks spiky' and one that holds is whether that recovery is faster than Kick's own smoothing window.
There are no fake channel IDs in this system. If Kick does not resolve your slug to a channel id, the bot stops. We do not pad a slug and do not substitute a fallback id. A ramp against the wrong channel, or against a number we invented, is not a ramp you can verify. When the run reports a curve, it is a curve for the channel you named, measured by Kick.
A practical sequence. Pick Steady Growth. Run twenty-five on a live low-viewer channel. Watch Kick, not only the deck. If the curve fits, save the preset and replay it. If you need a faster open, switch to Launch Spike — still staged, still twenty per tick, still one host per session. If the room should already be talking when people arrive, Chat Warmup first. If four hundred is the number and the free pool will not hold it, bring your own ISP list before you raise the slider.
The loop that keeps the curve alive is deliberately boring. Every tick it checks who is dead, reaps their hunter, frees the slot, and refills from the pool, capped at twenty so spawn never blocks the poll or the token endpoint. Boring is the feature. A loop that tries to spawn everything at once is a loop that stops answering the dashboard, and a dashboard that stops answering looks like a drop even when every socket is fine.
Do not confuse a preset name with a promise. Launch Spike will not put two hundred on Kick in one poll, and Steady Growth will not hold a number the pool cannot staff. The names describe the shape we will attempt; unique hosts describe the shape we can keep. If a replay comes in under the last run, check the live unique-host count before you blame the curve. Most 'the preset broke' reports are a smaller pool wearing the same label.
One more operator tell that is not an audience tell: Status stuck on Starting while Active is already climbing is a UI lag, not a spike. Status stuck on LOADING_PROXIES after sockets are up is a bug we already refused to ship — a free-list refresh must not overwrite running. If you ever see the deck call a live hold an error because the list hiccuped, treat that as a product failure, not as a reason to restage the ramp.
So the recipe for a ramp that does not look spiky is: twenty per tick, one host per session, a spare for the poll, sockets held until death, presets you actually replay, and a dashboard that measures Kick instead of itself. It is less glamorous than 'instant viewers,' and it is the only version that still looks like a room after you watch the public count for an hour.