[FEATURE] Config Preset for 10+ Accounts

[elstrm2]

Feature Description
Add a config preset/profile optimized for users with 10+ accounts because current defaults are tuned for ~3-5 accounts and can cause issues at scale like excessive rotation, cache loss, potential ban patterns and etc.

Suggested config ranges for 10+ accounts ------>

maxRetries: 2-4
defaultCooldownMs: 45000-90000
extendedCooldownMs: 300000-600000
maxWaitBeforeErrorMs: 120000-180000
globalQuotaThreshold: 0.06-0.10
rateLimitDedupWindowMs: 5000-10000
switchAccountDelayMs: 7000-12000
maxCapacityRetries: 2-4
capacityBackoffTiersMs: [8000-15000, 15000-30000, 30000-60000]

accountSelection.weights:
health: 5-7
tokens: 1-3
quota: 1-3
lru: 0.003-0.01

healthScore:
successReward: 2-4
rateLimitPenalty: -12 to -18
recoveryPerHour: 15-25
minUsable: 35-45

tokenBucket:
maxTokens: 60-90
tokensPerMinute: 8-12
initialTokens: 60-90

<------

Use Case

Users with 10+ accounts face different challenges than ~3-5 account setups. default lru=0.1 causes frequent rotation so it`s an obvious automation pattern; with lower lru like 0.003-0.01 system stays on one account like human and switches only on 429. Cache is account-bound so frequent rotation = cache miss = 10x cost on cached tokens. stats show 60-80% cache read with sticky behavior which is nice. Default defaultCooldownMs=10000 (10s) with many accounts can exhaust all of them during burst and so 45-90s cooldown prevents this cascade. also users with many accounts often work in sessions (not 24/7 like bot stations [this is an edge case that is not covered here because I say so and think so, for that just buy API and enjoy whatever bot station you like]). so i mean higher recoveryPerHour like 15-25 ensures full recovery between sessions. also health weight should dominate (5-7 range) so system reacts instantly to 429s — sticky until problem, then instant escape behavior.

Proposed Implementation
Option A: add preset selection in WebUI (eg => "Default", "Many Accounts 10+", "Conservative")
Option B: auto-detect based on account count / suggest optimal settings
Option C: just document recommended config for 10+ accounts in README (RECOMMENDED BY ME cuz easy to impl)

Compliance Consideration
Please confirm:

• [ OK AGREED BY ME ] This feature is for personal development use
• [ OK AGREED BY ME ] This feature does not violate or circumvent Google's Terms of Service
• [ OK AGREED BY ME ] This feature is not intended for commercial resale or multi-user access

All accounts are legitimate pro subscriptions so config optimizes for stability and cache efficiency and not abuse (hello google and anthropic!!!!!!!!)

Alternatives Considered
Manual config editing works but requires understanding internals. SO! I Spent significant time analyzing code (hybrid-strategy.js, health-tracker.js, quota-tracker.js) to find optimal values => logically, most users won`t do this.... and also found 5+ dead parameters in current config schema (requestTimeoutMs, retryBaseMs, retryMaxMs, persistTokenCache, logLevel) - they exist in config but code ignores them and you might want to clean those up separately or not you decide

Additional Context
I ALR TESTED THIS CONF with 12 pro accounts , had mixed usage (Claude Opus 4.5+ Gemini Flash subagents 1m 3.0 ), ~3-6 hours/day sessions with really random usage expericence because I work when I want.

SO THE GENERAL INSIGHT ALSO!! with many accounts you will probably 100% im sure you will want sticky behavior (because you stay on one account for cache) + fast escape (high health weight for instant switch on problems) and default config does opposite because it rotates often but switches slowly on issues.

so my conf makes 70% cache read rate (from def conf) improvement to 90+ cache read, ,minimal 429s and lockouts minimized.but i still noticed that no matter how the account is used if you do everything from one IP then after about a couple of weeks they can simply cancel the subscription (pro)...... so, yes this conf improves characteristics and lowers you chance of 429 and bans, but.... you will eventually be banned in few weaks