Apple cluster control is a technique for centrally managing multiple iPhones from one computer, without jailbreaking, without plugins and without dev boards.
This one answers: What Does a Xiaohongshu Post Cost on Apple Cluster Control.
A home goods seller came to me with a question. Hardware and licences worked out to just over eighty thousand. What does that come to per post.
I said the question was missing half. He was calculating the hardware, but on Xiaohongshu what decides whether you survive is the content line. Hardware is a one-time cost. Content happens every single day.
Break the cost of a post into four parts
Total cost divided by number of posts. The arithmetic is fine. The numerator is what goes wrong.
A complete numerator has four parts. The content itself, the hardware and licences, the sunk cost of the accounts, and operator time. Most people count only the second.
The first line, content, the largest and least computable
Xiaohongshu is a visual platform. A post needs images, a caption, and topics.
Where do the images come from. Shoot them yourself, and that is labour and hours. Source them, and you are dealing with rights. Generate them, and you are dealing with platform tolerance and quality. All three cost something, and none of them gets cheaper because you bought more devices.
Photography shows this most clearly. Thirty devices does not mean thirty times the material. The standard failure in matrix operations is exactly this. The fleet is ready, the content is not, and the workaround becomes posting the same thing with a different cover. That converts badly and raises the risk of accounts getting linked.
The better move is to work backwards. Decide how many decent posts you can produce steadily in a week, then let that number size the fleet. Do it the other way round and you will buy devices to sit and wait for material.
The second line, hardware and licences
This is the easiest line to compute and the easiest to overestimate.
Rough numbers. A device plus licence at two and a half thousand, thirty devices is seventy five thousand. Depreciated over two years, that is a bit over three thousand a month. Thirty accounts posting twenty times a month is six hundred posts, which puts hardware a little over five per post.
Seeing that number tells you something useful. Hardware is a very small share of the per-post cost. Cutting the fleet to save money and ending up unable to publish is the wrong calculation. That money is what makes the machine go.
The third line, the sunk cost of accounts
Overlooked, but real.
Accounts need warming up. Fresh accounts cannot run at full intensity for the first couple of weeks. During that period devices run and content gets produced, but nothing comes back. Every account goes through it once.
Accounts also die. Content problems, environment problems, or nothing detectable at all. So budget a loss rate. One spare for every twenty accounts is a reasonable starting point.
Add both of those to the numerator if you want a real per-post number.
The fourth line, time, the one that disappears from the sheet
Operator time is not just publishing. It is choosing what to make, reviewing what went out, handling comments and messages, reading the numbers, and adjusting course.
Automation removes the publishing block, maybe seventy percent of the operational work. The remaining thirty percent does not vanish. Somebody still has to look at the data and decide.
With nobody doing that, the setup is a machine that emits content and nothing else. A month in, the numbers are declining and nobody can say why.
When the per-post cost suddenly jumps
Three situations break the calculation.
Content capacity hits a ceiling. Past a certain fleet size the material runs out, repetition starts, engagement drops, and you spend more trying to recover the numbers.
Account loss rate climbs. Losses are baked in, but a block of accounts failing in a short window means environment or pacing, not normal attrition. Replacement then costs far more than budgeted.
Platform rules shift. Xiaohongshu has changed recommendation and review behaviour several times. Each shift invalidates some of what worked before. You either change the playbook or the cost goes up.
Back to the seller
He did not go to thirty devices. He started with eight and one person dedicated to making images. Three months in he told me the biggest discovery was that the bottleneck had never been the hardware.
The hard part of this calculation is not the arithmetic. It is admitting which line you left out.