How We Built an AI Credit System Across 11 Models

The Design Challenge

AI pricing is bewildering. One provider charges per million input tokens at one rate and output tokens at another. A different provider prices by "characters" with a separate fee for image understanding. A third offers tiered pricing based on context window size. Exposing this complexity to customers (asking them to understand token economics across multiple providers) is a non-starter for a product that should feel effortless to use.

We needed a single, unified metric that captures AI consumption regardless of which model processes the request, which provider serves it, or how that provider structures their billing. The metric needed to be predictable enough for budgeting, granular enough for attribution, and abstract enough that customers never need to think about the engineering underneath.

Credits became that abstraction. A credit is a normalized unit of AI consumption. It represents computational work performed on behalf of a user, regardless of which model or provider delivered that work. Customers see one number going down. They don't see eleven different pricing models, token multipliers, or provider rate cards.

The Proxy Pattern

The architecture that makes credit tracking possible is deceptively simple: every AI call in the platform passes through a single gateway. No service communicates directly with an AI provider. Instead, every request flows through our credit proxy, which handles attribution, metering, and routing in one atomic operation.

This pattern means that adding a new AI model to the platform doesn't require touching application code. The proxy already knows how to meter any request, attribute it to the originating user and organisation, and deduct the appropriate credit amount. Application services simply describe what they need. The proxy handles how and where it gets fulfilled.

The proxy doesn't just route. It provides complete observability. Every credit deduction is tied to a specific user, a specific feature invocation, and a specific model response. This granularity lets organisations understand not just how much AI they're consuming, but where that consumption delivers value.

Why We Don't Charge Per CV, Per Search, or Per User

Most recruitment platforms have adopted a pricing model that actively discourages use. They charge per CV processed, per search executed, per active job posted, or worse, by the number of employees in the company regardless of how many people actually use the platform. A 10,000-employee organisation might need only five recruiters using the tool, yet many vendors charge based on total headcount. This creates artificial barriers to adoption.

We took a different approach. GoVerse charges per seat, per recruiter who actually uses the platform. A large enterprise with five active recruiters pays for five seats. There are no charges based on company size, employee count, CV volume, search count, or number of active requisitions. Upload ten thousand CVs? Free. Run five hundred searches? Free. Maintain two hundred active roles simultaneously? Free. The platform doesn't penalise you for using it more.

We do maintain fair usage policies. API rate limiting prevents automated abuse, and we monitor storage consumption across accounts. When usage patterns suggest something beyond normal recruitment operations, we work with those customers to either adjust behaviour or move them to a dedicated enterprise deployment where resources are isolated. This is rare and handled collaboratively, not punitively.

Credits represent the AI value we deliver. When a model reads a CV and extracts structured data, that's value. When a reasoning model evaluates a candidate against your screening criteria and explains why they scored the way they did, that's value. You pay for the intelligence, not for arbitrary units like "your 101st job posting" or "your 501st CV received." The distinction matters because the value is proportional to what AI does for you, not to how much data you store.

Value-Based Pricing, Not Artificial Scarcity

Consider what happens when you upload 1,000 CVs. The storage is free. The indexing is free. The moment you ask AI to screen those candidates against your criteria, a fraction of a credit is consumed per candidate. For 1,000 candidates, you might use 20 credits total. That's the value exchange: we processed your entire pipeline intelligently, surfaced your best matches with transparent reasoning, and it cost you a small fraction of your monthly allocation. Compare that to a vendor who charges you per CV received. At scale, their pricing punishes success.

This is why we believe customers are happy to pay for AI credits. The value is visible and proportional. You can see exactly what the AI did, you can see the quality of output, and you can see that screening 1,000 candidates with AI costs less than one hour of a recruiter's time doing it manually. The credit isn't a penalty for usage. It's a fair exchange for genuine value delivered.

Teams aren't afraid to experiment with this model. A hiring manager can run exploratory searches, test different screening criteria, and iterate on their approach knowing that the cost is negligible relative to the value received. The question shifts from "can I afford to use AI on this?" to "why wouldn't I use AI on this?"

Aligned Incentives and Decreasing Costs

There's a long-term dimension to credit-based pricing that benefits customers directly. AI costs are falling. Model efficiency improves with every generation. Providers compete on price. What cost a dollar in compute eighteen months ago now costs a fraction of that, and this trend is accelerating.

