maxpool 1.22.0 → 1.22.2

package/package.json

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

package/src/account-manager.js

@@ -1445,10 +1445,11 @@ export class AccountManager {
    *
    * The ceiling is switchThreshold and never 1.0, deliberately: the owner asked for a
    * cap that "always preserves some meaningful room for usage of those accounts outside
-   * of MaxPool". A fully-ramped dynamic account therefore behaves exactly like an
-   * UNCAPPED one — never more aggressively — so this mechanism can only ever make an
-   * account MORE available than the fixed cap it replaces (pinned by T3c). That
-   * one-directionality is why it is not a live-session control surface.
+   * of MaxPool". NOTE the invariant is the WEAKER one: never LESS available than the
+   * FIXED CAP it replaces (pinned by T3c) — NOT "identical to an uncapped account".
+   * Above the ceiling the cap still hard-benches ('capped', ahead of the upstreamAllows
+   * carve-out) where the uncapped twin would read 'reserve' and stay routable. That is
+   * the reservation doing its job at the margin, not a parity bug.
    *
    * Fails CLOSED in every uncertain case (no stamp, unusable duration): an unknown
    * window position returns the floor, never an opened-up cap.
@@ -1946,7 +1947,13 @@ export class AccountManager {
     }
 
     if (q.unified5h != null && q.unified5h >= bench) {
-      return { cause: 'session_limit', retryAt: q.unified5hReset || null, queueable: Boolean(q.unified5hReset) };
+      // DYNAMIC CAP twin of the weekly arm's _capUnbenchAt: a rising session cap
+      // unbenches at its own ramp crossing, often hours before the 5h reset. Without
+      // this, util 0.55 over a floor 0.50 that has just rolled tells the client to wait
+      // ~5h when the cap releases it at ~2.8h (architect finding 2026-09-24).
+      const crossing = this._capUnbenchAt(account, q.unified5h, 'ses', now);
+      const retryAt = crossing ?? (q.unified5hReset || null);
+      return { cause: 'session_limit', retryAt, queueable: Boolean(retryAt) };
     }
 
     if (q.tokensLimit != null && q.tokensRemaining != null && q.tokensLimit > 0) {
@@ -4202,10 +4209,6 @@ export class AccountManager {
         // the restart AND the next `cc all` header re-send (the upsert guard).
         capUtilization: a.capUtilization ?? null,
         capMode: a.capMode ?? null,
-        capEffective: a.capUtilization == null ? null : {
-          ses: this._effectiveCap(a, 'ses'),
-          wk: this._effectiveCap(a, 'wk'),
-        },
       }));
   }
 
