Claude Code’s source code leaked recently and briefly appeared on GitHub mirrors. I asked Claude Code, “Did you know your source code was leaked?” . It was curious, and it itself did a web search and downloaded and analysed the source code for me. Claude Code & I went looking into the code for something specific: why do some sessions feel shorter than others with no explanation? The source code gave us the answer. How session limits actually work Claude Code isn’t unlimited. Each session has a cost budget — when you hit it, Claude degrades or stops until you start a new session. Most people assume this budget is fixed and the same for everyone on the same plan. It’s not. The limits are controlled by Statsig — a feature flag and A/B testing platform. Every time Claude Code launches it fetches your config from Statsig and caches it locally on your machine. That config includes your tokenThreshold (the % of budget that triggers the limit), your session cap, and which A/B test buckets you’re assigned to. I only knew which config IDs to look for because of the leaked source. Without it, these are just meaningless integers in a cache file. Config ID 4189951994 is your token threshold. 136871630 is your session cap. There are no labels anywhere in the cached file. Anthropic can update these silently. No announcement, no changelog, no notification. What’s on my machine right now Digging into ~/.claude/statsig/statsig.cached.evaluations.: tokenThreshold: 0.92 — session cuts at 92% of cost budget session_cap: 0 Gate 678230288 at 50% rollout — I’m in the ON group user_bucket: 4 That 50% rollout gate is the key detail. Half of Claude Code users are in a different experiment group than the other half right now. No announcement, no opt-out. What we don’t know yet: whether different buckets get different tokenThreshold values. That’s what I’m trying to find out. Check yours — 10 seconds: cat ~/.claude/statsig/statsig.cached.evaluations. | python3 -c " import json,sys outer=json.load(sys.stdin) inner=json.loads(outer[‘data’]) configs=inner.get(‘dynamic_configs’,{}) c=configs.get(‘4189951994’,{}) print(‘tokenThreshold:’, c.get(‘value’,{}).get(‘tokenThreshold’,‘not found’)) c2=configs.get(‘136871630’,{}) print(‘session_cap:’, c2.get(‘value’,{}).get(‘cap’,‘not found’)) print(‘user_bucket:’, outer.get(‘user’,{}).get(‘userID’,‘not found’)) " No external calls. Reads local files only. Plus, it was written by Claude Code. What to share in the comments: tokenThreshold — your session limit trigger (mine is 0.92) session_cap — secondary hard cap (mine is 0) user_bucket — which experiment group you’re in (mine is 4) Here’s what the data will tell us: If everyone reports 0.92 — the A/B gate controls something else, not actual session length If numbers vary — different users on the same plan are getting different session lengths If user_bucket correlates with tokenThreshold — we’ve mapped the experiment Not accusing anyone of anything. Just sharing what’s in the config and asking if others see the same. The evidence is sitting on your machine right now. Drop your three numbers below. Post content generated with the help of Claude Code submitted by /u/stayhappyenjoylife
Originally posted by u/stayhappyenjoylife on r/ClaudeCode