Fanvue Clone Script: Billing an AI Persona by the Session

What is actually billable when a fan talks to an AI persona?

An AI persona looks like the cheapest revenue line on a creator platform. No creator to schedule, no camera to light, no content to produce. A fan opens a chat, a model answers, money moves. That picture is wrong in one specific way, and the way it is wrong decides whether the feature prints margin or quietly eats it: every reply you sell costs you a real, variable, third-party amount at the moment it is generated, and you find out how much afterwards.

A subscription is a fixed price against a near-zero marginal cost. A persona session is a variable price against a variable cost, with someone else setting one side of the equation. This post covers the plumbing under that: what the persona object holds, how a session is metered, where the money column is and is not, and which safeguards exist in documentation versus which ones you write. For the product, pricing and demo, start at the Fanvue clone page and come back here for the mechanics.

The foundation is a Laravel backend against MySQL or MariaDB, documented across eleven files. Where those files disagree, this post says so rather than picking the flattering reading. Where they are silent, it says that too.

What does the platform store for a persona, and how is a session metered?

Four tables carry the AI domain, and their columns say more than any feature list. The provider integration row holds a provider name as a plain string, an API key field, a model identifier, a JSON settings blob, an active flag and a requests-per-minute rate limit. The persona definition holds a name, a description, a system prompt that cannot be null, a temperature defaulting to 0.7, a max-tokens ceiling defaulting to 500, an active flag and an optional creator owner reference. The session row holds the fan, the persona, a JSON conversation context, a cumulative token counter starting at zero, and start and end timestamps. The message row holds the session reference, a role of user, assistant or system, the body text and a per-message token count.

Because the owner reference is nullable, a persona is operator-configurable and creator-ownable at once: a platform-wide persona has no owner, a creator’s does. The two knobs that most affect output quality and cost are first-class columns rather than buried configuration, and the 500-token default is a cost ceiling as much as a style choice, since output tokens are the expensive half of most provider price lists.

The documented session flow is short. Load the persona with its system prompt and temperature. Create a session row with an empty context and a zero token counter. Then per exchange: write a user message row, call the provider, write an assistant message row, update the counter. End the session, or resume it later.

Notice what is absent. No balance check before the provider call, no debit after it, no hold or reservation. And no price, rate, amount or charge column on any of the four tables. The AI domain measures consumption in the provider’s unit, tokens, not the fan’s. That is a defensible separation, but it is not a billing implementation.

Which AI provider runs the persona, and whose API key is it?

This is the question founders most often get wrong when they budget. The requirements document names five AI providers: OpenAI, OpenRouter, Ollama, HuggingFace and Replicate. The feature catalogue repeats the list and assigns roles, with OpenAI covering chat, moderation assistance and caption generation, OpenRouter acting as a gateway to multiple models, Ollama covering self-hosted models, and HuggingFace and Replicate covering inference and model hosting. The provider abstraction in the technical dossier is a small interface with chat, embeddings and image methods, behind an orchestrator that builds OpenAI, OpenRouter and Ollama providers from configuration keys.

One discrepancy to carry into technical review: the schema reference gives the provider column’s example values as openai, anthropic or cohere, a different set from the five named elsewhere. The column is a 50-character string rather than a constrained enum, so the schema does not limit the set. Treat the provider list as a question for the code, not a settled fact.

Each of those providers is a third-party account. The integration row has an API key column, the orchestrator reads provider keys from service configuration, and the admin role matrix puts API key management at Super Admin level only. The solution overview lists AI provider usage among the operator’s recurring provider costs, alongside payment fees and streaming, described as pay per token or per API call. The implementation phases treat AI provider configuration as operator setup, done only if personas are in the launch plan.

So state it plainly: no AI subscription ships with the code. You open an account with a model provider, paste your key into the admin panel, and the inference bill is yours. The platform routes requests, stores the exchange and counts tokens. It does not buy the intelligence for you. Ollama is the documented escape hatch for operators who want inference on their own hardware, but self-hosting trades a provider invoice for a GPU bill, not for nothing.

Per message, per minute or per session: which billing unit do the docs support?

Here the documents genuinely disagree, and a founder who misses it will price a product the build does not implement. The requirements document is most specific: its AI Studio capability table lists per-minute billing as included, attributing it to the session, message and integration configuration together, and its functional requirements say per-session billing based on duration and a per-minute rate. Its AI Studio journey adds that per-minute billing applies to the creator or the user balance depending on configuration, so the same mechanism can charge either side.

