Quota on Credit: Toward Time Fairness in AI Usage Limits

An examination of Claude’s and Gemini’s quota architectures, and a proposal

Aydın Tiryaki

Introduction

2026 marked a quiet but structural shift in how large language model platforms enforce usage limits. Both Anthropic’s Claude and Google’s Gemini abandoned fixed daily message counts in favor of a “compute-based” quota architecture: usage is no longer measured by message count, but by prompt complexity, the model selected, conversation length, and the features used. This is not a coincidence — both companies converged on nearly the same skeleton within almost the same month (May 2026): a short-term “five-hour window” layered under a “weekly cap.”

Yet beneath this shared skeleton lie two different philosophies. This article first lays out both architectures in as much detail as possible, then describes a concrete problem that emerges in practice, and finally details a proposed solution I call Quota on Credit (Veresiye Kota).

Part 1: The Current Quota Architecture — Claude and Gemini

1.1 The Five-Hour Window: Two Different Philosophies

On both platforms, short-term usage is bounded by a five-hour window. But the two platforms follow diametrically opposed logic on how that window begins.

On Claude, the window is entirely reactive. There is no fixed clock grid. The window opens at the minute you send your first message in a session and closes exactly five hours later. If you send your first message at 09:47, your window closes at 14:47. Once a window closes, no window is “open” until you send a new message — the system does not keep you on hold. For example, if a window closes at 14:47 and you send your first message at 15:15, the new window starts from 15:15, not 14:47; the intervening 28 minutes fall outside any window and are simply not counted. In short: the system doesn’t trigger you — you trigger the system.

On Gemini, the window sits on a semi-fixed grid. Each user is assigned a personal “phase” (e.g., minute :37), and windows advance continuously along this phase, back to back: 09:37 → 14:37 → 19:37 → 00:37 → 05:37 → 10:37… No matter when the user logs in, the system “catches” them on this fixed grid — even if you start working at 14:00, your usage is still counted against the old window until the next grid point (14:37); the new window opens only then. In other words, here you wait for the window, not the other way around.

Both philosophies serve the same engineering goal (spreading server load over time to avoid a “thundering herd” — a burst of simultaneous requests) but reach it by different means: Claude relies on natural, user-triggered distribution, while Gemini relies on a centrally assigned phase plus daily drift (explained below).

1.2 The Weekly Limit: A Fixed Phase

Unlike the five-hour window, the weekly cap works on a fixed logic on both platforms. Your account (or the moment it was activated) is assigned a day and time once, and this “phase” stays fixed regardless of user behavior — no matter when or how much you work, the weekly reset happens on the same day and minute every time. In the case we tested, this fixed moment falls around 09:37 every Tuesday morning on Gemini, and around 02:xx every Thursday night on Claude.

So on both platforms, two different time regimes operate simultaneously: the short window is behavior-sensitive (fully on Claude, partly on Gemini), while the weekly window is entirely behavior-independent, locked to a fixed grid.

1.3 24 Not Dividing Evenly by 5: The Math of Drift

An interesting mathematical consequence arises in Gemini’s semi-fixed grid system. A day has 24 hours, but windows advance in 5-hour blocks — and 24 does not divide evenly by 5. The result: the user’s “morning slot” shifts forward by exactly one hour every day. For example, a window that starts at 09:37 today will start at 10:37 tomorrow, and 11:37 the day after. The math works like this: the 5-hour blocks advance as 09:37 → 14:37 → 19:37 → 00:37 → 05:37 → 10:37…; reaching this last point takes exactly 5 blocks, i.e., 25 hours. 25 hours = 24 hours + 1 hour; that extra hour accumulates every day without ever closing the gap, pushing the slot forward. This drift completes a full cycle after 5 days (5 days × 1 hour = 5 hours = one full block) and returns to where it started — meaning the user’s daily slot pattern repeats on a 5-day cycle.

This structure, likely unintentional, has a beneficial side effect: even on a fixed grid, no single user stays locked into the same hour every day (e.g., always the busiest hour) — everyone rotates through good and bad hours over time. The starting phase itself assigned to each user is likely also determined by some form of “jitter” (a deliberately randomized offset) — another way of preventing millions of accounts from resetting simultaneously and causing a sudden server load spike (thundering herd).

Worth noting: these two separate gears (the five-hour windows and the weekly limit) advance completely independently of each other. Even at the moment of the weekly reset, the rotation of the five-hour windows is not interrupted — only the quota is reset at that instant; the window itself continues turning from wherever it was.

1.4 Model-Based Differentiation

Quota consumption is not a single-dimensional “time” matter; it operates across at least three dimensions: time slot × model choice × depth of reasoning.

