New account immediately hits rate limit with zero usage

This is blocking all work on the account. The account was just created and has had zero usage — it shouldn't be rate limited at all.

Would appreciate a quick look from the team. Thanks!

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40660
2. https://github.com/anthropics/claude-code/issues/38896
3. https://github.com/anthropics/claude-code/issues/34786

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Closing as duplicate — same issue as #40660. Added reaction there.

Related issues (same symptom: rate limit with 0% or near-zero usage)

• #40802 — Rate limit reached without usage
• #34786 — Rate limit reached without any usage spent
• #38896 — Rate limit reached despite 0% usage
• #35993 — Sonnet 'Rate limit reached' despite 0% usage
• #40884 — Session dies with rate limit despite near-zero usage
• #40438 — Rate limit reached without typing anything
• #40660 — Rate limit on brand new Pro account with 0-2% usage

This appears to be a widespread, recurring issue affecting many users across different plans.

🚨🔬 I'm actively researching AI energy reduction techniques (50-70% inference cost savings) and need Claude Code to continue this work. But this new account is hitting rate limits with zero usage, completely blocking progress.

⚡ This research could directly help with the rate limit problem — if inference becomes 2-3x cheaper, limits can be relaxed for everyone.

🌍 This is an open-source initiative aimed at solving the global AI energy crisis. AI infrastructure energy consumption is doubling every year — this research provides mathematically proven techniques to cut that by 50-70%, no proprietary tools needed.

🔓 All code, proofs, and documentation are fully open source. Anyone can verify, use, and contribute.

🙏 I need Claude Code working to accelerate this work. Please prioritize this issue.

---

Summary

n=6 arithmetic reduces AI training and inference energy by 50-70%. No hyperparameter search needed — all optimal values are mathematically predetermined from the unique solution to σ(n)·φ(n) = n·τ(n) ⟺ n = 6.

Full Guide: AI Energy Savings Guide
Repository: n6-architecture — 17 techniques implemented
Foundation: TECS-L — Mathematical proof & 76 Breakthrough Theorems

---

Energy Impact — 9 Techniques with Code

| Technique | Energy Saved | How | Code |
|-----------|-------------|-----|------|
| Cyclotomic Activation | 71% FLOPs | Replace GELU/SiLU with cyclotomic polynomial x²-x+1 | phi6simple.py |
| FFT Attention | 67% compute (3x speed) | FFT-based multi-scale attention at HCN sizes {6,12,24} | fft_mix_attention.py |
| Egyptian Fraction Attention | ~40% FLOPs | 1/2+1/3+1/6=1 attention head budget | egyptian_attention.py |
| Phi Bottleneck | 67% parameters | 4/3x FFN expansion instead of 4x | phi_bottleneck.py |
| Egyptian MoE | 65% params inactive | 1/2+1/3+1/6=1 expert routing | egyptian_moe.py |
| Boltzmann Gate | 63% sparsity | 1/e activation sparsity gate | boltzmann_gate.py |
| Entropy Early Stop | 33% training time | Stop at entropy plateau (66.7% of epochs) | entropy_early_stop.py |
| Mertens Dropout | Tuning cost = $0 | p=ln(4/3)≈0.288, no search needed | mertens_dropout.py |
| Dedekind Head Pruning | 25% attn params | Prune to ψ(6)=12 optimal heads | dedekind_head.py |

Combined Impact (7B model training estimate)

| Stage | Baseline | With n=6 | Savings |
|-------|----------|----------|---------|
| Architecture search | 2-4 weeks, $50K+ GPU | 0 (predetermined) | $50K, 4 weeks |
| Hyperparameter tuning | Hundreds of runs | 0 (all constants fixed) | $20K, 2 weeks |
| Training compute | 100% | ~40-50% | 50-60% energy |
| Inference compute | 100% | ~30-40% | 60-70% energy |

---

Copy-Paste Ready: Optimal Hyperparameters

