How we price AI without credits theatre

A common way to price AI features is a credit system. A plan includes some number of credits per month, and different AI actions consume different, often unstated, numbers of them. This works well for a vendor. It lets them change the underlying cost of an action without changing the customer-facing number. The customer, meanwhile, does not know what a credit is worth in real usage until they have spent some and watched the balance move.

The vagueness is often not accidental. A credit is an abstraction layer between what a customer pays and what the vendor's AI usage costs. Only the vendor can see through it. That gives the vendor room to change the conversion rate without it looking like a price change. That specific pattern is what "credits theatre" describes: a unit vague enough that the customer cannot audit whether they are getting a fair deal. Credits as a concept are not the problem. The opacity is.

SalesCrew's AI features run through a single internal gateway, ai-complete. Every request through it is logged as an ai_run against a rate table, ai_rates, that defines what the request cost. The customer-facing allowance is stated in that same countable unit, model calls, not a converted or obscured one: roughly 5,000 model calls a month on Core, 25,000 on Outbound, 60,000 on Agency. A model call is a specific, auditable thing that happened. It is not a number that needs the vendor's conversion table to interpret.

This does not remove the real complexity of AI pricing. Different actions still use different model classes: a fast, cheaper model for some tasks, a slower, higher-quality one for others, each with a different real cost. What it removes is the need for the customer to trust an arbitrary credit conversion to know where they stand. The allowance is stated in the unit the system logs and enforces against.

The cap is stated plainly rather than left to be discovered. A soft alert at 80% of the allowance warns a customer before they run out. A hard stop at 100% applies to AI usage only. That last part matters. The cap is scoped to the AI gateway, so a customer who hits it can still use every manual path in the product: the UI, and every non-AI MCP tool action. A pricing model that let a usage cap take down the whole product would punish a customer for AI usage by removing capability that has nothing to do with AI.

A customer who wants to sidestep the shared allowance can use BYOK. They connect their own AI provider key, stored in Vault like any other credential, for a flat add-on fee. Usage through that key does not draw on the plan's allowance, because the customer pays the model provider directly. The design goal across both paths is the same. A customer should be able to look at a number and know exactly what it means. They should never have to trust a conversion rate they cannot verify.