Most AI products eventually run into the same problem:

Tracking usage sounds simple.

Until it isn't.

At first, all you need is a counter.

A request comes in.

You decrement a credit.

You process the request.

Done.

Or at least that's what most teams think.

As usage grows, things start breaking:

• duplicate requests
• retries
• race conditions
• timeout failures
• inconsistent balances
• billing mismatches

And suddenly a simple counter becomes a revenue problem.

The Naive Implementation

Most products start with something similar to this:

if (credits > 0) {
  credits--;
  executeRequest();
}

Looks harmless.

The user has credits.

A request arrives.

A credit is consumed.

The request is executed.

Simple.

The problem is that real-world systems are rarely this simple.

What Starts Breaking

The moment real users start using your product at scale, unexpected situations appear.

Retries

Networks fail.

Browsers retry requests.

Mobile apps resend actions.

Background jobs run again.

A single user action can generate multiple identical requests.

Without protection, credits may be consumed multiple times.

Race Conditions

Imagine a user has one credit remaining.

Two requests arrive at exactly the same time.

Both processes check the balance.

Both see one available credit.

Both proceed.

Now the user consumed two requests while paying for one.

Or worse:

Your balance becomes negative.

Partial Failures

One of the most dangerous situations looks like this:

Consume credit
↓
Call AI provider
↓
Timeout

Did the AI provider process the request?

Maybe.

Did the user receive the result?

Maybe not.

Should you refund the credit?

Should you charge again?

These situations become surprisingly difficult to handle consistently.

How Revenue Leaks Happen

Most revenue leaks don't come from pricing mistakes.

They come from tracking mistakes.

A few common examples:

Free Usage

The request succeeds.

The credit is never consumed.

The user receives value for free.

Double Charging

A retry consumes credits twice.

The user gets charged more than expected.

Now support tickets start arriving.

Billing Mismatch

Your billing dashboard shows one number.

Your usage records show another.

Your invoices show a third.

Nobody knows which number is correct.

Missing Audit Trail

A customer asks:

Why was I charged?

You have no record explaining exactly what happened.

Now you're forced to guess.

A Safer Architecture

Reliable usage tracking requires more than a simple counter.

The goal is to create a system that is:

• auditable
• idempotent
• atomic
• reliable under concurrency

Use a Usage Ledger

Instead of simply decrementing balances, record every consumption event.

Example:

ID          USER      UNITS
--------------------------------
1           user_1    -10
2           user_1    -20
3           user_1    -15

This creates a complete history.

You always know:

• what happened
• when it happened
• how many units were consumed

A balance becomes the result of ledger events rather than a standalone number.

Make Consumption Idempotent

Every usage operation should have a unique identifier.

Example:

request_id = 9f7d3c2a

If the same request arrives again:

• do not consume credits again
• return the original result

This prevents duplicate charges caused by retries.

Consume Credits Atomically

Checking balances and consuming usage should happen inside a single transaction.

Bad:

Read balance
↓
Check balance
↓
Update balance

Good:

Transaction
↓
Verify balance
↓
Consume units
↓
Commit

This prevents concurrency issues and race conditions.

Design for Auditability

Sooner or later a customer will ask:

Why was I charged for this?

You should be able to answer immediately.

Store:

• request id
• timestamp
• user id
• consumed units
• operation type

A complete audit trail saves countless support hours.

Why Counting Requests Isn't Enough

Many teams assume:

1 request = 1 unit

But AI products rarely work this way.

Different operations have different costs.

For example:

Text generation     = 1 credit
Image generation    = 20 credits
Video generation    = 100 credits

What matters isn't request count.

What matters is billable usage.

That's the metric that should drive monetization.

Final Thoughts

Tracking AI usage seems easy when your product has ten users.

It becomes infrastructure when your product has thousands.

The challenge isn't counting requests.

The challenge is building a system that remains correct when:

• requests are duplicated
• jobs retry
• users scale
• revenue depends on every consumption event

Because once usage becomes your pricing model, tracking usage becomes part of your business model.

And every mistake eventually turns into lost revenue.

Learn More

If you're building AI credits, usage-based billing, or prepaid consumption systems, one of the most important concepts is maintaining an auditable usage history through a usage ledger.

I wrote more about the architecture behind credits, consumption tracking, entitlements and billing synchronization in the Licenzy documentation:

https://licenzy.app/docs/usage-metering

It includes examples for:

• consumption tracking
• idempotency
• usage packs
• credit-based monetization