@@ -4420,10 +4423,6 @@ export class AccountManager {
         priority: a.priority,
         capUtilization: a.capUtilization ?? null,
         capMode: a.capMode ?? null,
-        capEffective: a.capUtilization == null ? null : {
-          ses: this._effectiveCap(a, 'ses'),
-          wk: this._effectiveCap(a, 'wk'),
-        },
         runtime: a.runtime,
         status: a.status,
         refreshDead: Boolean(a.refreshDead),

package/src/index.js

@@ -2113,14 +2113,25 @@ async function syncAccountsFromDisk(diskConfig, memConfig, accountManager) {
     // this a config-edit cap is stale until the next full reload).
     const diskCap = Number.isFinite(diskAcct.capUtilization) && diskAcct.capUtilization > 0 && diskAcct.capUtilization < 1
       ? diskAcct.capUtilization : null;
-    // The MODE rides along with the cap: a hand-edited config that adds/changes a cap
+    // The MODE and the two per-account OVERRIDES ride along with the cap: a hand
+    // edit to any of them must not sit stale until a restart (the staleness class
+    // this whole block exists to fix). a hand-edited config that adds/changes a cap
     // without naming a mode gets the dynamic default, exactly as a fresh load would —
     // otherwise a hot edit would silently produce a capped account with no mode, whose
     // effective cap is the floor forever (a fixed cap wearing the new feature's name).
+    // Same validation as boot (_capMode): a typo'd capMode must not fail open in
+    // silence on the hot path either — the boot path logs, so this does too.
+    if (diskCap != null && diskAcct.capMode != null && diskAcct.capMode !== 'fixed' && diskAcct.capMode !== 'dynamic') {
+      console.log(`[Maxpool] Ignoring unknown capMode ${JSON.stringify(diskAcct.capMode)} for "${mgr.name}" on hot sync — expected "fixed" or "dynamic"; using dynamic`);
+    }
     const diskMode = diskCap == null ? null : (diskAcct.capMode === 'fixed' ? 'fixed' : 'dynamic');
     if (mgr.capUtilization !== diskCap || mgr.capMode !== diskMode) {
       mgr.capUtilization = diskCap;
       mgr.capMode = diskMode;
+      const dCeil = Number.isFinite(diskAcct.capCeiling) && diskAcct.capCeiling > 0 && diskAcct.capCeiling < 1 ? diskAcct.capCeiling : null;
+      const dRamp = Number.isFinite(diskAcct.capRampStart) && diskAcct.capRampStart >= 0 && diskAcct.capRampStart < 1 ? diskAcct.capRampStart : null;
+      mgr.capCeiling = dCeil;
+      mgr.capRampStart = dRamp;
       console.log(`[Maxpool] Usage cap for "${mgr.name}" ${diskCap ? `set to ${Math.round(diskCap * 100)}% (${diskMode})` : 'removed'} from config`);
     }
     memConfig.accounts[memIdx] = { ...memConfig.accounts[memIdx], ...diskAcct };

package/src/tui.js

@@ -211,23 +211,31 @@ function capText(a, benched, am) {
   // scheduler is not using. `cap 50%>67%` reads as "reserved 50%, currently allowing
   // 67%"; the two collapse to one number while the cap sits at its floor, so an
   // early-window dynamic account looks exactly like the fixed one it replaced.
+  // The WINDOW is named, not just the number. `cap 50%>75%` alone is ambiguous in the
+  // way that matters for the decision the row exists to support ("is it safe for me to
+  // use this account myself right now?"): a lift driven by the 5h window means reduced
+  // protection for minutes, the same number off the weekly means DAYS of it. Council
+  // finding 2026-09-24.
   const eff = capEffectivePct(am, a);
-  const t = (eff != null && eff !== floorPct)
-    ? `cap ${floorPct}%>${eff}%`
+  const t = (eff != null && eff.pct !== floorPct)
+    ? `cap ${floorPct}%>${eff.pct}% ${eff.window}`
     : `cap ${floorPct}%`;
   return benched ? yellow(t) : dim(t);
 }
 
-/** The percentage routing is ACTUALLY enforcing on this account right now: the worse
- *  (lower) of its two windows' effective caps, which is the one that benches first.
- *  Null for a fixed cap or when the manager cannot compute one. */
+/** What routing is ACTUALLY enforcing on this account right now: the worse (lower) of
+ *  its two windows' effective caps — the one that benches first — AND WHICH window that
+ *  is. Returns {pct, window:'5h'|'wk'} or null for a fixed cap / when the manager cannot
+ *  compute one. The window label is load-bearing: the same percentage means "protection
+ *  is thin for the next few minutes" off the 5h window and "thin for days" off the weekly. */
 function capEffectivePct(am, a) {
   if (!am?._effectiveCap || a?.capMode !== 'dynamic') return null;
-  const vals = ['ses', 'wk']
-    .map(w => am._effectiveCap(a, w))
-    .filter(v => typeof v === 'number' && Number.isFinite(v));
+  const vals = [['ses', '5h'], ['wk', 'wk']]
+    .map(([w, label]) => ({ v: am._effectiveCap(a, w), window: label }))
+    .filter(e => typeof e.v === 'number' && Number.isFinite(e.v));
   if (!vals.length) return null;
-  return Math.round(Math.min(...vals) * 100);
+  const worst = vals.reduce((lo, e) => (e.v < lo.v ? e : lo));
+  return { pct: Math.round(worst.v * 100), window: worst.window };
 }
 
 /** PER-ACCOUNT SETTINGS the user set by hand — the last column's whole job