The solution overview says something different: free, subscription-included or charged per message, configurable at the persona level. The entity model says a third thing, describing the session row as tracking duration, charge and state. The schema reference for those same four tables shows no charge, price or rate column anywhere.

Both readings can be partly true, since pricing may live in the integration row’s JSON settings or in global admin settings, which a schema reference would not itemize. The honest conclusion is narrower than either document: confirm the billing unit against the code before you publish a price. Ask for one priced session demonstrated end to end during technical review. The choice is a real product decision, because each unit fails differently.

Billing unit	Documented status	Where the number has to live	What breaks first	Who absorbs a bad month
Per message	Named in the solution overview as one of three options	Persona-level configuration, charged on each assistant message	Fans ration messages and write long ones, so cost per charge rises while revenue per charge is fixed	Operator, through the output-token bill
Per minute of session time	Named in the requirements capability table as included	Derived from session start and end timestamps against a rate	Idle time. A fan who leaves the tab open is billed for silence or ends the clock ambiguously	Whichever side the idle rule favors, so write that rule first
Per session, flat	Implied by the duration-plus-rate functional requirement	A session-level price resolved at creation	Heavy users. One fan can consume many times the tokens another does for the same fee	Operator, with no natural cap
Subscription-included	Named in the solution overview; the fan access matrix shows persona access as a subscriber feature	Entitlement check against the subscription, plus a usage cap you define	Nothing, until an uncapped power user arrives. Then everything at once	Operator, which is why the cap is not optional
Free with a cap	Free access is named in the solution overview; the cap is not documented	A per-user quota you build, plus the integration row’s requests-per-minute limit	Acquisition economics, if the free tier converts poorly	Operator, as a deliberate marketing cost

What happens when a fan’s credit runs out mid-conversation?

Nothing in the eleven documents answers this, and the absence is worth stating rather than softening. There is no pre-authorization for a persona session: no reservation against the fan’s balance at session start, no minimum balance gate before the first provider call. There is no insufficient-funds branch, and no described behavior for the moment a balance reaches zero with a half-finished conversation on screen. The session row has start and end timestamps, and nothing says who writes the end timestamp when the money stops rather than the fan.

So the model is post-paid by default and silent about its failure mode, which is the combination most likely to produce either a support ticket or an unpaid provider call. Specify this branch yourself, early: whether a session requires a minimum balance before the first call, whether the balance is checked before each provider call or on a timer, what the fan sees when it empties, whether the final partial unit is charged or forgiven, and who closes the session row. None are hard to build. All are expensive to retrofit once real disputes exist.

Where does the credit come from, and what does the wallet guarantee?

The credit side is the mature part of this stack. A stored spending balance exists on the user record as a two-decimal currency column, and the documented API exposes a wallet summary, deposit history, available gateways, a fund-adding endpoint and a deposit invoice lookup. Funding is gateway-backed rather than internal, so fans top up through the same rails that handle subscriptions and content unlocks. We have written separately about how creator wallet systems behave under load.

The security documentation names the controls that matter for a balance: idempotency so repeated gateway callbacks cannot produce duplicate credits, entitlement checks and transaction status verification against wallet manipulation, and audit logging of credit and debit events. Read the mood of that language, though. Much of it is written as what should be verified, in a document whose purpose is to define a testing posture, and the requirements document separately calls monitoring dashboards not shipped and the audit posture moderate. The balance is real; the assurance that every debit path is idempotent and audited is a verification task you own. A persona session that calls a paid third party on every exchange is exactly the debit path to verify before launch.

Is anything reading what the persona says?

The documents make a claim their own pipeline descriptions do not support. The claim appears three times: the feature catalogue lists response filtering as included, described as chatbot responses moderated for policy compliance; the solution overview lists content filtering and safety settings via the SightEngine integration among persona operator controls; the whitepaper says persona conversations flow through the messaging system and are therefore recorded, moderated and billable through existing infrastructure. The schema reference points at the AI message table as the surface for chat moderation.

Now the pipeline. The only moderation flow documented end to end is upload-shaped: media is uploaded, queued, scanned by SightEngine for prohibited categories, the result stored against the media record, flagged items routed to manual review, admin thresholds deciding auto-rejection versus review. The API collection reinforces that shape, noting uploads and video should remain pending until checks pass. And where the catalogue itemizes text moderation, it names bio, captions and comments. Generated persona replies are not in that list.

