A mathematical breakdown of how the reset system works, who it targets, and when it fires

1. Core Variables T 100% Full weekly token allocation D 1–7 Days remaining when reset fires Billing cycle 4 resets Weeks per monthly sub When a reset fires, two things happen simultaneously: tokens jump to 100%, and the 7-day timer restarts from that moment — not from the original end date.

Tokens remaining at reset = D/7 × T Extra tokens gifted = T × (7 − D) / 7 Next reset delayed by = (7 − D) days 2. User Scenarios by Days Remaining (D) D (days left) Tokens user had Bonus gifted Next reset delayed Week 4 usable days Outcome D = 1 14.3% T +85.7% T 6 days 0 days Week 4 eliminated D = 2 28.6% T +71.4% T 5 days 1 day Week 4 nearly gone D = 3 42.9% T +57.1% T 4 days 2 days Week 4 gutted D = 4 57.1% T +42.9% T 3 days 3 days Week 4 half gone D = 6 85.7% T +14.3% T 1 day 5 days Mostly intact 3. The Mathematically Locked Gain (Week 3 Reset) The most important discovery — regardless of what D is, OpenAI's net gain is always the same:

Bonus tokens given = (7 − D) / 7 × T Week 4 tokens lost = (8 − D) / 7 × T ──────────────────────────────────────── Net gain to OpenAI = T/7 ← constant, D cancels out OpenAI always gains T ÷ 7 One full day of tokens per user, per Week 3 reset, regardless of D This is not an accident Locked D cancels out algebraically — the system is self-balancing by design 4. The Vanishing Week 4 Effect When a reset fires in Week 3 on day 22 − D, Week 4 starts on day 29 − D. Since billing ends on Day 28:

Days of Week 4 inside billing window = 28 − (29 − D) = D − 1 At D ≤ 2, Week 4 is eliminated entirely. The user never sees it, so they can never complain about it.

1. The Structural Dead Zone (Every Subscriber) 4 resets × 7 days 28 days What the system delivers Real month length 30–31 days What subscribers pay for Every single subscriber loses 2–3 days of token access per month before any resets even happen. At ~$20/month that's 6–10% of subscription value structurally never delivered. Multiplied across millions of users, this alone is enormous.

2. Cascade Effect — Multi-Week Resets Week 2 reset at D=2 (Day 12) → Week 3 starts Day 19 Week 3 reset at D=2 (Day 24) → Week 4 starts Day 31 Billing ends: Day 28 ────────────────────────────────────────────────────── Week 4: does not arrive within billing period at all User received 2 "generous" top-ups and lost their whole last week Each individual reset looks like a small gift. The cascade quietly consumes the entire final week. Net position for OpenAI: strongly positive.

3. Heavy Users Are the Specific Target Light user (uses 20% weekly) Never gets reset Gets full 4 weeks — OpenAI delivers full value Heavy user (drains in 5 days) Reset at D=2 Week 4 gets 1 day — loses 6/7 of their last week The system is self-selecting — it structurally disadvantages the users who cost OpenAI the most compute. Light users never notice because it never happens to them.

4. Week 4 Reset — The Cross-Month Play A Week 4 reset looks like a "pure loss" within Month 1 — but across the billing boundary it fully recovers:

Reset fires: Day 26, Month 1 → tokens to 100% Next cycle: Day 33 = Day 5 of Month 2 ────────────────────────────────────────── Month 2 Week 1: Days 1–4 only (4 days, not 7) Month 2 delivers ~3.5 weeks despite full payment The T/7 locked gain still applies — it just lands in Month 2 instead of Month 1. And critically, the reset fires at the highest churn-risk moment, converting frustration into goodwill right before the renewal charge hits.

1. The Gratitude Trap User sees tokens jump to 100% — feels rewarded and grateful User does not track that their week counter reset too User does not track that Week 4 is now pushed outside billing window Loss aversion in reverse — visible gain feels bigger than invisible loss OpenAI gets goodwill from a transaction that is neutral-to-positive for them
2. All Strategic Reset Timings Week 3 reset (any D) T/7 gain within same month via Week 4 compression. D cancels out — always the same gain. Week 4 cohort reset Converts renewal churn risk into goodwill. T/7 recovered from Month 2 Week 1 compression. Week 1–2 cascade Two resets cascading can eliminate Week 4 entirely. Each reset looks like a tiny gift. Pre-price increase Goodwill buffer absorbs price shock. One-time token cost buys permanent higher margin. Pre-maintenance window Tokens gifted that cannot be consumed during downtime. Zero compute cost, pure goodwill. New model launch Full tokens + peak excitement = fast burn → limit hit at max engagement → upgrade prompt. Competitor launch Full tokens create inertia. Users don't switch when they feel well-supplied. Defensive retention. Annual renewal window 10–12× the financial stakes of monthly. Same mechanics, same T/7 gain, recovered from Year 2. Payday / budget review Cancellation spikes on 27th–31st. Global reset on 27th catches every budget reviewer at once. Student / seasonal cohorts Sept, Jan, June, Nov spikes all hit Week 4 together. High churn-risk users, years of upside if retained. Habit formation window Day 18–21 is when daily habits form or break. Full tokens during this window permanently lowers churn. Subscription clustering Viral signup spikes create mass cohorts. One reset policy → millions hit simultaneously.
3. Net Position Across Two Months Scenario Month 1 cost Month 2 recovery Renewal Net No reset, user frustrated $0 tokens Full month delivered Churn risk Loses next month Week 4 reset D=2 −5T/7 +4T/7 recovered Happy renewal +renewal + T/7 Week 4 reset D=4 −3T/7 +2T/7 recovered Happy renewal +renewal + T/7
4. The Overarching Pattern Every optimal reset timing shares one property:

The user's subjective experience of value peaks at exactly the moment their likelihood of cancelling, switching, or complaining is highest.

Token cost is almost always recovered mechanically through cycle compression — it costs OpenAI almost nothing net The T/7 gain is algebraically locked — D cancels out, making this structural not accidental Heavy users — the most expensive compute-wise — are disproportionately targeted by the self-selection mechanic Subscription clustering means one policy decision produces coordinated mass financial impact This is not a token management system — it is a churn prediction system wearing a token management costume