X vs Bluesky vs Threads: Which Network Model Wins

X, Bluesky and Threads are three different answers to the same question: how do you run a public network for short posts and pay for it? X sells paid membership tiers. Threads started from an account system a company already had. Bluesky built an open protocol so that accounts and moderation choices can move. None of them wins outright, and which one to learn from depends on what you want to control.

This guide compares the business and governance models, not the user experience. It is written for an operator deciding what to borrow when starting a new network, perhaps from a ready-made X clone script or a custom build. We describe each network from its own published pages, as of October 2026, and we give no user or revenue figures because those change and we have not verified current ones.

Three networks, three bets

X: membership is the product

X's Premium help page lists three paid tiers: Basic, Premium and Premium+. The checkmark appears on eligible Premium and Premium+ profiles after a review, and those subscribers can apply for Original Content Rewards and Creator Subscriptions. The bet is that an account is worth paying for, and that paying members create a base from which creators can be paid. We cover the details in X verification and paid tiers explained and the payout side in how X creator payouts work.

Threads: the graph came with the parent

Meta's launch announcement says Threads uses Instagram credentials to sign in. That is the central design decision: a new app could ask existing Instagram users to join with the account and the identity they already had. The same announcement describes posts of up to 500 characters, with links, photos and videos, and says Meta was working to make Threads compatible with open, interoperable social networks. The bet is distribution: a new network starts with an audience because someone else already built one. A later Meta page may describe different limits or features, so read the current version before you quote any detail.

Bluesky: the protocol is the product

Bluesky's About page describes itself as building an open foundation for the social internet, built on open protocols. The AT Protocol documentation explains the mechanics: permanent identifiers for accounts, signed data repositories held by personal data servers, relays that aggregate updates, and app views that provide the network-wide counts, search and discovery. The bet is that a network built on a protocol lets users, developers and third parties take part without owning the whole stack.

Comparison table

Where the table says "check" or "nothing we verified", we do not know the current state from a primary page we opened, and we would rather leave it blank than guess. For the open-protocol side of the comparison in more depth, see Mastodon vs Bluesky vs a private network.

Cold start: how each got its first users

Every network has to answer why anyone should join an empty room. The three approaches are different, and only some can be copied.

• Existing graph (Threads). Sign-in with an existing account removes the empty-room problem. The cost of acquiring the audience was paid years before by another product. A small network cannot copy this directly.
• Brand pull (X). An established name carries an audience that is already there and is willing to pay for status or reach. Again, this is an asset built over years.
• A story and a protocol (Bluesky). A different promise attracts people who want something other than the incumbents: ownership, choice, portability. Part of that promise is available to anyone who can explain it clearly.

What a new network can borrow is the structure behind each approach. Offer a reason to join that the big networks cannot, such as a language, a profession or a rule set. Make the first conversations visible. Let members bring people with them. Our guides on the community cold start problem and on how to start a microblogging platform walk through the seeding steps.

It also helps to be honest about size. A niche network does not need millions of members. It needs enough active people that a visitor sees a conversation within seconds. A closed group of a few hundred who post daily feels alive; a public network of thousands who never post feels dead.

Moderation approaches

Moderation is where the three models differ most, and it is where an operator has the most to decide.

Central staff plus rules (X and Threads)

Both X and Threads rely on a company writing rules and enforcing them. Meta's launch post describes Community Guidelines enforcement and says third-party partners could review and rate misinformation on Threads. This model is simple to explain and fast to act on, and the company carries full responsibility for the result.

Crowd context notes (X)

X also runs Community Notes, where volunteer contributors write context and rate each other's notes. A note is shown only when contributors who have disagreed in past ratings agree it is helpful. It adds context; it does not remove posts or replace staff. We explain it in Community Notes explained.

Layered labelers (Bluesky)

Bluesky's post on stackable moderation describes a layered approach. The company runs its own moderation team and automated systems as the default layer. Third parties can run labeling services, built with an open-source tool called Ozone, and users can subscribe to them as easily as following an account. The AT Protocol moderation guide frames this as separating speech from reach: the underlying data stays permissive, while the layers above it decide what is shown to whom.

A small network will usually start with central staff, because the first thousand members need clear answers. Add the other layers when volume justifies them. Our guides on content moderation models and on moderating an online community at scale explain when to add what. The operator console we ship has a report queue, five graded actions and an audit log, which is the staff layer in working form.

Money

The three networks make the revenue question visible in different ways.

• Subscriptions (X). The Premium help page describes tiers with different benefits, and the revenue comes from members. See how X and Twitter make money for the advertising and data lines that sit next to it.
• Optional paid features (Bluesky). Bluesky's funding post says the network will always be free to use and that it will develop a subscription model for features such as higher-quality video uploads or profile customizations. It states that it will not uprank accounts simply because they subscribe, and it describes a goal of a voluntary monetization path for creators. These are statements of plan, so check the current state before you rely on them.
• Parent company (Threads). The pages we opened do not describe a revenue model for Threads, so we make no claim. What the launch post does show is that the app sits inside a company with an existing account system.