So the accurate statement is this: the documentation asserts that persona responses are filtered, names the message table as where it would happen, and nowhere describes the mechanism that does it. SightEngine is also a separate third-party account the operator configures, like the model provider, so even the moderation you do have runs on your keys. Before a persona speaks to a paying fan, get a demonstration of a blocked generated response. If that cannot be produced, you are shipping unscreened model output, and screening is scope rather than a feature.

Does the platform tell the fan they are talking to a machine?

This is the section that matters most, and the honest answer is uncomfortable. Across all eleven documents there is no disclosure control, no AI labeling feature, no synthetic-media marker, no likeness-consent record and no persona-approval workflow. Searching the full set for likeness, synthetic media, deepfake or disclosure returns nothing on this subject. The consent machinery that does exist is data-protection consent: registration consent, cookie consent, data-processing consent, consent records stored and auditable. That is privacy consent, which is a different thing from a named person agreeing that a model may speak in their character, and different again from a fan being told that the reply they just paid for was generated.

There is also a specific detail you should see before you inherit it. The technical dossier includes a prompt builder with three system-prompt templates, for a chatbot, an assistant and a roleplay character. The default chatbot template, used when a persona has no more specific type, ends with the instruction: “Never reveal you are an AI.”

Take that literally. It is a default string in a documented template, the fallback for any persona created without choosing otherwise, and it instructs the model to conceal its own nature from the person paying to talk to it. It is trivially changeable, because the persona’s system prompt is a first-class editable column and the template is a starting value rather than a lock. But a default is what ships when nobody decides, which is why this is the first thing to change in a build and not the last.

What this means commercially is simple and we will not dress it up. The platform gives you the surface to disclose, because the system prompt, the persona name and the persona description are yours to write, and the fan-side preference table gives you somewhere to record what the fan was told. It does not give you the policy and it does not give you a compliance position. Whether a persona may be built on a real creator’s likeness, what that creator must sign, what the fan must be shown and when, and which rules apply in your markets and to your payment processors are decisions that sit entirely with you as the operator, and they belong with your own legal counsel rather than a feature table. Nothing here is legal advice, and no documentation substitutes for that advice.

The engineering recommendation that follows is narrow: write your disclosure into the persona’s system prompt and its visible name, record consent for any real likeness outside the platform as a document you can produce, and treat the shipped concealment default as a bug in your own configuration.

Who controls a persona: the operator, the creator or the fan?

All three, at different levels, and the role matrices are specific enough to plan against. The operator holds the provider relationship: API key management appears in the admin matrix at Super Admin level only, so credentials are not delegated to moderators or ordinary admins, and persona libraries are described as admin-managed, which fits the nullable owner reference.

The creator holds the character. Chatbot setup appears in the creator matrix for verified and top creators and is unavailable to pending or suspended ones, so persona creation is gated behind verification rather than open at signup. Account managers can manage the chatbot on a creator’s behalf, which matters if agencies are part of your model.

The fan holds less, but not nothing. A user AI preference table stores per-user enabled flags and persona preferences, described as controlling the AI behavior permitted for them. That is your opt-out surface and the right place to record what a fan was told. The fan access matrix also lists persona access as a subscriber-level feature marked conditional on availability, not something for free users, which bears on whether you sell personas as an upsell or a subscription benefit. Persona conversations run on the same messaging surface that carries paid direct messages with real creators, which is its own product with its own pricing questions.

What is missing from the documented API surface and the abuse controls?

Two gaps are worth knowing before you scope mobile work or a hardening pass. First, the API collection’s route-family map lists thirteen families covering authentication, identity, content, media, messaging, monetization, commerce, live and calls, verification, admin, notifications, analytics and webhooks. There is no AI family and no persona or session endpoint in it. Since that document is the contract surface used to validate mobile parity, persona chat should be treated as absent from the documented client API, whatever exists in the web application. If your launch includes personas on mobile, that is scope with a date attached.

Second, the abuse controls around a paid model call are thinner than they look. The integration row carries a requests-per-minute rate limit, which is a real primitive. Beyond that, rate limiting is documented as shipped on authentication and payment endpoints, while per-flow throttling is described as suggested posture in the API collection and as a recommendation in the security assurance document, which also lists incomplete rate limiting among its own medium-severity findings. Per-user AI quotas are phrased as something to consider implementing, with advice to monitor AI usage for volume spikes that may indicate a compromised key. Two-factor authentication is shipped, but mandatory two-factor for admins is a recommendation, and verifying that operator actions are audit logged is a checklist item rather than a guarantee. On a feature that spends your money with every request, a leaked key or an unthrottled loop bills you directly for as long as it runs.

