Designing an Honest “Unlimited” Generative AI Product: Credits, Queues, and Fair Use

Abraham Aragón — Sun, 16 Aug 2026 22:50:54 +0000

Disclosure: I am building Donatello.studio. This article describes the product and systems principles behind our access model; it is not an independent review.

Generative AI products have an uncomfortable cost structure. A text request may be inexpensive, while a long video or a complete song can consume orders of magnitude more compute. Yet users reasonably want a simple promise: they should be able to keep creating without discovering a surprise hard quota.

The word unlimited can describe that promise, but only if we define it precisely. It cannot mean infinite concurrent GPU jobs, zero latency, or immunity from abuse controls. A more defensible definition is:

A compliant account has no fixed daily, monthly, or lifetime creation quota, and retains a route to submit work even when normal-priority funding inventory is temporarily unavailable.

This post walks through a practical architecture for supporting that definition with credits, queues, fair-use controls, and explicit rights rules.

1. Separate access from priority

The first design mistake is treating access and execution priority as the same thing. They are different product states.

Access answers: may this account submit a valid job?
Priority answers: when should the job run relative to other jobs?
Concurrency answers: how many jobs may the account run at once?
Throughput answers: how quickly may new jobs enter the system?

A product can preserve access while lowering priority during heavy load. That is fundamentally different from returning a quota-exhausted error and forcing an upgrade.

A small state model might look like this:

NORMAL      -> funded credits, standard queue priority
CONTINUITY  -> no normal credits available, lower queue priority
THROTTLED   -> temporary rate or concurrency limit
BLOCKED     -> verified abuse, rights violation, or security action

Only the last state removes access, and it should require a documented reason. Capacity pressure by itself should move jobs between queues, not silently create a lifetime cap.

2. Make credits an accounting unit, not a paywall

Credits are useful because different media types have different expected costs. They provide a common accounting layer across image, video, music, and voice generation.

For a job, a basic estimate can combine model cost, duration, resolution and retry risk:

estimated_cost = base_model_cost
               * duration_factor
               * resolution_factor
               * retry_risk

The user-facing credit price does not need to expose raw provider cost, but the mapping should be stable enough to avoid surprises. Reserve credits before dispatch, then reconcile after completion if the provider reports actual usage.

if balance >= estimate:
    reserve(estimate)
    enqueue(job, priority=NORMAL)
else:
    enqueue(job, priority=CONTINUITY)

The critical design choice is the final branch. In a hard-quota product it becomes reject. In an access-preserving product it becomes a slower, tightly controlled queue.

Credits can still be earned through optional free activities, partner-funded actions or referrals. Those activities finance normal-priority work. They should improve speed and capacity without becoming the only possible doorway to the product.

3. Treat partner inventory as volatile

Survey and offer inventory varies by country, device, profile, time of day and partner demand. A user may have many activities today and none tomorrow. Designing as if inventory were constant creates geographical dead ends.

Monitor at least:

percentage of eligible sessions with zero activities;
median credits earnable per user by country and device;
completion-to-credit success rate;
reversal and fraud rate;
percentage of jobs entering continuity access;
queue wait time by priority class.

The goal is not to force every market into identical partner economics. The goal is to detect where the normal path is missing and ensure the fallback remains usable.

4. Build the continuity queue as a real product path

A lower-priority queue should not be a fake button that never completes. It needs an explicit service policy.

A scheduler can combine job age, expected cost and account trust:

score = age_minutes * AGE_WEIGHT
      - estimated_cost * COST_WEIGHT
      + trust_score * TRUST_WEIGHT

This prevents small jobs from waiting forever behind expensive jobs while still allowing older work to advance. Useful safeguards include:

one active continuity job per account;
deduplication of identical submissions;
cancellation before provider dispatch;
idempotency keys for retries;
provider-specific circuit breakers;
transparent status messages and estimated wait bands.

The interface should say what is happening. “Queued with lower priority” is honest. An unexplained spinner is not.

5. Fair use must be behavioral, not arbitrary

A fixed hidden number does not become fair use just because the Terms call it fair use. Controls should respond to behavior that threatens other users or the service.

Signals can include automated bursts that exceed human interaction patterns, repeated duplicate submissions, many accounts sharing one identity, attempts to bypass concurrency controls and confirmed rights violations.

Start with reversible actions: reduce concurrency, add cooldowns, require re-authentication or request verification. Reserve permanent blocks for strong evidence and provide an appeal path. Do not use high legitimate usage as an abuse signal by itself. The whole point of unlimited access is that a genuine power user is allowed to be a power user.

6. Commercial use is not the same as copyright-free

The systems design is incomplete without rights design. A platform can grant commercial permission for output produced by its current routes, but it cannot manufacture rights in an input the user did not own.

The product should distinguish:

Platform permission — whether the Terms permit commercial use of eligible output.
Input rights — whether the user may upload the image, recording, likeness or voice.
Legal protectability — whether the output qualifies for protection in a jurisdiction.
Third-party claims — whether the requested output infringes trademarks, publicity rights, privacy or other rights.

For voice and likeness features, explicit authorization controls are especially important. Clear attestation, logging, reporting and enforcement are better than burying responsibility in generic Terms.

7. Turn the promise into acceptance criteria

Marketing language becomes safer when engineering and support can test it. Example acceptance criteria:

No compliant account is blocked solely because it crossed a fixed daily, monthly or lifetime count.
When normal credits are unavailable, the user is offered a continuity submission path.
Every accepted job exposes a queue state, cancellation state and terminal outcome.
Capacity controls change priority, throughput or concurrency rather than inventing an undocumented permanent quota.
Commercial-use language links to current Terms and never claims that all output is automatically copyright-free.
Users are told that they need rights to inputs, likenesses and voices.

These criteria can be covered by product tests, support audits and monitoring dashboards. They turn a vague promise into an operating contract.

The trade-off

The honest trade-off is simple: a free, no-fixed-quota service cannot guarantee instant execution for every workload. It can guarantee that compliant users are not pushed into a surprise purchase solely because they created too much.

That is the standard we are applying at Donatello: no paid subscription or card required to start; no fixed daily, monthly or lifetime creation quota for compliant accounts; credits for normal priority earned through optional free activities; and continuity access governed by fair use, anti-abuse controls, queues and service capacity. Current production routes permit commercial use under the Terms, while users remain responsible for input and likeness rights.

The phrase free and unlimited should never be the end of the explanation. It should be the short label for a system whose rules are understandable, observable and designed to keep access open.

DEV Community: Abraham Aragón