Fair Pricing for AI: Why Credits Beat Subscriptions

Flat-rate subscriptions work when usage is predictable. AI-powered features have wildly variable usage — one user might process 5 calls per day, another might process 50. A subscription priced for the light user subsidizes the heavy user. A subscription priced for the heavy user overcharges the light user and suppresses adoption.

Credits solve this by aligning cost with consumption. Each AI operation has a credit cost based on its actual compute expense — lightweight operations cost less, full-context operations cost more. Users purchase credit packages and spend them as they use AI features. The economics are transparent.

The engineering challenge is making credits feel invisible during normal usage. Balance checks, deductions, and low-balance warnings need to happen in the background without adding latency or friction to the user experience. Credits should be a pricing mechanism, not a user experience obstacle. (The cost architecture credits meter: Planner-Validator tiering.)

The naive approach to credit deduction — check balance, perform operation, deduct — has a race condition. Two simultaneous operations both see sufficient balance, both proceed, and the user ends up with a negative balance. Multiply this across a day of active usage and the accounting falls apart.

We use an optimistic deduction pattern: credits are reserved atomically before the AI operation starts, using a database operation that checks and deducts in a single transaction. If the balance is insufficient, the operation is blocked before any AI tokens are consumed. No race condition, no overdraft, no wasted compute.

The system also works offline. The credit balance is cached locally with a short time-to-live. When the device is offline, operations proceed against the cached balance with local decrements. When connectivity returns, the actual deductions sync to the server. The brief staleness window is a deliberate tradeoff — a small potential overdraft in exchange for uninterrupted offline functionality.

When credits run out, AI features are disabled — but everything else continues working normally. The app doesn’t lock the user out. It doesn’t nag with interstitial modals. It surfaces a non-intrusive indicator and disables the specific features that consume credits. The rest of the application — data browsing, CRM sync, settings — remains fully functional.

The security model separates spending from adding. Users can spend credits through normal operations, but adding credits requires elevated credentials that exist only on the server. Even if a user’s authentication token is compromised, the attacker can only spend credits — never create them. That server-only rule is the same one that keeps secrets off devices entirely.

Every credit operation — deduction, addition, balance check — is logged in a complete audit trail. Operation types are validated against a server-side whitelist, preventing a compromised client from inventing cheap operation types to game the system. The credit system is ultimately a trust boundary: the server is the authority on balances, the client is a cache that syncs.

The test of a credit system is whether users think about it. If credits are invisible during normal usage and transparent when they run low, you’ve succeeded. If users are checking their balance before every action, you’ve built a tollbooth.