Founder Decision Signals

• You can name your billing unit in one sentence. If you cannot, you are not ready to price it, because the three source documents each give a different answer.
• You have a provider account and a cost model before a price. Your floor is the output-token cost at your chosen model and max-tokens ceiling, not a competitor’s screen.
• You have written the empty-balance branch. Minimum balance at start, check frequency, what the fan sees, whether the last partial unit is charged, who closes the session.
• You have seen a blocked generated response. Not a blocked image upload. If nobody can show you one, screening is scope.
• Your disclosure is in the persona itself, in the system prompt and visible name rather than a terms page nobody opens, and the concealment default is gone.
• You have a signed likeness consent for every persona based on a real person. The platform stores none, so it lives in your own records before launch.
• You have a per-user quota, not just the provider rate limit. The integration-level limit protects the provider. A per-user cap protects your invoice.

Common AI Persona Billing Mistakes to Avoid

• Pricing a persona like a subscription. A subscription has near-zero marginal cost. Every persona reply has a real one, set by someone else, scaling with the fan’s enthusiasm rather than yours.
• Assuming the token counter is a money column. The entity model’s mention of a charge is not matched by a column in the schema reference. Verify which it is before you price.
• Treating the operator cost log as proof the fan is billed. The documented cost tracker converts tokens to currency for your own ledger. That is the expense side; revenue is a different wire.
• Offering unlimited persona chat inside a subscription tier. One uncapped power user can consume more inference than a hundred ordinary subscribers pay for.
• Leaving max tokens at the default without pricing it. The 500-token ceiling is a style decision and a cost decision. Raise it and your unit cost rises with it on every reply.
• Shipping the default system prompt, which instructs the model never to reveal that it is an AI. That is not a default to inherit by accident.
• Assuming an AI subscription is bundled. Five providers are supported, zero are included, and the inference invoice arrives in your name.
• Deferring the hardening pass. Per-flow rate limits, per-user quotas, mandatory admin two-factor and verified audit coverage are recommendations in the security documents, not shipped defaults.

How a Ready-Made Foundation Fits an AI Persona Build

The case for a documented foundation is not that it is cheaper to buy. It is that the expensive parts of this feature are the parts nobody demos. Nobody asks to see your empty-balance branch. Everybody notices an unpaid provider bill, or a fan who did not know who they were talking to.

At Miracuves we work from a documented creator-platform codebase where the persona definition, the session ledger, the message log, the provider integration row, the wallet and the role matrices are already specified and already in the admin panel. That is what a Fanvue clone script is in practice: not a visual copy of someone’s product, but a foundation whose unglamorous decisions are written down and open to inspection before you commit budget to them.

It also means we tell you where it stops, which on this feature is the more valuable half. No bundled AI subscription. A token counter rather than a price column. Three documents naming three billing units. No documented pre-authorization or empty-balance behavior. A moderation claim without a documented pipeline. No disclosure or likeness-consent control of any kind, and a shipped default that tells the model to conceal itself. None of those are reasons not to launch. They are the inputs to a launch plan that survives contact with real fans and real invoices.

A foundation pays off most when your differentiation sits upstream of the plumbing. If your bet is a specific audience, character catalogue or creator relationship, rebuilding a wallet and a session ledger is pure cost. Our wider work across the creator economy follows the same shape, and the hub page for this build carries the scope, pricing and demo.

Final Thoughts

An AI persona is the only revenue line on a creator platform where your cost of goods is set by a third party and charged by the request. That one property reshapes your pricing floor, your abuse exposure, your need for a per-user cap and your tolerance for an unspecified failure branch. The platform gives you a real persona object with real tuning knobs, a session ledger, a message log and a mature wallet to charge against. It gives you five provider options and no provider account.

It also hands you four honest absences: no price column on the session ledger, so the billing unit is yours to settle; no documented pre-authorization or empty-balance behavior, so that branch is yours to write; no documented pipeline behind the response-filtering claim, so screening is yours to verify or build; and no disclosure or likeness-consent control at all, with a default prompt that instructs concealment, so the policy and the honesty are entirely yours to own. Decide all four before you write a launch date, name the person who holds the provider key and watches its spend, and keep a signed likeness consent for every persona modeled on a real human being. On this feature those are not compliance overhead. They are the product.

FAQs