The lesson for an operator is that the money line shapes the product. A paid tier makes verification and perks necessary. A free network with optional extras needs low running costs and a plan for the first expensive feature, usually video. A network inside a larger company can postpone the question, but a standalone network cannot. Our X clone business model page shows how the member tiers, creator subscriptions, tips and ad campaigns fit together for an operator.

A worked example: three founders, one niche

Say three founders each want a network for the same niche, independent game developers. Numbers here are invented to show the reasoning.

1. Founder A copies the X model. Free tier, a paid tier at 5 a month with a badge and longer posts. With 2,000 active members and 8% on the paid tier, that is 160 payers and 800 a month before fees. It works if the badge means something, so A must run a review queue and answer impersonation reports.
2. Founder B copies the Threads shortcut. B has a large newsletter and invites subscribers to sign in with their newsletter account. Onboarding is fast, but B now depends on the newsletter platform's rules and cannot take that identity data elsewhere.
3. Founder C copies the Bluesky principle. C stores identity and posts in clean records, publishes an export, and documents the rules for moderation lists. Growth is slower, but members trust the exit door, and joining a protocol later stays possible.

None of the three is wrong. A chose a revenue line, B chose speed, C chose portability. The mistake is choosing without noticing what you traded away.

Governance: who can change the rules

Business model is half the comparison. The other half is who holds the power to change the product, and members feel that half when something goes wrong.

• X. Tiers, prices and creator program rules are set by the company and can change. Its help page is the place the rules appear, and it is the page to check before you plan around any detail. A member who relies on a perk is relying on the company's continued choice.
• Threads. The account system belongs to the parent company, so a change to that system affects the network. Meta's launch post says sign-in uses Instagram credentials, which means identity is a shared dependency across two products.
• Bluesky. The protocol documentation describes account portability: users can move their data and identity to another host, using keys they control, without the original provider's cooperation. It also describes independent feed and labeling services. The company states that it is a public benefit corporation structured so the network cannot be bought by one person or organization. That is a governance claim, and like any, it is tested over years, not in a launch post.

For an operator the practical point is simple. Whatever your members depend on, a login, a badge, a payout, a moderation rule, decide who can change it and how much notice they get. If the answer is "only us, with thirty days' warning", write that into your terms. If you can say it before a member asks, the question becomes a selling point instead of a complaint.

Questions to ask of any model you copy

1. If the company changed its mind tomorrow, what would members lose?
2. Can a member take their identity, posts and follows elsewhere, and how?
3. Which rules are public, and which are applied by staff without explanation?
4. Who pays for the expensive parts, and what happens when the money runs short?
5. What does a creator get that they could not get from a free account elsewhere?

A ready-made X clone app answers the first of these directly: you hold the source and the hosting, so nobody upstream can reprice your tiers or retire your badge. The other four are your policy to write, and the three networks above are good examples of how different the answers can be.

Lessons for a niche network

Own your graph

Your members and their follows are the asset. Keep them in records you control, under your own hosting and accounts, and make sure you can export them. Anything that makes the graph depend on a third party's login is a dependency you should price in.

Decide federation early

Federation changes your moderation duties, because content arrives from servers whose rules you did not write. It also changes your data model, because identity becomes portable. Make the decision on purpose, even if the answer is "not yet". Our guide on whether Threads works with Mastodon shows how large a network handles it, and apps like Threads compared lists alternatives.

Plan a revenue line early

Free forever with no plan is a deadline. Tips and creator subscriptions are the lightest start, and a membership tier can follow once members can say what they would pay for. The same pattern applies on other creator networks: a white-label OnlyFans clone starts from subscriptions, and a TikTok clone app starts from gifts and video.

Make your rules legible

All three networks publish rules and explain at least some of their moderation. Whatever you pick, write the rules in plain words, show how a decision was made and offer an appeal. This is cheap, and it is the clearest trust signal you can send.

Which model to borrow

Decision checklist

1. Write one sentence: who is this network for and why would they leave their current one?
2. Choose the first revenue line and what a paid member gets.
3. Decide where identity lives and whether members can export it.
4. Pick the first moderation layer and name the people who run it.
5. Decide whether you will federate, and write down when you will revisit it.
6. Plan the first hundred members by name, not by percentage.
7. Check app store payment rules before you promise paid features in a mobile app.
8. Review the model after ninety days against churn, reports and support load.

Short glossary

• Protocol. A published set of rules that lets different software exchange data.
• Federation. Several independently run servers exchanging data through a shared protocol.
• Labeler. A service that attaches labels to content so apps can filter it.
• Follow graph. The record of who follows whom.
• Portability. The ability to move an account and its data to another provider.

What to decide next

Pick the single priority from the table above and design around it. If it is membership revenue, read the X clone features to see tiers, badges and creator earning in one build, and compare the published price on the pricing page. For the short-form video side, the ReelShort clone follows a different model again. Whatever you choose, write down what you traded away so you can revisit it later.