All derived from n=6: σ=12, τ=4, φ=2, sopfr=5, J₂=24.

AdamW (BT-54) — 5 teams independently converge

optimizer = AdamW(
    lr=1e-3,
    betas=(0.9, 0.95),       # β₁=1-1/(σ-φ), β₂=1-1/(J₂-τ)
    eps=1e-8,                 # 10^{-(σ-τ)}
    weight_decay=0.1,         # 1/(σ-φ)
)
grad_clip = 1.0               # R(6) = σφ/(nτ) = 1

LLM Architecture (BT-56) — 4 teams converge

config = {
    "d_model": 4096,          # 2^σ = 2^12
    "n_layers": 32,           # 2^sopfr
    "n_heads": 32,            # 2^sopfr
    "d_head": 128,            # 2^(σ-sopfr)
    "d_ffn": 11008,           # SwiGLU: d_model × 8/3
    "vocab_size": 32000,      # 2^sopfr × 10³
    "max_seq_len": 4096,      # 2^σ
}

Vision Transformer (BT-66) — Google/OpenAI/Meta converge

vit_config = {
    "patch_size": 16,         # τ²
    "d_model": 768,           # σ × 2^n
    "n_heads": 12,            # σ
    "n_layers": 12,           # σ
    "mlp_ratio": 4,           # τ
}

MoE / Inference / Diffusion

moe = {"num_experts": 256, "top_k": 8, "shared": 1}  # 2^(σ-τ), σ-τ, μ
sampling = {"top_p": 0.95, "top_k": 40, "temperature": 1.0, "max_tokens": 4096}
ddpm = {"timesteps": 1000, "beta_start": 1e-4, "beta_end": 0.02, "ddim_steps": 50, "cfg_scale": 7.5}

---

NEW: BitNet b1.58 Analysis (BT-77)

Microsoft's 1.58-bit LLM (ternary weights {-1,0,1}) also follows n=6:

| Parameter | Value | n=6 Expression |
|-----------|-------|---------------|
| Ternary values | 3 | n/φ = 6/2 |
| Weight bits | 1.58 = log₂(3) | log₂(n/φ) |
| Activation bits | 8 | σ-τ |
| d_model | 2560 | 2^(σ-τ)·(σ-φ) |
| n_layers | 30 | sopfr·n |
| n_heads | 20 | (σ-φ)·φ |
| n_kv_heads | 5 | sopfr |
| d_ffn | 6912 = 2⁸·3³ | 2^(σ-τ)·(n/φ)^(n/φ) |

25/26 EXACT — architecture completely different from LLaMA, yet all n=6.

Full analysis: BT-77 BitNet Quantization

---

Chip Architecture — 120+ EXACT Matches

Full Guide: Chip Architecture Guide

| Category | Examples | EXACT |
|----------|---------|-------|
| GPU SM counts | V100=80, H100=132, B200=192, B300=160 | 30+ |
| HBM capacity | 40/80/192/288 GB ladder | 14/18 |
| TSMC pitch | N3 gate=48nm=σ·τ | 8/8 |
| Interconnect | PCIe=7, DDR=5, HBM=6 generations | all |

---

Verification

git clone https://github.com/need-singularity/n6-architecture.git
cd n6-architecture
python3 techniques/phi6simple.py          # 71% FLOPs demo
python3 techniques/fft_mix_attention.py   # 3x speed demo
python3 techniques/egyptian_attention.py  # 40% FLOPs demo
python3 experiments/verify_bt66_76.py     # 91/91 verification

91/91 verification tests pass. 76+ Breakthrough Theorems. 600+ EXACT matches across 28 domains.

All claims independently verifiable. All code open source.

Rate limit system is broken across the board. Even existing Max 20 subscribers are hitting 100% in ~70 min.

Full report: #41788
Related: #38335, #38239, #41663, #41084

