Price your AI software separately from model usage

A proposal editor can be useful before it sends anything to a model. Customers may pay for reusable sections, approval history, client workspaces, and reliable exports. Those features have a different cost structure from generating another draft.

If you combine everything into one undifferentiated credit price, customers cannot tell whether they are buying software access or inference. You also lose a clear view of which part of the business covers support and hosting.

AI Pass lets an app offer wallet-funded model usage through OAuth. Provider-key BYOK is another route, where a customer supplies a provider credential. Neither requires you to stop charging for useful software. The integration guide calls for preserving existing subscriptions and billing when adding the optional connection.

Build a service tier around work people keep

Consider a hypothetical proposal app with two monthly service plans. Every number below is an invented planning assumption, not an AI Pass rate, an observed result, or a revenue forecast.

Solo includes reusable proposal blocks, version history, and exports. Studio adds shared libraries, reviewer permissions, and team administration. Model usage is funded separately through the customer's chosen supported route.

The illustrative variable service cost includes hosting, storage, expected support, and payment processing allocated per account. It excludes inference because this scenario places inference on the selected user-funded route. Real payment fees, taxes, support costs, and accounting treatment need their own estimates.

Hypothetical plan	Monthly service price	Variable service cost	Contribution before fixed costs	Contribution margin
Solo	$12.00	$3.20	$8.80	73.33%
Studio	$29.00	$9.50	$19.50	67.24%

Contribution is price minus variable service cost. Contribution margin divides that amount by the service price. These figures were checked with decimal arithmetic; they are not net profit margins.

Studio earns more dollars per account here but has a lower percentage margin. That could be acceptable if collaboration is the product customers need. The calculation also tells you to watch support time: a team plan can require considerably more help than a single-user editor.

Look at a whole month, not one account

Assume the hypothetical app has 80 Solo accounts and 20 Studio accounts:

• Service revenue: 80 × $12 + 20 × $29 = $1,540.
• Variable service costs: 80 × $3.20 + 20 × $9.50 = $446.
• Contribution before fixed costs: $1,540 − $446 = $1,094.
• With an assumed $700 in fixed monthly costs, the remainder is $394.

That remainder excludes anything you left out of the model, such as founder compensation or taxes. Calling it profit without checking those omissions would be misleading.

With only Solo accounts and the same assumptions, $700 ÷ $8.80 is approximately 79.55. You would need 80 whole paying accounts to cover the assumed fixed costs. This is a planning threshold, not evidence that those customers will appear.

Compare the cost of bundling inference

Now suppose Solo still costs $12 but also promises bundled model usage. Keep the $3.20 variable software cost. A hypothetical customer consuming $2 of inference leaves $6.80 before fixed costs. One consuming $18 leaves negative $9.20.

The point is not that bundled usage is always bad. A bundle can be easier to buy and can work with well-designed limits. But the product must account for usage variation instead of hiding it inside a hopeful average.

Separate funding makes the service-tier calculation easier to interpret. It does not remove your costs for orchestration, file processing, retries your app funds, or customer support. List those explicitly rather than assuming "user-funded" means "costless."

Make the pricing page match the ledger

Use a service-plan description such as: "Solo covers the proposal editor, saved templates, version history, and exports. AI generation is billed separately through your selected funding method."

Beside Generate, show the current funding source and available pricing information. If you add a developer markup, disclose it clearly in the appropriate cost presentation. Any developer earnings from eligible paid usage remain governed by current terms; do not count an assumed payout as guaranteed service revenue.

Use the SDK documentation for the browser integration or the REST reference for a backend route. Keep your existing app hosting and login either way.

Before publishing a tier, ask whether a customer who generates nothing can still describe what they bought. If the answer is saved work, collaboration, and a dependable workflow, you have a software price that can stand apart from model consumption.