Monetization — pricing, revenue share, and payouts

This chapter is the money model, told straight: what you can set today, what the platform pays out, and what is still coming.

Coming soon

No actor can be bought today. Checkout is disabled platform-wide (ACTOR_PURCHASE_FLOW_DISABLED) — every actor, free or priced, is listed without a buy path. Pricing you set now is stored on your offer and ready for launch day. The best use of the wait: build audience. See ](en/feature-status/).

1. The money model at a glance

Capability	State today
Set pricing model + price on your offer	Live — registration wizard, step 2
Marketplace card shows your pricing	Live
Actor checkout	Not enabled — disabled platform-wide
Payouts	Coming soon — engine in dry-run behind launch gates
Bundles	Coming soon — no fulfillment path yet

2. Pricing models you set today

You set two things when registering your actor (step 2 of the wizard): a pricing model and a price. The three models are:

Model	Meaning
free	Your actor is free to deploy.
one_time	Customers pay once to get access to your actor.
subscription	Customers pay a recurring price for continued access.

The model and price you set appear on your marketplace card: free actors show as free; paid actors show their model and price next to the name and description. Pricing lives in your offer on the platform — it is not baked into your image — so a price change never requires a rebuild or a new image tag.

3. Revenue share

When your actor sells, you keep the majority share of the reference price; terms on /kreators. That page is the public offer surface for kreators: it carries the program terms and a payout calculator that models your monthly payout from a reference price, a customer count, and your tier share — useful for sanity-checking the price you have in mind.

The price you set on your offer is your reference price. Your payout is computed from it; the exact share depends on your kreator tier, published with the terms on /kreators. No percentages are quoted here because the share is tiered, not flat — the terms page is the source of truth.

4. Payouts

Coming soon

Payouts are not live. The settlement engine is code-complete and running in dry-run behind platform launch gates — no money moves yet. When payouts go live, they will run through Stripe Connect on a monthly cadence. There is nothing to set up today; connect your Stripe account when the program opens. See ](en/feature-status/).

5. Bundles

Coming soon

Bundles are not sellable yet — there is no fulfillment path for bundle purchases. See ](en/feature-status/).

When they land, bundles let you sell a suite of actors as one SKU: a grouping of actors with each member’s mesh role and dependency, so the actors cooperate in one domain. If your actor is designed to work alongside others (fleet mesh on), bundle-readiness will matter later — but today, sell the actor, not the suite.

6. Pricing guidance

Free vs paid. Today, pricing is positioning, not revenue — no one can buy yet. Free maximizes deployments while the platform ramps, and every deployed kompanion is proof of demand for launch day. Reach for a price when your actor does a complete, recurring job a customer would otherwise pay a person or a tool for.

Match the model to the value. one_time suits an actor that solves a discrete job once. subscription suits actors that deliver ongoing value — your actor runs as an always-on kompanion, and recurring runtime justifies a recurring price.

Anchor against the platform’s suites. Look at what the platform itself lists — the existing suites (Kajuris, Kampagne, Kaotel/Kacoif, Kinsur) bundle many actors per domain. A single-purpose actor should position below a full suite in scope and price; a suite-equivalent fleet from one kreator is the exception, and a bundle candidate when bundles land.

Plan to update. Because pricing lives in your offer rather than your image, you can start free, watch adoption, and move to a paid model at launch without touching your container. Revisit your price whenever your actor’s scope changes materially.

7. The quality bar

Every submission passes the same gates described in ](en/publishing/): a security scan and a use-case review. Pricing does not skip the queue — a paid actor faces the same review as a free one. What improves your approval odds:

• Boundary tests — prove your actor refuses out-of-scope requests, not just that it handles in-scope ones. Reviewers look for capability limits.
• A clean config — make kaoohi-config-check passes, the derived config.json is committed and fresh in the image, and the parameter list is lean (the wizard warns above 50 parameters).
• An honest description — the marketplace card comes from your config. If the description promises more than the actor does, use-case review catches it.

In short: price honestly, describe exactly, and test the boundaries. The rest — checkout, payouts, bundles — is on the platform’s roadmap, not yours.