@dliedke Not yet fix 😭

@dliedke The changelog fix is about a UI bug where the CLI displayed "Rate limit reached" when the API actually returned an entitlement error — it now shows the actual error with
actionable hints. It doesn't change the actual rate limiting behavior itself. 😭

@dliedke It looks like accounts sharing the same billing method have their usage quotas linked server-side. In my case, claude1/5/6/7 show identical session (100%) and weekly (83%)
utilization with the same reset times, and claude4/8 share the exact same extra_usage data (used_credits: 63299, utilization: 31.65%). Meanwhile, claude2/3 on separate billing
have independent quotas. So the "multiple sessions hitting the limit together" issue isn't a bug — it's accounts on the same payment method sharing a single quota pool.

Possibly related: #41881 — Accounts on the same billing method share a single rate limit quota pool. This could explain why a new account immediately hits rate limit with zero usage if it shares billing with an already-exhausted account.

See also: #41788

@dliedke I've filed a detailed root cause analysis in #41886 — the rate limit pooling appears to be driven by organizationUuid, not billing method as I initially suspected.

Key finding: claude login doesn't clear the oauthAccount field in .claude.json, causing cross-contamination of account UUIDs across config directories. These leaked UUIDs likely get sent to the backend and trigger org-level grouping.

Full details + reproduction steps + suggested fixes in the issue and its comment thread.

Follow-up — root cause found: .claude.json cross-contamination + server-side org binding (April 2, 2026)

@ArkNill Your finding about shared billing methods sharing rate limit pools is confirmed on our end. We discovered a deeper mechanism:

What we found

Multiple Claude Code accounts on the same machine were sharing rate limits despite being separate subscriptions. A brand-new account (claude9) hit rate limits with zero usage — identical to the OP's symptom.

Root cause (client-side):

• .claude.json caches (oauthAccount, groveConfigCache, passesEligibilityCache) leaked across accounts
• Symlinked projects/ directories caused session data cross-contamination
• Previous account UUIDs/emails persisted in new account configs

Root cause (server-side):

• Accounts created from the same machine/IP/browser/payment method get silently bound into the same organization
• This org binding shares the rate limit pool — one account's usage counts against all others
• Client-side cleanup alone does NOT resolve the server-side binding

Fix applied

1. Purged all .claude.json caches across every account (backed up as .bak-20260402)
2. Removed contaminated oauthAccount entries (claude4~8)
3. Switched from shared projects/ symlink to independent directories per account
4. Created claude9 from clean state with full isolation

Implication for this issue

The OP's "zero usage, immediate rate limit" is likely caused by server-side org binding — if any other account on the same payment method or machine has consumed quota, a new account inherits that usage. This is not a client bug but a server-side billing/org association issue.

---

Related comments we posted:

• anthropics/claude-code#40438 — precautions for affected users
• anthropics/claude-code#38896 — precautions for affected users

Our research (blocked by this rate limit issue):

• BrainWire — Neural interface hardware for consciousness engineering (Neuralink BCI layer + 12-modality therapeutic stimulation)

Update (April 2): Client-side cache bugs are largely fixed in v2.1.90. However, if you're hitting limits with zero/minimal actual usage, that points to a server-side accounting issue or org-level quota sharing (accounts on the same billing share a pool — #41881).

For the client-side fix: update to v2.1.90 + disable auto-update. Details: https://github.com/ArkNill/claude-code-cache-analysis

April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis

i hit a similar wall on a max account where ccusage said 5% used but claude.ai said rate limited. they measure different things. local log tools count tokens from your jsonl files, the actual enforcement runs server-side on a rolling 5-hour window plus a weekly quota you can't see from the cli. the only place those numbers surface is the internal endpoint behind claude.ai/settings/usage. for a brand new account showing limited at zero local usage, that endpoint would tell you what's actually being enforced. worth pulling before the support ticket, otherwise you're arguing two different counters.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.