maxpool 1.5.53 → 1.5.55

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "maxpool",
-  "version": "1.5.53",
+  "version": "1.5.55",
   "description": "Multi-account Claude Code proxy with adaptive, rate-aware load balancing across Claude accounts",
   "type": "module",
   "main": "src/index.js",

package/src/index.js

@@ -1,5 +1,6 @@
 #!/usr/bin/env node
 
+import net from 'node:net';
 import { spawn, spawnSync } from 'node:child_process';
 import { createInterface } from 'node:readline';
 import { loadOrCreateConfig, loadConfig, saveConfig, atomicConfigUpdate, getConfigPath, loadState, saveState, getStatePath, getLogPath, readGeneration, flushConfigWrites, flushStateWrites } from './config.js';
@@ -7,6 +8,24 @@ import { setEventLogPath, installConsoleMirror, setConsoleStdoutSuppressed } fro
 import { SleepGuard } from './sleep-guard.js';
 import { AccountManager } from './account-manager.js';
 import { createProxyServer, REQUEST_IDLE_MAX_MS } from './server.js';
+
+// ── Happy Eyeballs: stop racing a dead IPv6 leg ────────────────────────────────
+// Node 20 resolves both families and, 250ms after starting the IPv4 connect, races an
+// IPv6 one (autoSelectFamily, autoSelectFamilyAttemptTimeout=250). On a machine whose
+// resolver returns an AAAA that BLACKHOLES — a VPN advertising IPv6 it cannot carry is
+// the common case — that second leg never completes and takes the whole connect down
+// with it, surfacing as UND_ERR_CONNECT_TIMEOUT / ETIMEDOUT on a network that is
+// otherwise fine (curl, which falls back cleanly, succeeds in the same second).
+//
+// Measured 2026-08-01 on this fleet: 6,848 connect failures in one day; A/B over 14
+// requests gave 12/14 at the 250ms default vs 14/14 with the timeout raised. Raising it
+// is preferred over disabling the race outright: real IPv6 still wins where it works,
+// and a blackholed leg simply loses instead of poisoning the attempt. `dns
+// setDefaultResultOrder('ipv4first')` was ALSO measured and is NOT reliable (6 of 14 in a
+// degraded window) — it reorders preference but still starts the doomed leg.
+net.setDefaultAutoSelectFamilyAttemptTimeout(
+  Math.max(1000, Number(process.env.MAXPOOL_FAMILY_ATTEMPT_TIMEOUT_MS) || 5000),
+);
 import { Prober } from './prober.js';
 import { loginOAuth, fetchProfile, refreshAccessToken, isTokenExpiringSoon, tokenFingerprint } from './oauth.js';
 import { TUI } from './tui.js';

package/src/server.js

@@ -1446,11 +1446,18 @@ function unavailableMessage(accountManager, requestInfo = {}, retryAfter, willRe
   }
 
   const claudeCount = accountManager.accounts.filter(a => a.type !== 'provider').length;
-  // Only name the providers when this pool actually HAS them (`cc all`). On `cc ma`
-  // (Claude-only) there are none, so the old hardcoded "and the GLM/Kimi providers"
-  // was a lie. When present they DO serve (not barred), so they're saturated too.
-  const providersClause = accountManager.accounts.some(a => a.type === 'provider')
+  // Only name the providers when this pool HAS them AND they are actually allowed to
+  // serve this request. With crossProviderFallbackPolicy 'never' (the default) they are
+  // barred by POLICY, not saturated — saying they are "at their limit" is a lie that
+  // hides the real, one-keypress fix. Name the switch instead.
+  const providerAccounts = accountManager.accounts.filter(a => a.type === 'provider');
+  const providersUsable = providerAccounts.some(a => a.enabled !== false
+    && accountManager._claudeFallbackFor?.(a.provider) !== 'never');
+  const providersClause = providerAccounts.length && providersUsable
     ? ' and the GLM/Kimi providers' : '';
+  const providersBarredHint = providerAccounts.length && !providersUsable
+    ? ' GLM and Kimi are switched off for Claude sessions — turn one on with m then g if you want them to cover this.'
+    : '';
 
   // No route is expected to recover within the queue window — i.e. every Claude
   // account is at its own 5h/weekly limit. A short "retry in Ns" would be a lie;
@@ -1459,10 +1466,14 @@ function unavailableMessage(accountManager, requestInfo = {}, retryAfter, willRe
     const eta = Number.isFinite(retryAfter) && retryAfter > 0
       ? ` Soonest reset in ~${formatRetryDuration(retryAfter)}, beyond the hold window.`
       : '';
-    return `No account can take this request — all ${claudeCount} Claude accounts${providersClause} are at their limit.${eta} Add another Claude account or wait for a quota reset.`;
+    return `No account can take this request — all ${claudeCount} Claude accounts${providersClause} are at their limit.${eta} Add another Claude account or wait for a quota reset.${providersBarredHint}`;
   }
 
-  return `No account can take this request right now — all ${claudeCount} Claude accounts${providersClause} are momentarily at their limit. Retry in ${retryAfter}s.`;
+  // "momentarily ... Retry in 2282s" was two bugs in one breath: 2282 seconds is 38
+  // MINUTES (not momentary), and raw seconds are unreadable. Scale the wording to the
+  // actual wait and render it in human units, the way every other branch already does.
+  const waitLong = Number.isFinite(retryAfter) && retryAfter >= 120;
+  return `No account can take this request right now — all ${claudeCount} Claude accounts${providersClause} are ${waitLong ? 'at their limit' : 'momentarily at their limit'}. Retry in ~${formatRetryDuration(retryAfter)}.${providersBarredHint}`;
 }
 
 // A provider (GLM/Kimi) rejecting a request whose token count exceeds its context