On Claude, Opus consumes quota far faster than Sonnet — so much so that on Max plans, Anthropic has split the two models into independent weekly pools; when your Opus quota runs out, you can switch to Sonnet and keep working. On the Pro plan there is no such split — all models (except Fable) are pooled together under a single “All models” bucket.

Gemini has a similar distinction: Flash and Flash-Lite are designed for everyday tasks, fast and light on quota; Pro is designed for complex reasoning and consumes quota much faster. When your quota runs out, the system may automatically downgrade you to Flash-Lite.

The difference between “standard” and “Extended/Deep Think” reasoning modes is also real on both platforms: quota consumption rises noticeably when extended thinking is enabled.

The same action can also feel very different across subscription tiers. Under the structure announced at Google I/O 2026, Gemini’s “AI Ultra” plan is not actually a single tier but two tiers under the same name: roughly $100/month for 5x AI Pro’s quota, and roughly $200/month for 20x. This means a Gem Factory update, for instance, may consume only 8-10% of quota in the larger 20x pool, while the same operation could consume a much larger share — even nearly all of it — on a narrower tier. In other words, the answer to “what percentage of quota does an action cost” depends not only on the action itself, but on which tier the user is on.

1.5 The Fable Example: Quota Regimes for New Models

The fact that Claude Fable 5 (a premium-tier model introduced in June 2026, briefly suspended due to export controls, and restored in July) is tracked separately on the usage page as its own line (“Fable only”) is a current example of how new models introduce new quota categories tied to distinct commercial/access regimes. Fable is included up to a certain percentage of the weekly quota, after which usage continues on credit — following an entirely separate logic from other models (Sonnet, Haiku).

Part 2: Defining the Problem

2.1 The Time/Workload Mismatch

The practical consequence of the architecture described above is this: quota depletes according to the weight of the work, not according to time, yet the window itself is fixed according to time. This mismatch forces users to plan their work around the quota. A heavy task (long context, a resource-intensive model, an extensive update) can exhaust the quota within the first hour of a five-hour window; the remaining three to four hours are lost entirely as “dead time” — benefiting neither the user nor the system.

The reverse also creates a problem: with the bulk of the weekly quota still available (say, 70%), a user can still get locked out within the current five-hour window and be unable to find quota even for a small task. In other words, there is plenty of “budget” in the system overall, but it is divided so rigidly across time slots that the user ends up like someone with money in their pocket but no small change on hand at that particular moment.

2.2 The Loss of Unfinished Work

The most serious dimension of the problem is not merely unusable time, but the loss of unfinished work. When quota runs out mid-task, the task does not automatically resume where it left off; once the quota refreshes, it is sometimes necessary to restart from scratch or from a nearby point. In this case, the quota already spent up to that point ends up serving no purpose at all — both the user’s quota and the system’s computational resources are genuinely wasted.

2.3 Concrete Examples

This problem becomes especially pronounced in large, quota-intensive tasks:

Gem Factory update (Gemini): An ordinary Gem update consumes roughly 2-3% of quota, while updating the Factory itself (being an extensive Gem) consumes around 8-10%, and translating it into English costs another 8% or so. A single “stable release” cycle (update + translation) alone can consume 16-18% of a five-hour quota.
ATG Gem/GPT Project Lexicon (Claude): While working on this extensive project that catalogs over 60 Gems and GPTs in categorized sections, two large operations can exhaust an entire window; if other tasks are also being done at the same time, there is no chance of completing the work, and unfinished work is sometimes lost.
Unrequested action: In the same process, the system (Gemini, in this instance) autonomously undertaking a task that was not requested — translating into English before the Turkish update was confirmed stable, without instruction — consumed already-scarce quota without the user’s consent or plan, disrupting planned work. This is a separate issue worth addressing in its own right: a scarce resource being spent outside the user’s control.

Part 3: The Proposal — Quota on Credit

3.1 Core Principle

The proposal is named Quota on Credit (Veresiye Kota in Turkish) — borrowed from a traditional Turkish retail concept: “put it on the tab, you’ll pay for it anyway, only the timing differs.” This is entirely different from the “purchase extra quota/credit” mechanism currently offered by Anthropic or Google — because the user is not adding extra load to the system; they are simply drawing forward a portion of their own already-earned entitlement whose “turn” hasn’t come yet.

The core principle draws a firm distinction between two elements:

The total cap (weekly quota): Untouchable, never exceeded.
The temporal distribution (how the quota is divided across time slots): Currently determined entirely and rigidly by the system; the proposal allows the user to flex a portion of this in their own favor.

3.2 Rules and Safeguards

