Does apps_script mode have a hard limit on the number of Deployment IDs?

[sparkling-firefly]

Is there a hard-coded limit on the number of Deployment IDs the client will actually use in apps_script mode?
Thank you.

[therealaleph]

Reviewed via Anthropic Claude.

@sparkling-firefly — no hard-coded limit on script_ids count in apps_script mode. The client iterates whatever is in your config.json array.

Practical considerations even though no software limit:

1. Round-robin distribution: mhrv-rs cycles through all script_ids for each request. More IDs = more spread, but per-request latency is dominated by Apps Script edge RTT (~200-400ms), not script count.
2. Quota math: each script_id is owned by ONE Google account. Apps Script daily quota is per-account (~5K-20K UrlFetchApp calls depending on Google account age/region). 10 script_ids from 10 separate Google accounts = 10× quota. 10 script_ids from 1 Google account = same quota as 1 ID.
3. Marginal returns: past 3-5 healthy IDs from different accounts, adding more rarely helps. The bottleneck shifts from quota to Apps Script edge RTT and ISP network latency.
4. Probe overhead: at startup, mhrv-rs warms each ID with a probe (fetch_ips_from_api does some discovery work). 100 IDs = ~100 probe RTTs at startup = ~30-60s warm-up time.
5. Config file size: config.json parsing is bounded; 1000+ entries would work but isn't tested. Keep under 50 entries for sanity.

Failure modes you'd hit:

• IDs that frequently timeout get auto-blacklisted by mhrv-rs for 120s (fix: v1.9.15 full-mode warm-up race during h2 init (#924) #1029's + sliding window). So bad IDs just rotate out.
• If ALL IDs in your config are throttled simultaneously (Apps Script regional throttle), the proxy fails until any one recovers — no graceful degradation back to direct.

Recommendation: 2-5 script_ids from 2-5 separate Google accounts is the practical sweet spot. More than that is diminishing returns.

می‌بندم — no software limit, but architectural ceiling is around 5-10 useful IDs.