AI Top-Ups for Open-Core Products: Add Usage Without Repricing

AI top-ups open-core pricing works when your product has a useful free core, a commercial layer, and a few AI features whose usage varies heavily by customer. The mistake is treating every user as if they will consume the same amount of inference.

If one customer runs a few summaries a month and another runs thousands of document analyses, a flat plan can turn either unfair or unprofitable. Raising every plan price makes light users pay for power users. Offering unlimited AI pushes variable model costs back onto the product team. A top-up model gives each plan a clear allowance, then lets heavier users buy more AI usage when they need it.

For open-core teams, this is especially useful. The free core can remain valuable and accessible, while premium AI actions become a paid usage surface around the product. ShareAI Builder is designed for that layer: teams route selected AI requests from their own product through ShareAI, set a margin or surcharge, let customers pay for routed AI usage, and receive monthly payouts based on the usage they generate.

When AI Top-Ups Make Sense

AI top-ups are not a pricing trick for every product. They work best when the customer can understand why a feature has variable cost and when the feature creates value at the moment of use.

The strongest fit is a premium AI action with uneven usage: document extraction, RAG search, image generation, code review, support assistant responses, batch summarization, data enrichment, translation, or workflow recommendations. These actions have a real cost behind the scenes, but users can usually connect the charge to an outcome they asked for.

Top-ups are weaker when the AI feature is mostly decorative, when the cost per user is tiny, or when the user cannot predict what will consume credits. If the value is hard to explain, a top-up balance will feel like friction. If the value is clear, it can feel like control.

The Basic Open-Core Top-Up Model

The cleanest model has five parts:

1. The product includes a defined AI allowance in a paid plan, trial, or commercial edition.
2. The team marks selected AI requests as metered, while keeping the free core outside the paid AI layer.
3. When a customer reaches the included allowance, the product offers a top-up instead of blocking the whole workflow.
4. The application routes paid AI calls through ShareAI using the ShareAI API or Builder setup.
5. The customer pays ShareAI for routed AI usage, and the Builder earns a monthly payout from the margin attached to that usage.

This keeps the commercial AI surface separate from the open-source promise. You are not changing the license. You are not moving the product into ShareAI. You are adding a usage-aware monetization layer to specific AI-powered actions inside an app you already own.

That separation matters. Open-core buyers often accept paid enterprise features, hosted services, support, and premium automation. They are less forgiving when a team quietly moves core functionality behind usage charges. Start by metering AI features that are clearly incremental to the core product experience.

If you are still defining the larger pricing architecture, the broader free core, paid AI features model and the enterprise AI add-ons approach are useful companion paths. This article focuses specifically on the top-up layer.

Step 1: Pick Usage Units Customers Understand

Raw tokens are useful internally, but they are not always the best customer-facing unit. A good usage unit maps to the job the user is trying to finish.

AI feature	Customer-facing unit	Why it works
Document analysis	Pages, files, or analyses	Users think in documents, not tokens.
Support assistant	Resolved replies or assistant conversations	The unit connects to a customer interaction.
RAG search	Answers, searches, or indexed documents	The unit follows the retrieval workflow.
Image generation	Images or generation jobs	The output is visible and countable.
Code review	Runs, files reviewed, or pull requests	The unit matches the developer workflow.

You can still track provider cost, tokens, latency, and model usage behind the scenes. The customer-facing package should be simpler. A credit can represent a bundle of internal work, as long as the product explains it consistently.

This is also where AI pricing differs from ordinary SaaS seats. AI cost often scales with calls, model choice, tokens, or generated output. Bessemer’s AI pricing playbook and OpenView’s usage-based pricing work both point toward the same practical lesson: when cost and value vary by usage, the pricing model needs a usage-aware component.

Step 2: Decide What Is Included

The included allowance is the part customers will judge first. Too small, and the top-up prompt appears before users trust the feature. Too large, and heavy users can create margin pressure before you learn the economics.

A practical starting point is to include enough usage for the median customer to complete a real workflow, then reserve top-ups for customers who are clearly above normal usage. The goal is not to charge every user as soon as possible. The goal is to avoid subsidizing heavy AI consumption with one flat plan price.

For open-core teams, the free tier should still prove the product’s core value. Keep community usage useful. Meter premium AI features that add convenience, automation, speed, or scale. That could mean a limited number of AI-assisted runs in the free edition, larger allowances in paid tiers, and top-ups for customers who outgrow those allowances.

Step 3: Add Top-Up Triggers and Guardrails

A top-up flow should feel predictable before it feels commercial. The product should show the user what is included, what has been used, what happens next, and what a top-up buys.

• Show remaining AI credits or usage near the feature, not only on a billing page.
• Warn users before they run out, such as at 75 percent and 90 percent of the allowance.
• Use hard caps for teams that need spend control.
• Use soft warnings for teams that prioritize continuity and have an admin-approved payment method.
• Avoid charging for failed requests or invisible system retries.
• Keep admin controls separate from end-user feature controls.

The important design principle is simple: do not surprise the customer. If the user sees an AI action as valuable and understands the remaining balance, a top-up prompt is much easier to accept.

Step 4: Route Paid AI Usage Through ShareAI Builder

Once the product has a clear paid AI surface, ShareAI Builder can sit behind that usage. The product remains your product. ShareAI handles the routing and monetization layer for selected AI requests.