Target restriction: A transfer can only be made into the currently active slot; no direct transfer into a future slot that hasn’t started yet.
Source options:
- Near-term right: From any future slot within the next 24 hours.
- Weekly-horizon right: From any day the user selects within that same week (e.g., to set aside a share in advance for a known busy day).
- Week-to-week right: If this week’s quota is also exhausted, from the as-yet-untimed general total of a future week (e.g., one or two weeks ahead) — not deducted from a specific day/time, but from that week’s abstract total.
Amount cap: At most a defined proportion (e.g., ⅔) of any source slot/week may be transferred; no source can ever be fully emptied — ensuring the user still has at least a baseline quota guaranteed when they reach that slot in the future. For week-to-week transfers, given the longer horizon of unpredictability, it is reasonable for this cap to be more conservative (e.g., ⅓ or ¼).
Incremental, not a block: Transfers happen not as a single large package but in small amounts as needs arise; the sum of these incremental transfers still runs up against the cap in rule 3 — like a vessel that fills drop by drop but stops at a defined level.
Multiple sources, single target: For large tasks (extensive work that even an entire slot could not cover), the same active slot may receive incremental transfers from multiple source slots/days.
No chaining: A slot that has already lent quota cannot itself borrow from elsewhere — no chained borrowing.
Transparency: Before every transfer, the user is shown exactly what is being drawn from where, and how much will remain in the source afterward.
Self-limiting frequency: The mechanism does not additionally need an arbitrary “so many times per week” cap to preserve predictability — frequency already limits itself naturally through rules 3 and 6 (the cap on how much of any source can be drawn, and the no-chaining rule). Once a user reaches the ceiling of currently accessible sources, there is simply nothing left to draw; drawing again requires waiting for that source itself to refresh. This keeps the system balanced through its own internal logic, without penalizing a user with a genuinely heavy and recurring workload through an arbitrary number — which is far more consistent with the proposal’s actual purpose (closing a real mismatch by a real amount).

3.3 Three Trigger Channels

The mechanism can be activated through three different paths:

User request (reactive): The user requests it the moment they feel the need — “I want this much from that slot.”
System observation (proactive): When usage reaches a predefined threshold (e.g., 90%), the system evaluates the user’s historical usage pattern (which slots go consistently unused, e.g., the 3 a.m. slot) and proactively offers: “I can transfer some amount from that unused slot of yours — would you like that?”
System pre-calculation (preventive): Before starting an extensive task, the system compares its estimated quota cost against the user’s remaining quota in that slot; if the task cannot be completed, it warns before even starting and offers a transfer: “This task won’t finish with your current quota; shall we transfer some from there, or wait for the next slot?” This channel prevents the “loss of unfinished work” problem at its root.

In all three channels, the final amount is not a static entitlement but a real-time negotiation: the user requests up to the maximum cap, and the system determines how much it can actually grant based on its real infrastructure load at that moment — the request may not always be fully met.

3.4 Two Tiers: Intra-Day and Inter-Week

The proposal is a fractal repetition of the same principle at two different scales:

Tier 1 (micro): Transfers between five-hour slots, within the same week.
Tier 2 (macro): Weekly quota can be drawn forward from a future week’s quota at a more conservative ratio — for example, ahead of a busy work period before a planned vacation two weeks out.

The same three safeguards apply at both tiers: the total is never exceeded (only shifted in time), no chained transfers, and the operation is transparent.

Part 4: The Balance of Fairness

4.1 From the User’s Perspective

The proposal allows the user to make more efficient, user-centered use of an entitlement they’ve already purchased in bulk but which is rigidly distributed across time slots. This is not a request for an extra entitlement — it is a flexing of the timing of an entitlement that already exists.

4.2 From the System’s Perspective

For the system not to lose out either, the design observes these principles: total weekly consumption does not change (the system only rearranges when it is consumed, not how much); the no-chaining rule limits computational complexity; each source’s own cap (rule 3) keeps the system naturally balanced without needing an arbitrary frequency restriction. There is also a reasonable objection from the system’s side: the greatest advantage of the current fixed-window model is predictability and simplicity; flexible transfer adds an extra layer of forecasting to infrastructure capacity planning. This objection is legitimate — the proposal also accepts the company’s right to reject it outright; the real goal is to make two legitimate interests (the company’s preference for simplicity/predictability, and the user’s demand to use their earned quota efficiently) visible at the same table.

4.3 Economic Tension and Ethical Stance

At no stage does this system request additional resources from the AI company; only the temporal distribution of quota the user has already earned changes. This could clearly weaken a revenue stream embedded in the current “get locked out, wait, or buy extra credit/plan” model (the upsell that occurs at the moment of scarcity). Rather than ignoring this, it should be said plainly: attempting to profit from a user who has failed to complete their work and, as a result, is forced to buy extra quota, cannot be seen as a well-intentioned approach. Refusing to let a user flex a right they’ve already paid for, and then upselling them at the moment of scarcity, blurs the line between providing a service and turning scarcity into an opportunity.