Because credits map to actual computational cost, as those underlying costs decrease, the credit-to-work ratio improves. The same credit budget does more over time. Customers don't need to renegotiate contracts or switch plans to benefit from AI cost reduction. It happens automatically because our pricing is pegged to real consumption, not artificial per-unit charges.

This alignment matters. Our incentive is to make AI features as efficient as possible (better models, smarter routing, fewer wasted tokens) because that efficiency directly benefits our customers' credit budgets. We're not motivated to keep consumption artificially high. We're motivated to deliver maximum value per credit spent.

Building for Transparency

Credits only work as an abstraction if customers trust them. That trust requires transparency. Every credit deduction in GoVerse is auditable. Customers can see exactly which operations consumed their budget, which models were invoked, and how consumption maps to their team's activity patterns.

The dashboard shows real-time credit consumption broken down by feature, by team member, and by time period. Organisations can set alerts when consumption approaches thresholds, allocate credit budgets across teams, and understand their AI usage patterns without needing to interpret raw token counts or provider invoices.

This transparency turns credits from an opaque billing mechanism into a genuine planning tool. Finance teams can forecast AI spend. Operations teams can identify which workflows consume the most AI and optimise accordingly. And leadership can understand the ROI of AI adoption in concrete, measurable terms.

What We Tried First, and Why It Failed

The first version of the credit system deducted credits after the provider responded. The flow read: send the request, get the token counts back from the provider, compute the cost, subtract it from the balance. It was the obvious design and it had a hole. A user near a zero balance could fire several concurrent requests, all of which passed the balance check because none had been deducted yet, and all of which then executed. We were giving away work to accounts that had already run out. The race window was small, but at scale small windows get hit constantly.

The fix was to move to a reserve-then-settle model. Before a request reaches a provider, the proxy places a hold against the balance based on an estimated cost. If the balance can't cover the estimate, the request is rejected before any provider is called and no money is spent. After the provider responds with real token counts, the hold is settled to the actual amount and the difference is released. This is the same pattern a card authorisation uses, and we landed on it for the same reason: you cannot safely charge for work whose exact cost you only learn after doing it.

Estimation is the hard part of that model. We estimate from input size and task type, and we err on the side of holding slightly more than the request is likely to cost. That means an occasional request is rejected when the balance would actually have covered the settled amount. We decided a rare false rejection at the edge of a balance is a better failure than silently letting accounts overspend, so the estimate stays conservative.

Normalising Eleven Pricing Models

Turning provider bills into a single credit number is not a clean multiplication. Providers price along axes that don't line up: one charges separately for input and output tokens, another prices by character, a third adds a surcharge for large context windows or image understanding. A credit has to sit above all of that, which means the proxy carries a per-model cost function rather than a single rate. Each function maps that model's native billing units into normalised credits, and the router's model choice therefore also determines the cost function applied.

The trade-off we accepted here is that a credit does not correspond to a fixed number of tokens. It corresponds to a normalised unit of cost, and the token-to-credit ratio differs by model on purpose. A premium reasoning model consumes more credits per token than an efficient extraction model, because it costs us more per token. Exposing a flat "one credit equals N tokens" number would have been simpler to explain and would have been a lie the moment the router picked a different model. We chose the honest abstraction over the tidy one.

• Reserve: estimate cost from input size and task type, place a hold, reject up front if the balance can't cover it.
• Route and execute: the model router picks a provider; the model chosen selects the cost function.
• Settle: convert real provider token counts through that model's cost function and reconcile the hold to the actual amount.

Metering on the Hot Path

Every AI call passes through the proxy, which makes the proxy latency that every AI feature inherits. That is a design risk we watched closely, because a metering layer that adds noticeable delay to every request would tax the whole product. The reserve and settle operations are deliberately lightweight balance updates rather than heavy synchronous accounting, so the metering cost stays a small slice next to the provider call itself, which dominates end-to-end latency by a wide margin.

Detailed attribution (which user, which feature, which model, how many tokens) is recorded, but we keep the write off the critical path where we can, so building the audit record does not slow the response a recruiter is waiting on. The honest cost of routing everything through one gateway is that the gateway must never become a bottleneck or a single point of failure, so it is built to be horizontally scalable and to fail toward rejecting new spend rather than losing the record of spend already committed. Losing a deduction is a worse failure than briefly refusing a request, and the system is tuned around that ordering.