A clean implementation should tag each metered request with the customer, workspace, plan, feature, request type, and internal usage unit. That gives your team the visibility to compare customer allowances, top-up purchases, actual model usage, and margin.

Inside the ShareAI Builder console, teams can configure the Builder side of the setup and set the margin attached to routed usage. The app then sends selected AI requests through ShareAI, customers pay for that routed usage, and the Builder receives monthly payouts when usage generates revenue.

If you are still choosing model coverage, the ShareAI models page can help frame which AI actions belong in the paid layer. The best candidates are usually high-value actions where model quality, latency, and cost have a direct product impact.

Step 5: Explain the Model Clearly

Customer messaging should be boring in the best way: precise, short, and visible before a charge happens.

Use language like this:

Your plan includes 1,000 AI credits each month. Credits are used for premium AI actions such as document analysis and assistant-generated responses. If your team needs more, an admin can add credits without changing the whole plan.

That copy does three jobs. It tells the customer what is included. It connects usage to visible features. It makes top-ups an expansion path, not a penalty.

Avoid vague phrases like unlimited AI, fair use applies, or advanced usage may incur charges. Those phrases create support tickets. A good top-up model should reduce billing confusion, not move it into the inbox.

Common Mistakes to Avoid

The first mistake is metering the wrong thing. Do not charge for every internal model call if the user only sees one finished answer. Package around the visible outcome whenever possible.

The second mistake is making the free core feel worse. Open-core trust depends on a useful free foundation. Keep the core product credible, then monetize premium AI acceleration around it.

The third mistake is hiding limits until the moment of failure. If a team learns it needs top-ups only after a workflow breaks, the pricing model will feel hostile. Show usage earlier.

The fourth mistake is skipping margin review. A top-up package should be checked against real AI provider costs, model selection, retry behavior, and heavy-user patterns. A generous allowance is fine when it is deliberate. It is dangerous when it is invisible.

A Practical Launch Path

Start with one premium AI action. Choose a feature that users already request, that has measurable usage, and that creates enough value to justify a paid expansion path. Do not try to meter every AI surface at once.

1. Pick the first premium AI feature.
2. Choose a customer-facing unit, such as analysis, answer, file, or run.
3. Set an included allowance for the paid plan or trial.
4. Add usage visibility and admin-controlled top-ups.
5. Route the paid AI requests through ShareAI.
6. Review usage, model costs, conversion, and margin after the first billing cycle.

This keeps the launch small enough to ship and specific enough to learn from. After one feature works, the same model can expand to other premium AI actions in the product.

FAQ

What are AI top-ups in an open-core product?

AI top-ups are paid usage additions for premium AI features. An open-core product can include a monthly allowance, then let customers buy more credits, analyses, answers, or runs when their usage exceeds that allowance.

How are AI top-ups different from a higher paid plan?

A higher plan changes the customer’s whole subscription. A top-up adds more AI usage without forcing a plan change. That is useful when the customer likes the current plan but has occasional spikes in AI consumption.

When are AI top-ups better than unlimited AI?

Top-ups are better when usage varies widely and AI costs are meaningful. Unlimited AI can be attractive in marketing, but it can also hide heavy-user costs until margins become painful.

Does ShareAI replace our product billing?

No. ShareAI can handle the routed AI usage and monetization layer. Your product can keep its existing subscription, license, enterprise contract, or open-core commercial model.

Does ShareAI host or build the open-core product?

No. The application remains built, hosted, and managed outside ShareAI. ShareAI Builder is for routing and monetizing selected AI usage from the product, not for creating or hosting the product itself.

What should count as a credit?

A credit should map to a visible customer action. For example, one document analysis, one generated image, one assistant answer, or one code review run. Internally, you can still map credits to tokens, model cost, and routing behavior.

How should open-core teams handle free users?

Keep the free core useful. If free users get AI access, use a small allowance or demo-friendly limit. The paid top-up model should apply to premium AI usage, not to the basic value that makes the open-core project credible.

Can AI top-ups work for self-hosted customers?

Yes, when the self-hosted product can route selected AI requests through a commercial endpoint and the customer accepts that architecture. The product should make the routed feature, usage terms, and admin controls clear.

How do Builder payouts work?

In a ShareAI Builder setup, the Builder routes selected AI usage through ShareAI and sets a margin or surcharge. Customers pay ShareAI for that routed usage, and the Builder receives monthly payouts based on generated usage.

How is a Builder different from a Provider?

A Builder owns the app, product, plugin, or platform that sends users to ShareAI-routed inference. A Provider contributes compute capacity to the network. Open-core top-up pricing is mainly a Builder workflow, even though Provider supply helps power the broader marketplace.

What internal data should we track?

Track customer ID, workspace ID, feature name, plan, request count, usage unit, model used, cost proxy, top-up balance, failed requests, and generated revenue. Without this data, it is hard to tune allowances or margin.

What is the safest first feature to launch with top-ups?

Choose a premium AI feature that already has demand, obvious customer value, and measurable usage. Document analysis, assistant answers, batch enrichment, and generation jobs are often easier to explain than background automation.

Start With One Premium AI Action

The best open-core top-up model is usually small at first. Pick one AI feature, define the allowance, show usage clearly, and route the paid requests through ShareAI. Once the economics are visible, you can expand the model without repricing the whole product.

Teams that are ready to test a Builder setup can start in the ShareAI Builder console or review the ShareAI documentation before wiring the first routed AI feature.