There is a counterbalance on the other side too: a user base that gets frustrated less often, doesn’t get locked out, and doesn’t need to resort to informal workarounds to force the quota open (such as automated “warm-up” requests sent just to open a window early) can, in the long run, benefit the company through brand trust and customer loyalty. This balance between short-term revenue and long-term trust should be addressed openly in how the proposal is presented to the company.

Ultimately, this proposal is not company-centered but user-centered — while still respecting the system’s infrastructural realities and its own rights, seeking a balance that satisfies both sides.

Part 5: Broader Context

5.1 The Regulatory Framework — A Cautious Note

It can be said that a fairness mechanism of this kind is consistent with existing consumer-rights principles (such as the EU’s regulations on consumer rights and unfair commercial practices): “being unable to use a purchased service due to structural constraints” falls, in principle, within the scope of such frameworks. However, it must be stated clearly: no regulation currently in force mandates a specific mechanism of the kind described here. Product-level fairness rules of this sort typically emerge first through market competition (if one platform implements it, others are pressured to follow), and only later, once user complaints accumulate, attract regulatory attention — regulation tends to follow, not precede. This article points to a direction consistent with existing principles, rather than making a prediction.

5.2 Comparison with Other Sectors

The problem of “losing an unused entitlement” is not unique to AI. Mobile data quotas typically reset unused amounts at month’s end while overage is billed instantly; some carriers’ past “data rollover” offerings show that this kind of flexibility is commercially viable. Similar debates have occurred around unused annual credit card benefits and airline miles. AI quotas are simply the newest and least regulated member of this family.

5.3 Why AI Should Lead the Way

A telecommunications company’s system is static: it operates on fixed rules and cannot “negotiate” with a user in real time; flexibility requires a human customer service representative, a form, or a separate request process. AI, by contrast, is already a party that talks with the user in real time, understands what they’re trying to do, and can assess its own instantaneous load. For this reason, a dynamic negotiation of the kind “this task costs this much, you have this much quota, shall we transfer?” can occur for AI as a natural part of the conversation, without requiring any extra human intervention — because the platform itself is already the “intelligent party.”

This means the proposal is, for now, a system specifically idealized for AI. But as other sectors (telecommunications included) evolve toward smarter, negotiation-capable systems over time, the same principle is expected to become adaptable there as well. For today, it is AI models that need to take on this leadership.

Conclusion

The five-hour-slot-plus-weekly-cap architecture that Claude and Gemini converged on in 2026 is a reasonable starting point for ensuring fairness in usage, but the rigid coupling between workload and time slot creates real friction — in the form of both dead time and the loss of unfinished work. The Quota on Credit proposal suggests flexing not the total amount of quota a user has already earned, but only its distribution across time: a time-management model bounded by strict but non-arbitrary rules (a per-source amount cap, no-chaining, transparency), triggerable either by user request or by the system’s own observation/pre-calculation — fair to both the user and the system. This may create short-term revenue tension for AI companies, but it aligns fully, in the long run, with the principles of user trust and efficiency.

Colophon

This article is based on an extensive conversation between Aydın Tiryaki and Claude (Anthropic) that took place in July 2026. The method proceeded as follows: first, the technical workings of the existing quota systems (the logic behind how five-hour slots begin, the fixed nature of weekly limits, the drift arising from 24 not dividing evenly by 5, model-based differentiation) were clarified step by step through mutual question-and-answer and verification. In this stage, the observations Aydın Tiryaki contributed from his own use of Gemini and Claude (slot start times supported by screenshots, concrete quota-consumption examples from the Gem Factory and the ATG Gem/GPT Project Lexicon) served as the determining data source; Claude verified these observations against current sources (official support documentation from Anthropic and Google, along with independent technical reviews) and integrated the technical framework.

The core of the article — the Quota on Credit proposal itself, including its central idea, its rules (amount cap, target restriction, multiple sourcing, no-chaining, the two-tier structure), its trigger channels, and its economic/ethical rationale — belongs entirely to Aydın Tiryaki and was built step by step through his successive explanations over the course of the conversation. Claude’s contribution in this process is limited to technically classifying the proposed ideas, testing their internal consistency, expressing them with relevant terminology, and ultimately drafting this article into written form. For this reason, the article is published under Aydın Tiryaki’s byline.

Author: Aydın Tiryaki Contribution: Claude (Anthropic, Sonnet 5) — technical verification, framing, and drafting Date: July 2026 Publication: aydintiryaki.org

| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ Veresiye Kota: Yapay Zekada Zaman Adaletine Doğru │Quota on Credit: Toward Time Fairness in AI Usage Limits ░ 13.07.2026

Kategoriler

Bağlantılar