# Designing an Honest “Unlimited” Generative AI Product: Credits, Queues, and Fair Use > Source: > Published: 2026-08-16 22:50:54+00:00 *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. The first design mistake is treating access and execution priority as the same thing. They are different product states. 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: ``` php 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. 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. 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: 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. 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: The interface should say what is happening. “Queued with lower priority” is honest. An unexplained spinner is not. 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. 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: 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. Marketing language becomes safer when engineering and support can test it. Example acceptance criteria: These criteria can be covered by product tests, support audits and monitoring dashboards. They turn a vague promise into an operating contract. 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.