<!– wp:rank-math/faq-block {"questions":[{"id":"faq-question-17613401","title":"Does an AI subscription come included with the code?","content":"

No. The documentation names five supported providers, OpenAI, OpenRouter, Ollama, HuggingFace and Replicate, and treats the provider account as operator setup. The integration table has an API key column, the provider abstraction reads keys from service configuration, and API key management sits at Super Admin level only. The solution overview lists AI provider usage under the operator’s recurring provider costs, billed per token or per API call. You open the account, you hold the key, and the inference bill is yours.

“,”visible”:true},{“id”:”faq-question-17613402″,”title”:”Is a persona session billed per message, per minute or per session?”,”content”:”

The documents disagree, which is the useful answer. The requirements document lists per-minute billing as included, plus a functional requirement for per-session billing based on duration and a per-minute rate. The solution overview describes interactions as free, subscription-included or charged per message. The entity model says the session row tracks a charge, but the schema reference shows no price, rate or charge column on any of the four AI tables, only a token counter and timestamps. Ask for one priced session demonstrated end to end before you publish a price.

“,”visible”:true},{“id”:”faq-question-17613403″,”title”:”What happens if a fan runs out of credit mid-conversation?”,”content”:”

The documentation does not say, and that absence should shape your plan. There is no documented pre-authorization, no minimum balance gate at session start and no insufficient-funds branch. The documented session flow goes straight from loading the persona to calling the provider and logging the exchange, with no balance check before or debit after, so the model is post-paid and silent about its failure mode. Specify it yourself: the minimum balance to start, how often the balance is checked, what the fan sees when it empties, whether the final partial unit is charged, and who closes the session.

“,”visible”:true},{“id”:”faq-question-17613404″,”title”:”Are persona responses moderated before a fan sees them?”,”content”:”

The claim is made but the mechanism is not documented. The feature catalogue lists response filtering as included, the solution overview lists content filtering via the SightEngine integration among persona operator controls, and the whitepaper says persona conversations are recorded and moderated through existing infrastructure. However, the only moderation pipeline described end to end screens uploaded media, and where the catalogue itemizes text moderation it names bio, captions and comments rather than generated replies. Ask to see a generated reply the platform refused to deliver; if that cannot be shown, treat screening as scope.

“,”visible”:true},{“id”:”faq-question-17613405″,”title”:”Does the platform disclose to fans that they are talking to an AI?”,”content”:”

No. Across all eleven documents there is no disclosure control, no AI labeling feature, no synthetic-media marker, no likeness-consent record and no persona-approval workflow. The consent machinery that exists is data-protection consent at registration, cookies and data processing, which is a different thing. There is also a documented default system-prompt template whose chatbot variant ends with an instruction never to reveal that it is an AI. That default is editable, because the system prompt is a first-class column, and changing it is the first configuration task here. The policy itself sits with the operator and belongs with your own legal counsel.

“,”visible”:true},{“id”:”faq-question-17613406″,”title”:”Can a persona be built on a real creator’s likeness?”,”content”:”

The platform provides no consent record, approval workflow or likeness register, so the documentation neither permits nor prevents it and offers no compliance position. What it does give you is a persona object owned by a creator account, a verification gate limiting persona setup to verified and top creators, and a fan preference table where you can record what a fan was told. Everything else is operator policy: what a named person signs before a persona speaks in their character, and which rules apply in your markets. Take that decision with legal counsel, not from a feature table.

“,”visible”:true},{“id”:”faq-question-17613407″,”title”:”What stops a compromised key or a runaway loop from running up a huge provider bill?”,”content”:”

Less than you would want, by the documentation’s own account. The provider integration row carries a requests-per-minute rate limit, which is a real primitive. Beyond that, shipped rate limiting is documented for authentication and payment endpoints, per-flow throttling is described as suggested posture, and the security assurance document lists incomplete rate limiting among its own medium-severity findings. Per-user AI quotas are phrased as something to consider implementing. Build the per-user cap and the spend alert as part of launch.

“,”visible”:true},{“id”:”faq-question-17613408″,”title”:”Can fans use personas in the mobile app?”,”content”:”

Not according to the documented API. The API collection’s route-family map lists thirteen families covering authentication, identity, content, media, messaging, monetization, commerce, live and calls, verification, admin, notifications, analytics and webhooks. There is no AI or persona family and no session endpoint in it. Since that document is the contract surface used to validate mobile parity, persona chat should be treated as absent from the documented client API. If personas are part of a mobile launch, scope that work explicitly.

“,”visible”:true}]} –>