Session Limits vs Revenue: The Data Nobody Publishes

Every platform selling engagement faces the same conflict, and almost nobody writes it down: the design that is best for the user is worse for revenue. AI companion session limits are the clearest case. A cap that interrupts a long session protects the user and costs the platform — and the creator — money.

This piece works through that trade-off with the enforcement data we actually have, explains the design we shipped, and is explicit about which parts are measured, which are modelled, and which are simply our judgement. It is not a wellbeing announcement. We benefit commercially from the choice we made, and that is stated rather than buried.

Key takeaways

• We have no usage data. The marketplace has no onboarded creators. Nothing here is dressed up as measurement.
• Session caps run server-side on the enforcement path, not as a front-end banner.
• Default is a soft nudge, on by default, creator-adjustable up to a hard block.
• The soft default preserves revenue. We benefit. That is a real conflict, not a resolved one.
• Stated in advance: if the nudge proves decorative under real traffic, the default changes.

Contents

• The conflict, stated plainly
• What we can and cannot measure
• The mechanism we built
• Modelling the revenue cost
• Why creator-controlled rather than platform-set
• The objection we find hardest
• What we have committed to test

The conflict, stated plainly

A marketplace selling generation credits earns more when more generations happen. A per-creator subscription earns more when it is renewed, and renewal correlates with use. Both revenue shapes reward engagement.

Nothing in either model rewards a user stopping. There is no line in the business plan labelled "sessions we successfully interrupted".

This is the same structure that drives criticism of social platforms, and the standard industry response — a wellbeing paragraph in the terms and a settings toggle nobody finds — is a way of appearing to address it without changing any incentive. We wanted a mechanism instead. We also want to be clear that having a mechanism is not the same as having resolved the conflict.

It is worth noting what regulation does and does not reach here. The Online Safety Act 2023 obliges services to assess and mitigate risks of harm, and Ofcom has powers behind that — but neither prescribes a session limit. Design choices in this area are still almost entirely voluntary, which is precisely why publishing the reasoning matters.

What we can and cannot measure

Here is where most posts of this kind quietly cheat, so:

We have no usage data. The LikeWard marketplace has no onboarded creators. Zero rows in creators, generations and subscriptions. Every end-to-end test fixture we created during verification was deleted afterwards, deliberately, so the directory is honestly empty rather than padded.

That means we cannot tell you what session lengths look like, what a nudge does to them, or what any of this costs in practice. Anyone publishing those numbers for a platform at this stage is inventing them.

What we can describe is the mechanism, the incentive structure, and a model with its assumptions on the table.

Table: separating what is verified in our own system from what is modelled and what is simply unknown. The three "unknown" rows are the interesting ones, and we would rather label them than fill them.

The mechanism we built

Boundary sets carry a relationship framing category alongside the content rules. Creators can set:

• A session cap — after N consecutive generations of that creator, a nudge fires.
• A variety suggestion — a prompt toward other creators after sustained single-creator use.
• Strength — soft nudge through to hard throttle.

The important property is where it runs. This is evaluated server-side alongside contexts, forbidden depictions and the realism ceiling — on the same path, before generation. A client that chooses not to render the nudge does not thereby escape it, which is the difference between this and a screen-time banner.

It ships on, at soft-nudge strength, at 12 consecutive generations. The full field reference is in the boundary configuration guide.

Modelling the revenue cost

With no traffic, a model is all anyone can offer. Assumptions on the table:

• Generation demand within a session decays; the marginal request is worth less to the user than the first.
• A soft nudge diverts some proportion of continuing sessions; a hard block ends them.
• Diverted users partly return later; blocked sessions partly do not.

Under those assumptions the ordering is unsurprising: no limit > soft nudge > hard block on revenue, with the gap between nudge and block wider than between no-limit and nudge. A nudge costs comparatively little because most sessions end before the cap anyway; a block truncates the tail, and the tail is where heavy-use revenue concentrates.

That ordering is exactly why the soft default is commercially comfortable for us — and it is why stating it plainly matters more than the model does. The design we chose sits at the cheap end of the intervention range.

Why creator-controlled rather than platform-set

The strongest argument for the design, and it is genuinely an argument about who decides rather than about wellbeing.

A platform-set hard block imposes our judgement on a creator's income without asking them or the user. A platform-set no-limit imposes the opposite. Either way we are deciding something that principally affects two other parties.

Making it a creator-set lever puts the dial with the person whose likeness is being generated and whose earnings are affected. It is the same principle as the rest of the product: the creator writes the rules, the platform enforces them, and we do not substitute our preferences for theirs.

"We built a consent engine and then found ourselves about to hard-code a preference about how people should use it. The consistent move was to make it another field in the boundary set." — LikeWard engineering desk

The objection we find hardest

Not the ones we can answer. This one:

A creator-controlled dial with a soft default means almost nobody changes it, so the default is the policy — and we picked the commercially convenient default.

That is a fair hit. Defaults are policy. Most creators will not adjust this, so shipping at soft-nudge means soft-nudge is the effective platform position, and it happens to be the one that costs us least.

Our answer is partial rather than complete. A hard default would suppress a product that has no users yet and would be a platform overriding creators on their own terms — the pattern the whole product exists to avoid. We think creator-controlled is right. We do not think it is costless, obviously correct, or free of self-interest, and a post claiming otherwise would not be worth reading.

What we have committed to test

Stated in advance so it is checkable later:

1. Whether the nudge interrupts anything. If sessions continue at the same rate through a nudge, it is decorative and the default should change.
2. Whether creators adjust it. If nobody moves the dial, "creator-controlled" is a description of a settings screen rather than of who decides.
3. What the actual revenue delta is. The model above is assumptions. Real traffic replaces it.

We will publish those numbers when there are any, including if they are unflattering. In the meantime, the honest summary is: we built a real mechanism, put it on the enforcement path, defaulted it to the cheap end, and are telling you that is what we did.

---

Related: the companion app comparison for how this sits against the wider category, the boundary configuration guide for the settings themselves, and the creator-owned companion use case.